flair.14 Reporter
	Description • 24 years ago

when you enter webcamnow.com i go to family&friends section. immediately after i
go into this section it asks me to download a plugin. i click on ok and mozilla
will crash.i can reproduce this error 100% of the time

	R.K.Aa.
	Comment 1 • 24 years ago

It crashes all right.. Backtrace looks familiar but can't find it in bugzilla:
(2001020608)

Program received signal SIGSEGV, Segmentation fault.
0x40e7062b in nsPluginHostImpl::GetURLWithHeaders ()
   from /usr/local/mozilla/components/libgkplugin.so
(gdb) bt
#0  0x40e7062b in nsPluginHostImpl::GetURLWithHeaders ()
   from /usr/local/mozilla/components/libgkplugin.so
#1  0x40e705d0 in nsPluginHostImpl::GetURL ()
   from /usr/local/mozilla/components/libgkplugin.so
#2  0x40e6ba90 in _geturl () from /usr/local/mozilla/components/libgkplugin.so
#3  0x40e87405 in NPN_GetURL ()
   from /usr/local/mozilla/plugins/libnullplugin.so
#4  0x40e86f66 in DialogOKClicked ()
   from /usr/local/mozilla/plugins/libnullplugin.so
#5  0x4058b0fd in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#6  0x405b884d in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#7  0x405b7c92 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#8  0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#9  0x4052a8c8 in gtk_button_clicked () from /usr/lib/libgtk-1.2.so.0
#10 0x4052beb8 in gtk_real_button_released () from /usr/lib/libgtk-1.2.so.0
#11 0x4058b0fd in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#12 0x405b7b4b in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#13 0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#14 0x4052a808 in gtk_button_released () from /usr/lib/libgtk-1.2.so.0
#15 0x4052b872 in gtk_button_button_release () from /usr/lib/libgtk-1.2.so.0
#16 0x4058acc9 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#17 0x405b7ccb in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#18 0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#19 0x405eac8c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#20 0x4058ac22 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#21 0x40589e7a in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
---Type <return> to continue, or q <return> to quit---
#22 0x404d00bf in handle_gdk_event ()
   from /usr/local/mozilla/components/libwidget_gtk.so
#23 0x4063453b in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#24 0x40661186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#25 0x40661751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#26 0x406618f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#27 0x405897b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#28 0x404c82ac in nsAppShell::Run ()
   from /usr/local/mozilla/components/libwidget_gtk.so
#29 0x4043e3ea in nsAppShellService::Run ()
   from /usr/local/mozilla/components/libnsappshell.so
#30 0x804dd55 in main1 ()
#31 0x804e595 in main ()
#32 0x402479cb in __libc_start_main (main=0x804e468 <main>, argc=1, 
    argv=0xbffff684, init=0x804af1c <_init>, fini=0x8053d84 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff67c)
    at ../sysdeps/generic/libc-start.c:92

	R.K.Aa.
	Comment 2 • 24 years ago

Resembles bug 54921 but different stack. Resolving as new, new component/QA

	R.K.Aa.
	Comment 3 • 24 years ago

Modifying summary, setting new for real, upping severity.

	shrirang khanzode
	Comment 4 • 24 years ago

cc: Peter L. I definitely see the crash on this website while pressing OK on the 
plugin download dialog. well, works fine on java.sun.com, does not crash.

	R.K.Aa.
	Comment 5 • 24 years ago

An anomaly with the Plugin dialog:  When it first appears it vanishes again
right away, and lands in background. It has to be brough to foreground on my
system, before i can click on it. Anyone else see that?

	shrirang khanzode
	Comment 6 • 24 years ago

