85958 - Shockwave/Flash pages cause crash under Solaris [x-server/bit-depth]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jim Crumley]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; rv:0.9.1+) Gecko/20010613
BuildID:    2001061322

Mozilla crashes under Sparc Solaris 2.7 when trying to access 
any Macromedia Flash page when displaying on a display
with a default resolution of 8 bits per pixel. This display
supports up to 24 bpp (and mozilla itself runs at 24 bpp), but
the xserver is set to default to 8bpp because of some legacy
apps which don't like 24 bpp. This crash occurs while running
mozilla from the local box, or when run off a pentium Linux box
and displayed on the Solaris box.  The crash does not dump a core.

The error messages while running locally:

  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  58
  Current serial number in output stream:  59

Error message when running from Linux box:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 58 error_code 8 request_code 72 minor_code 0

From a quick search of google on these error messages, this
seems to be a fairly common X problem under Solaris. 


Reproducible: Always
Steps to Reproduce:
mozilla http://www.macromedia.com/ & 
(Display on Solaris box with default color depth of 8 bpp).

Actual Results:  crash

Expected Results:  Display page (works correctly with this plugin with 
netscape 4.7x, or for Linux box using its own display).

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[yiming chung]

add cc

Comment 3

[Dimitri Papadopoulos]

This is probably a duplicate of 79601:
	http://bugzilla.mozilla.org/show_bug.cgi?id=79601

Turning off javascript in the preferences dialog should
stop mozilla from crashing.

Comment 4

[Jim Crumley]

No, this is not a duplicate.  Turning javascript controls off had no effect.
Mozilla still crashes immediately for me on all Flash pages.

Also, if this were a duplicate the same behavior would be seen on Linux,
but I do not get this crash on Linux.

I try to build a Solaris debug build to see if I can get some more info
on this. 

Comment 5

[barnes]

Also occurs on Solaris 8 with, for example, build 2001072210.

Comment 6

[Peter Lubczynski]

Can someone post a stack track or a talkback ID? Thanks!

Comment 7

[Jim Crumley]

Sorry for the delay in posting details. I can't give you a talkback ID, because
AFAIK there aren't any talkback builds for Solaris.

Anyway, no core is dumped, so I ran a debug build that I made under gdb. Crashed
as usual at www.macromedia.com.  I'll attach the complete log of that session.

Let me know if there's anything else that you want me try.

Comment 8

[Jim Crumley]

Attachment: log of gdb session showing crash

Comment 9

[Jim Crumley]

Some more info on this bug.  Today with build 20010932322 I came acrosss this
bug and two times it dumped a core during the crash. Also, the debugging info is
slightly different than during previous crashes:

    Cannot allocate colormap entry for default background.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  61
  Current serial number in output stream:  62

The information from the two core looks like it may not be all that useful. 
Each core gave a bunch of "Reading symbols from" lines and then had one line of
other info.  One was:
#0  0xfeb45dd4 in realfree () from /usr/lib/libc.so.1
While the other was:
#0  0xfeb464fc in t_splay () from /usr/lib/libc.so.1

Also, I can only get this bug to dump core after browsing for a while.  If a
Flash site which causes this is the first or second site I visit, a core will
not be dumped.  But if I've been browsing for a while, then a core might be
dumped. Any ideas on why that might be?

Comment 10

[Jim Crumley]

Stack trace from crashing at www.macromedia.com with Sparc Soalris build 2001102222:

#0  0xfeb45dd4 in realfree () from /usr/lib/libc.so.1
#1  0xfeb46624 in _free_unlocked () from /usr/lib/libc.so.1
#2  0xfeb46574 in free () from /usr/lib/libc.so.1
#3  0xfed2c6f4 in _XFreeDisplayStructure () from /usr/lib/libX11.so.4
#4  0xfed258a4 in XCloseDisplay () from /usr/lib/libX11.so.4
#5  0xfeebbb24 in gdk_exit_func () at gdk.c:1007
#6  0xfeb203e0 in _exithandle () from /usr/lib/libc.so.1
#7  0xfeb9a194 in exit () from /usr/lib/libc.so.1
#8  0xfed2c918 in _XDefaultError () from /usr/lib/libX11.so.4
#9  0xfdd36960 in nsIMEGtkIC::~nsIMEGtkIC ()
   from /net/aurora/a1/crumley/sun/moz-old/components/libwidget_gtk.so
#10 0xfed2288c in _XError () from /usr/lib/libX11.so.4
#11 0xfed161a4 in _XEventsQueued () from /usr/lib/libX11.so.4
#12 0xfed17c24 in XEventsQueued () from /usr/lib/libX11.so.4
#13 0xfd8d27e0 in XtAppPending () from /usr/lib/libXt.so.4
#14 0xfd911714 in _start ()
   from /net/aurora/a1/crumley/sun/moz-old/./libgtkxtbin.so
#15 0xfee6627c in g_main_iterate (block=1, dispatch=1) at gmain.c:771
#16 0xfee66930 in g_main_run (loop=0x2f22b0) at gmain.c:935
#17 0xfefbfcec in gtk_main () at gtkmain.c:476
#18 0xfdd1f190 in nsAppShell::Run ()
   from /net/aurora/a1/crumley/sun/moz-old/components/libwidget_gtk.so
#19 0xfe9a9c10 in nsAppShellService::Run ()
   from /net/aurora/a1/crumley/sun/moz-old/components/libnsappshell.so
#20 0x170d0 in NS_CreateNativeAppSupport ()
#21 0x17b3c in main ()

Comment 11

[Peter Lubczynski]

I think this is a dup....but maybe Serge or Pavlov know what's going on here....

Comment 12

[Mike Gebis]

My friend noticed this problem at work, but when I ran the binary out of his
directory, I had no problem whatsoever.  We finally figured out that the
difference was that he was using a GTK theme (one of the Aqua ones); when he
went back to the default GTK theme, he had no problems with Flash.

I can gather more details if you would like.  I'm being a bit vague here because
I'm not at work right now. :)

Comment 13

[Jim Song]

Could this fault be invoked by the absent of X's 16 bit depth?

Comment 14

[Peter Lubczynski]

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

Comment 15

[Peter Lubczynski]

--->reassign to Sergi by request

Comment 16

[Jim Song]

I directly load a flash file, and found in file nsPluginHostImpl.cpp,
there are two call for SetWindow  in "InstantiateFullPagePlugin".
The second one will also cause the crash.  

Comment 17

[Sergi]

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

Comment 18

[Sergi]

Two calls for SetWindow is not a reason of crush. For example,
'InstantiateEmbededPlugin' has only one SetWindow call, but embedded
plugins crush browser too.

Xmon monitoring shows (for example):

                                 ..............ERROR: Match
                                     sequence number: 003a
                                        minor opcode: 0000
                                        major opcode: 48

This error means request with sequence number 003a had bad match.
Looking for 003a request:

         ............REQUEST: PutImage
             sequence number: 003a
                      format: ZPixmap
              request length: ff00
                    drawable: DWB 06c00001
                          gc: GXC 06c00014
                       width: 02f7
                      height: 0056
                       dst-x: 0
                       dst-y: 0
                    left-pad: 00
                       depth: 18
                        data: [...skipped...]

Note: depth of image are 0x18 (i.e. 24). Drawable is window we are
going to use for drawing. Looking for window 06c00001:

         ............REQUEST: CreateWindow
             sequence number: 000c
                       depth: 08
              request length: 000d
                         wid: WIN 06c00001
                      parent: WIN 064001bf
[...skipped...]

Note: depth of this window are 0x08 (i.e. 8bit).  That is reason. Bad match
of visuals as described in http://bugzilla.mozilla.org/show_bug.cgi?id=114047

Comment 19

[Sergi]

Attachment: one part of fix, patch for mozilla/widget/src/gtkxtbin/gtkxtbin.c

Comment 20

[Sergi]

Attachment: second part of fix, patch for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

Comment 21

[Sergi]

Attachements contain two patches for files:
mozilla/widget/src/gtkxtbin/gtkxtbin.c
and
mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

