8.56 KB, text/plain
1.85 KB, patch
|Details | Diff | Splinter Review|
913 bytes, patch
|Details | Diff | Splinter Review|
1.47 KB, text/plain
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).
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Shockwave/Flash pages cause crash under Solaris → Shockwave/Flash pages cause crash under Solaris
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
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
Created attachment 62277 [details] [diff] [review] one part of fix, patch for mozilla/widget/src/gtkxtbin/gtkxtbin.c
Created attachment 62278 [details] [diff] [review] second part of fix, patch for mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp
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.
Created attachment 64156 [details] [diff] [review] first part of new patch, unified diff for mozilla/widget/src/gtkxtbin/gtkxtbin.c
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.
Sergi, Great work! I have test your new patch.Now the flash seems so pretty on Solaris.
Are the patches currently under review?
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+
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.0 → mozilla1.0.1
will this patch be landed on 1.0 branch?
nominating for the branch
Whiteboard: [PL RTM]
*** Bug 154210 has been marked as a duplicate of this bug. ***
changing resolution to fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 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?
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.
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.
*** Bug 157719 has been marked as a duplicate of this bug. ***
*** 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.