:( nope, it's fine 4 me

	R.K.Aa.
	Comment 7 • 24 years ago

ok good - false alarm on that. (my "raise window" setting must be acting up)

	Peter Lubczynski
	Comment 8 • 24 years ago

This may have been fixed by recent check-ins as it no longer crashes for me.

R.K.Aa, can you try to duplicate with a recent build? Thanks.

	R.K.Aa.
	Comment 9 • 24 years ago

It still crashes on linux SEA 2001020721
The stack has changed.
I tested now by first deleting cache, then restarting moz. (btw... nullplugin is
initially registered twice - i think there's another bug on that)

Immediately  before crash i see this in console:

Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"

Backtrace (non-debug)

Program received signal SIGSEGV, Segmentation fault.
0x40e4fa0b in _geturl () from /usr/local/mozilla/components/libgkplugin.so
(gdb) bt
#0  0x40e4fa0b in _geturl () from /usr/local/mozilla/components/libgkplugin.so
#1  0x4096c405 in NPN_GetURL ()
   from /usr/local/mozilla/plugins/libnullplugin.so
#2  0x4096beab in DialogOKClicked ()
   from /usr/local/mozilla/plugins/libnullplugin.so
#3  0x4058b0fd in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#4  0x405b884d in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#5  0x405b7c92 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#6  0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#7  0x4052a8c8 in gtk_button_clicked () from /usr/lib/libgtk-1.2.so.0
#8  0x4052beb8 in gtk_real_button_released () from /usr/lib/libgtk-1.2.so.0
#9  0x4058b0fd in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#10 0x405b7b4b in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#11 0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#12 0x4052a808 in gtk_button_released () from /usr/lib/libgtk-1.2.so.0
#13 0x4052b872 in gtk_button_button_release () from /usr/lib/libgtk-1.2.so.0
#14 0x4058acc9 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#15 0x405b7ccb in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#16 0x405b5d95 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#17 0x405eac8c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#18 0x4058ac22 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#19 0x40589e7a in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#20 0x404d00ef in handle_gdk_event ()
   from /usr/local/mozilla/components/libwidget_gtk.so
#21 0x4063453b in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#22 0x40661186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#23 0x40661751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#24 0x406618f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#25 0x405897b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#26 0x404c82ac in nsAppShell::Run ()
   from /usr/local/mozilla/components/libwidget_gtk.so
#27 0x4043e3ba in nsAppShellService::Run ()
   from /usr/local/mozilla/components/libnsappshell.so
#28 0x804dd55 in main1 ()
#29 0x804e595 in main ()
#30 0x402479cb in __libc_start_main (main=0x804e468 <main>, argc=1, 
    argv=0xbffff684, init=0x804af1c <_init>, fini=0x8053d84 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff67c)
    at ../sysdeps/generic/libc-start.c:92

	Peter Lubczynski
	Comment 10 • 24 years ago

Ok, the crash looks like it's in NPN_GetURL(). Time to break out gdb, if I can 
get it working :(

	av (gone)
	Comment 11 • 24 years ago

This is deceiving. This is a very special case. The default plugin dialog does 
not get destroyed when the object frame is destroyed (if, say, there is 
redirection on the page). instance->pdata gets corrupted when it comes back to 
the plugin, and where exactly it crashes is just a matter of chance. That was my 
impression after spending some time with serge at his unix box. We've got a 
patch to kill the dialog window if the page is teared up before the dialog is 
dismissed (and what actually happened on this page). Serge is going to post the 
patch soon.

	shrirang khanzode
	Comment 12 • 24 years ago

this same stack trace appeared in the list that phil sent to me...for crashers 
for 6.01

	av (gone)
	Comment 13 • 24 years ago

Serge, I am targeting this as mozilla0.9. If you don't think it is feasible, 
please correct accordingly.

	karnaze (gone)
	Comment 15 • 24 years ago

Moving to mozilla0.8.1

	av (gone)
	Comment 17 • 24 years ago

*** Bug 71884 has been marked as a duplicate of this bug. ***

	av (gone)
	Comment 18 • 24 years ago

It is waitng sr, but apparently we are missing the boat. Moving to 0.9.

	Peter Lubczynski
	Comment 19 • 24 years ago

Marc, can you super review this?

	Marc Attinasi
	Comment 20 • 24 years ago

I am not familiar wit he plugin code enough to make heads or tails of the patch,
so all I can do it rubber-stamp this one, but I need to know how you actually
tested that this works and has not caused any other regressions. I'm guessing
that the reported crash at least is fixed, but have you tested other cases to
make sure that there are no regressions? The code in the patch looks sane -
sr=attinasi, assuming that the testing done has been adequate.

	serge (gone) Assignee
	Comment 21 • 24 years ago

Thanks Marc,
actually I had to post here our early e-mail discussion of this patch with              
Christopher Blizzard <blizzard@mozilla.org>, I'm correcting myself now

> 
> Christopher Blizzard wrote:
> 
> > Serge Charapaev wrote:
> >
> >>
> >>
> >> Christopher Blizzard wrote:
> >>
> >> > Andrew Volkov wrote:
> >> >
> >> > > http://bugzilla.mozilla.org/show_bug.cgi?id=67879
> >> >
> >> > A couple of questions:
> >> >
> >> > o We have list handling in nspr, right?  Even though it's a C
> >> > file there
> >> > is already an impl that you can use.  I see a lot of list work in
> >> > this
> >> > code.  Is that required for ABI compatibility or can we resuse
> >> > the hash
> >> > table impls and list impls in nspr?
> >> >
> >> or GList...,
> >> I agree, but I did  a patch on existing code, and the list impl
> >> already been in there.
> >
> > OK.  We might want to add a bug somewhere to fix that.  Not
> > important but should be done one day for cleaup reasons.  ( This is
> > my obsessive compulsive nature showing through. :)
> >
> >> >
> >> >
> >> > o Why are you using Xt to do your pixmap drawing?  We have
> >> > routines in
> >> > gdk to that for you.
> >> >
> >> >
> >> well, all we have here is  XtWindow_ID according of
> >> http://lxr.mozilla.org/seamonkey/source/widget/src/gtkxtbin/gtkxtbin.c#354
> >> which is right thing to have considering backward compatibility,
> >> so I do not see any reason why I cannot use Xt,
> >> moreover to me it seems easy to use origin Xt stuff , moreover to
> >> get gdk window from foreign Xt one
> >> is not a trivial task, I've tried gdk_window_foreign_new() it does
> >> not work properly
> >
> > If you're already using gtk in there already there's no reason to
> > pull in Xt if you don't have to.
> >
> > Since the Xt drawable is the same as the widget->window have you
> > tried hooking up to the draw signal in the widget instead?  The code
> > is much simpler if you can.  The code would just be something like:
> >
> > void
> > plugin_draw_callback(GtkWidget *widget, GdkRectangle *area) {
> >    (...)
> > }
> >
> > Let me play with this a little.
> >
> OK, now I understand why you are using Xt and in this context.  I also
> remember why I hate looking at the GtkXtBin code. :)
> 
> A few stylistic comments -
> 
>    * Can you use a consistent style for your globals?  You've got
>      cursor, aPixmap ( is that an argument or a global? ) and
>      xpm_attr.  Three different styles for three different variables
>      which are all globals.
>    * Please include "prprf.h" to get rid of the warning about
>      PR_snprintf() being undefined.
>    * There are some strlen() calls in there when there are PL_*
>      equivalents.
> 
> Is there any reason why this plugin is an old style plugin?  If it
> were a new style plugin it could use nsIPrompt, real list handling and
> be much cleaner.  It could even be XP.  If it's possible can we file a
> bug on it?
> 
> Other than that sr=blizzard.  It seems to work well.
> 
> --Chris

	karnaze (gone)
	Comment 22 • 24 years ago

Reassigning to serge.

	serge (gone) Assignee
	Comment 23 • 24 years ago

Checked in:
/cvsroot/mozilla/modules/plugin/default/unix/Makefile.in,v <--  Makefile.in
new revision: 1.4; previous revision: 1.3
npshell.c;/cvsroot/mozilla/modules/plugin/default/unix/npshell.c,v <-- npshell.c
new revision: 1.10; previous revision: 1.9
/cvsroot/mozilla/modules/plugin/default/unix/nullplugin.c,v <--  nullplugin.c
new revision: 1.5; previous revision:1.4
/cvsroot/mozilla/modules/plugin/default/unix/nullplugin.h,v <--  nullplugin.h
new revision: 1.4; previous revision: 1.3
----
resolve as FIXED 

	David Baron :dbaron:
	Comment 24 • 24 years ago

I'm about to back out these changes because the following tinderboxes are red: 
speedracer (on Seamonkey), messina, monkeypox, nebiros, palermo, and torino (on
SeaMonkey-Ports).  None of these machines have the system header file
<X11/xpm.h> and serge@netscape.com did not respond to email about this problem.

Reopening bug.

See:
http://www.mozilla.org/hacking/rules.html
http://www.mozilla.org/projects/seamonkey/rules/bible.html
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports
for more information.

	tor
	Comment 25 • 24 years ago

I agree with dbaron - this should be backed out, as xpm isn't a standard part
of X11.  Use a gdk/gtk equivalent for loading the pixmap, such as
gdk_pixmap_colormap_create_from_xpm (see
xpfe/bootstrap/nsNativeAppSupportGtk.cpp for an example).

	serge (gone) Assignee
	Comment 26 • 24 years ago

well, I cannot use gdk_pixmap_colormap_create_from_xpm_d((GdkWindow *window,...)
there is no GdkWindow I can use here. I'll try to use Xlib calls instead.

	Christopher Blizzard (:blizzard)
	Comment 28 • 24 years ago

I find it kind of amusing that we're using xpm via gdk when we're saying that 
it's not standard. :)

sr=blizzard

	serge (gone) Assignee
	Comment 29 • 24 years ago

checked in
/cvsroot/mozilla/modules/plugin/default/unix/Makefile.in,v  <--  Makefile.in
new revision: 1.6; previous revision: 1.5
/cvsroot/mozilla/modules/plugin/default/unix/nullplugin.h,v  <--  nullplugin.h
new revision: 1.6; previous revision: 1.5
/cvsroot/mozilla/modules/plugin/default/unix/npshell.c,v  <--  npshell.c
new revision: 1.12; previous revision: 1.11
/cvsroot/mozilla/modules/plugin/default/unix/nullplugin.c,v  <--  nullplugin.c
new revision: 1.7; previous revision: 1.6

	av (gone)
	Comment 30 • 24 years ago

Marking fixed.

	shrirang khanzode
	Comment 31 • 24 years ago

verified on linux 042308 trunk build. It no longer crashes when I click OK on 
the default downloader plugin. VERIFIED.

	Peter Lubczynski
	Comment 32 • 24 years ago

*** Bug 76503 has been marked as a duplicate of this bug. ***