Main ideq of fix is to get visual, depth and colormap from one place
for all child windows associated with plugin. Please review.

Comment 22

[Sergi]

Huh. Sorry. I should check fix more carefully.
Flash works, but pressing of right mouse button crushes browser
with bad match while creating popup window.

Comment 23

[Jim Song]

Hi, 
I check the source files, but found no clue that the popup menu
is created by mozilla itself. Does anybody can conform that it
is created by flash plugin itself?

Comment 24

[Sergi]

Sure, it's plugin itself.

Comment 25

[Jim Song]

Then can someone from Mozilla inform Shockwave this bug? I have reported
this to them, but there is no response till now. Currently, I found a way 
to disable the right-button event on flash plugin. I donot know whether
my patch is needed since it is only the temporary method.

Comment 26

[Sergi]

Attachment: first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c

Comment 27

[Sergi]

Attachment: second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

New patch posted, works fine. Right button in plugin shows menu.
Please review.

Comment 28

[Jim Song]

Sergi, 
Great work! 
I have test your new patch.Now the flash seems so pretty on Solaris. 

Comment 29

[Margaret Chan]

Are the patches currently under review?  

Comment 30

[serge (gone)]

Comment on attachment 64156 [details] [diff] [review]
first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c

looks good r=serge

Comment 31

[serge (gone)]

Comment on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

r=serge

Comment 32

[Sergi]

Comment on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

Mark patch has-review due to previous comment.

Comment 33

[serge (gone)]

blizzard, could you sr=, please?

Comment 34

[Christopher Blizzard (:blizzard)]

Comment on attachment 64156 [details] [diff] [review]
first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c

sr=blizzard

Comment 35

[Christopher Blizzard (:blizzard)]

Comment on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

sr=blizzard

Comment 36

[Jim Crumley]

Any chance of getting this into the trunk?

Comment 37

[Jim Crumley]

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

Comment 38

[rubydoo123]

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

Comment 39

[Joshua Xia]

Hi, Can anybody checkin this patch?

Thanks!

Comment 40

[serge (gone)]

in the trunk
mozilla/widget/src/gtkxtbin/gtkxtbin.c,v  <--  gtkxtbin.c
new revision: 1.14; previous revision: 1.13
mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp,v  <-- 
ns4xPluginInstance.cpp
new revision: 1.94; previous revision: 1.93

Thanks all.

Comment 41

[Jay Yan]

will this patch be landed on 1.0 branch?

Comment 42

[serge (gone)]

nominating for the branch

Comment 43

[Jim Crumley]

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

Comment 44

[serge (gone)]

changing resolution to fixed

Comment 45

[Jay Yan]

serge:
Do you ( anyone else) have paln to land it on 1.0 branch? 

if nobody has time plan, I will ask for approval from drivers, than checkin it
into branch.

Thanks

Jay

Comment 46

[serge (gone)]

Jay: w/o verification it wont be approved for sure.
Could you verify this and mark so, before requesting an approval, please?

Comment 47

[Jay Yan]

Sure, Serge, we will take care of it till it is checkined to branch.
thanks. 
Jay

Comment 48

[Jay Yan]

When Harry and I were verifying this bug using trunk code, we met with a crash.

and it is always reproducible, the way to reproduct it is to 
1 install flash plugin
2 access http://www.macromedia.com  
3 stay for a while without any action after all the page is loaded,  (if you are
not patient, you can move the window or do whatever you like)
4 mozilla crash without a core. 

it happens on Solaris, both 8bpp and 24bpp. I did not try it's status on linux
or 1.0 branch.

This patch is not the guilty patch, since I pulled out the patch from my
workspace then build/run mozilla again, there is still crash.

Serge: did you meet with the same crash in Linux?

Comment 49

[Robin Lu]

mozilla 1.0 on solaris also crashes.

I used xmon but no relative error was caught.So it might not be the same error
as this patch being fixed.

