Closed Bug 85958 Opened 23 years ago Closed 22 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect)

Sun
Solaris
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: crumley, Assigned: sep)

References

()

Details

(Keywords: crash, Whiteboard: [PL RTM])

Attachments

(4 files, 2 obsolete files)

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).
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
add cc
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.
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. 
Also occurs on Solaris 8 with, for example, build 2001072210.
Can someone post a stack track or a talkback ID? Thanks!
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.
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?
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 ()
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]
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. :)
Could this fault be invoked by the absent of X's 16 bit depth?
*** Bug 114047 has been marked as a duplicate of this bug. ***
--->reassign to Sergi by request
Assignee: av → sep
Keywords: mozilla1.0
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.  

*** Bug 112576 has been marked as a duplicate of this bug. ***
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
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.
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.
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?
Sure, it's plugin itself.
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.
Attachment #62277 - Attachment is obsolete: true
Attachment #62278 - Attachment is obsolete: true
New patch posted, works fine. Right button in plugin shows menu.
Please review.
Sergi, 
Great work! 
I have test your new patch.Now the flash seems so pretty on Solaris. 
Are the patches currently under review?  
Keywords: fixedSunBranch
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 on attachment 64161 [details] [diff] [review]
second part of new patch, unified diff for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp

r=serge
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+
Keywords: patch, review
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+
Any chance of getting this into the trunk?
*** Bug 148486 has been marked as a duplicate of this bug. ***
*** Bug 144623 has been marked as a duplicate of this bug. ***
Hi, Can anybody checkin this patch?

Thanks!
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.0mozilla1.0.1
will this patch be landed on 1.0 branch?
nominating for the branch
Keywords: adt1.0.1
Whiteboard: [PL RTM]
*** Bug 154210 has been marked as a duplicate of this bug. ***
changing resolution to fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
Jay: w/o verification it wont be approved for sure.
Could you verify this and mark so, before requesting an approval, please?
Sure, Serge, we will take care of it till it is checkined to branch.
thanks. 
Jay
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?
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?
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.
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
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
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 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+
checked into 1.0 branch, thanks all.
Keywords: adt1.0.1
*** Bug 157719 has been marked as a duplicate of this bug. ***
*** Bug 162288 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: