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

VERIFIED FIXED

Status

()

Core
Plug-ins
--
critical
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Jim Crumley, Assigned: Sergi)

Tracking

({crash})

Trunk
Sun
Solaris
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL RTM], URL)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Marking NEW.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Summary: Shockwave/Flash pages cause crash under Solaris → Shockwave/Flash pages cause crash under Solaris

Comment 2

16 years ago
add cc

Comment 3

16 years ago
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.
(Reporter)

Comment 4

16 years ago
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

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

Comment 6

16 years ago
Can someone post a stack track or a talkback ID? Thanks!
(Reporter)

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
Created attachment 45068 [details]
log of gdb session showing crash
(Reporter)

Comment 9

16 years ago
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?
(Reporter)

Comment 10

16 years ago
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

16 years ago
I think this is a dup....but maybe Serge or Pavlov know what's going on here....
Summary: Shockwave/Flash pages cause crash under Solaris → Shockwave/Flash pages cause crash under Solaris [x-server/bit-depth]

Comment 12

16 years ago
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

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

Comment 14

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

Comment 15

16 years ago
--->reassign to Sergi by request
Assignee: av → sep
Keywords: mozilla1.0

Comment 16

16 years ago
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.  

(Assignee)

Comment 17

16 years ago
*** Bug 112576 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 18

16 years ago
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
Status: NEW → ASSIGNED
(Assignee)

Comment 19

16 years ago
Created attachment 62277 [details] [diff] [review]
one part of fix, patch for mozilla/widget/src/gtkxtbin/gtkxtbin.c
(Assignee)

Comment 20

16 years ago
Created attachment 62278 [details] [diff] [review]
second part of fix, patch for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp
(Assignee)

Comment 21

16 years ago
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.
(Assignee)

Comment 22

16 years ago
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

16 years ago
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?
(Assignee)

Comment 24

16 years ago
Sure, it's plugin itself.

Comment 25

16 years ago
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.
(Assignee)

Comment 26

16 years ago
Created attachment 64156 [details] [diff] [review]
first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c
Attachment #62277 - Attachment is obsolete: true
Attachment #62278 - Attachment is obsolete: true
(Assignee)

Comment 27

16 years ago
Created attachment 64161 [details] [diff] [review]
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

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

Comment 29

16 years ago
Are the patches currently under review?  

Updated

16 years ago
Keywords: fixedSunBranch

Comment 30

16 years ago
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
Attachment #64156 - Flags: review+

Comment 31

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

r=serge
(Assignee)

Comment 32

16 years ago
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.
Attachment #64161 - Flags: review+
(Assignee)

Updated

15 years ago
Keywords: patch, review

Comment 33

15 years ago
blizzard, could you sr=, please?
Comment on attachment 64156 [details] [diff] [review]
first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c

sr=blizzard
Attachment #64156 - Flags: superreview+
Comment on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

sr=blizzard
Attachment #64161 - Flags: superreview+
(Reporter)

Comment 36

15 years ago
Any chance of getting this into the trunk?
(Reporter)

Comment 37

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

Comment 38

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

Comment 39

15 years ago
Hi, Can anybody checkin this patch?

Thanks!

Comment 40

15 years ago
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.
Keywords: mozilla1.0 → mozilla1.0.1

Comment 41

15 years ago
will this patch be landed on 1.0 branch?

Comment 42

15 years ago
nominating for the branch
Keywords: adt1.0.1
Whiteboard: [PL RTM]
(Reporter)

Comment 43

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

Comment 44

15 years ago
changing resolution to fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 45

15 years ago
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

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

Comment 47

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

Comment 48

15 years ago
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

15 years ago
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?
(Reporter)

Comment 50

15 years ago
Created attachment 90080 [details]
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

15 years ago
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

15 years ago
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.
Status: RESOLVED → VERIFIED

Updated

15 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1+

Comment 53

15 years ago
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
Attachment #64156 - Flags: approval+

Comment 54

15 years ago
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
Attachment #64161 - Flags: approval+

Updated

15 years ago
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 55

15 years ago
checked into 1.0 branch, thanks all.

Updated

15 years ago
Keywords: adt1.0.1
(Reporter)

Comment 56

15 years ago
*** Bug 157719 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 57

15 years ago
*** Bug 162288 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.