I used Workshop and caught a signal 11 SEGV (no mapping at the fault address).
The stack is:
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611

   main(0x0, 0xffbeed34, 0xffbeed3c, 0x5f1c8, 0x0, 0x0)
   0x199a8(0x0, 0xff23d4a8, 0x601f0, 0x1b224, 0x100d4, 0x0)
   Run__17nsAppShellService(0xbebc0, 0xfdb4f8f4, 0xbebc0, 0xfdb509f8,
0xffbeeac0, 0x1cdb0)
   Run__10nsAppShell(0xd70b0, 0xfdadfbbc, 0xd70b0, 0xff1f7280, 0x0, 0xffe)
  gtk_main()
   g_main_run(0x20cd58, 0x20cd58, 0x1, 0xfdadfc80, 0x0, 0x0)
   g_main_iterate(0x1, 0x1, 0xff25057c, 0x0, 0xff3e2660, 0xfdacfe44)
   g_main_dispatch(0xffbee988, 0x707c0, 0x1, 0x765b78, 0xff3e2660, 0xfecd7cb8)
   g_timeout_dispatch(0x7be5a0, 0xffbee988, 0x765b78, 0x3, 0x0, 0xffbee8f0)
   0xfd611ba8(0x7b4270, 0x1, 0x0, 0x0, 0x0, 0x0)  <<== This is
xt_event_polling_timer_callback at gtkxbin.c while debuging with my private build 
   XtAppProcessEvent(0x7b4270, 0x1, 0x3, 0x8, 0x4, 0x2)
   __do_global_dtors_aux(0x7c5990, 0xffbee770, 0x843037, 0x2, 0xf4240, 0xffbee774)
   __do_global_dtors_aux(0x7c5990, 0xffffffff, 0xffbee650, 0xffbee5d0,
0xffbee550, 0xffbee390)
   __do_global_dtors_aux(0x7c5990, 0x0, 0xffbee61c, 0xffbee618, 0xffbee614,
0xffbee610)
   __do_global_dtors_aux(0x7c5990, 0x52, 0x0, 0x793988, 0x1d, 0x1)
   __do_global_dtors_aux(0x7c5990, 0x93ddd8, 0x8d8258, 0xffbee290, 0x0, 0xffbee2b8)
   __do_global_dtors_aux(0xffbee278, 0x9306d8, 0x3, 0x793970, 0xfffff410,
0xfffff3c0)

I changed the xt_event_polling_timer_callback to XtAppProcessEvent only
XtIMTimer in my private load. Then, this signal begins to generat from
xt_event_dispatch at gtkxtbin.c.

So, could there be some error on event handling of gtkxtbin?

Comment 50

[Jim Crumley]

Attachment: Stack trace of "new" crash

I've attached a stack trace of the the "new" crash type.  The stack looks the
same with build 2002070222 and with a version of 1.0 that I patched for this
bug.

The traces are much different between the crashes and the behavior is different
too.  With the "old" crash, any Flash page crashed immediately on load.  This
"new" bug takes some time to happen, and doesn't seem to happen on most Flash
sites. In fact, I haven't found this crash on any page except macromedia.com.

Anyway, this "new" problem should definitely have its own bug.

Comment 51

[rubydoo123]

I'm not sure why Jim did not open a new bug report, but I will do so now.
Although I cannot reproduce his crash on windows so I presume this is unix only.
See bug 155601 for the new bug report

Comment 52

[Jay Yan]

Since the new crash is another new bug 155601, and Harry and I can use the trunk
to load shockwave and flash on 8bpp Solaris, mark it as verified.

What's more, the new crash is not regression casued by this patch, I will ask
for branch approval right now.

Comment 53

[chris hofmann]

Comment on attachment 64156 [details] [diff] [review]
first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c

a=chofmann for 1.0.1  add the fixed1.0.1 keyword after checking into the branch

Comment 54

[chris hofmann]

Comment on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

a=chofmann for 1.0.1  add the fixed1.0.1 keyword after checking into the branch

Comment 55

[Jay Yan]

checked into 1.0 branch, thanks all.

Comment 56

[Jim Crumley]

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

Comment 57

[Jim Crumley]

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