We're seeing frequent crashes of various versions of firefox on RHEL 5 when used with the internal clearspace instance (docspace). I will gdb backtraces and a coredump of 3.0.2 (the only one we could find debuginfo pkgs for), but we've experienced crashes on 3.0.6, and the 3.0.7 pkg I found in brew the other day. We do not yet have a reliable reproducer, but it does seem to happen more when interacting w/ the the tinymce editor embedded within clearspace. If you can point us towards more recent packages and/or debuginfo packages, we'll happily try to help come up w/ more relevant core dumps.
Created attachment 334058 [details] output of gdb's bt command Stacktrace from gdb
Created attachment 334059 [details] More verbose backtrace of all threads from gdb Backtrace for all threads
Please install debuginfo packages and attach the bactrace again...
Created attachment 334558 [details] backtrace w/ more debuginfo's installed Ok, here's the expanded backtrace w/ xulrunner and other debuginfo's installed
Martin, Go ahead and try creating a new document; also, Sudhir and I can probably help you via IRC if need be. We hang out in #collaboration TinyMCE refers to the javascript WYSIWYG editor invoked for any document (or other content) creation or editing.
I can't reproduce the crash. But it looks like NULL pointer deference like https://bugzilla.mozilla.org/show_bug.cgi?id=474303. This one (and some others) are already fixed in upcoming 3.5 (former 3.1).
If you can reproduce the crash - can you test official mozilla binaries too? latest 3.0.7 and 3.1 beta...
Do we have 3.1 packages we could try w/ RHEL5? Please note that we have tried the 3.0.7 packages that were found in brew, and reproduced the crash with them. We couldn't provide a stack trace b/c we didn't have the debuginfo pkgs.
GSS is one of our biggest users of the internal Clearspace instance; this bug greatly impacts their ability to effectively perform their daily activities. I see that you are having difficulty reproducing the problem (we also cannot reproduce it consistently)- is there anything further our team can do to help you troubleshoot this issue?
(In reply to comment #12) > I can't reproduce the crash. > > But it looks like NULL pointer deference like > https://bugzilla.mozilla.org/show_bug.cgi?id=474303. This one (and some others) > are already fixed in upcoming 3.5 (former 3.1). Martin - how certain are we that the issue is already resolved in 3.5 (3.1)? And, do we know when this will be released? Thanks, Sam
Please install firefox 3.1b3 at your rhel-5 box (from ftp://ftp.mozilla.org/pub/firefox/nightly/3.1b3-candidates/build2/linux-i686) and try to reproduce the problem with it. This build has the mentioned fix.
So far, haven't been able to reproduce the issue on the 3.1 build. Any chance we can obtain some beta 3.1 packages for testing (and possible deployment) w/ RHEL 5 CSB?
Created attachment 335605 [details] output of gdb's bt command Stacktrace from gdb Experienced crash again on FF 3.0.7 with the patches applied.
Okay, new debug builds are available at http://porkchop.devel.redhat.com/~stransky/xulrunner/ - please attach a backtrace from this build, it should provide more info...
My whole OS got rebooted after I installed the new debug builds and could not capture any stacktrace. This happenned when I went to spaces tab of clearspace admin console.
Clearing needinfo on me
Created attachment 336041 [details] firrefox bug report in case it's useful, firefox generated this report for me the other day when i experienced this crash.
Sorry but this one is useless...we need a backtrace from gdb.
Created attachment 336482 [details] Back Trace from the crash I had on RHEL 5.3 FF 3.0.7
Comment on attachment 336482 [details] Back Trace from the crash I had on RHEL 5.3 FF 3.0.7 This backtrace is incomplete or it's not relevant to the reported crash...
What's the status on this? Do we have a new build we can test? -Sam
Comment #23 is still valid.
(In reply to comment #31) > Comment #23 is still valid. Thanks - I installed it yesterday. So far I am not experiencing anything bad like in comment #24. I saw a couple of crashes right before installing this, but attempts to reproduce after installing have not been successful. Was this just a debug package or does it include a potential fix?
It's only a debug package w/o any fix.
Is this helpful? Just had a crash but looks like a core did not get generated: Program /usr/lib/firefox-3.0.5/firefox (pid = 10681) received signal 11. Stack: UNKNOWN 0x32e420 UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x009691AF] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x01013D31] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x0100B98E] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x0100BE94] UNKNOWN [/usr/lib/libgtk-x11-2.0.so.0 +0x00130060] g_closure_invoke+0x0000012B [/lib/libgobject-2.0.so.0 +0x00008F0B] UNKNOWN [/lib/libgobject-2.0.so.0 +0x00019E83] g_signal_emit_valist+0x00000667 [/lib/libgobject-2.0.so.0 +0x0001B147] g_signal_emit+0x00000029 [/lib/libgobject-2.0.so.0 +0x0001B539] UNKNOWN [/usr/lib/libgtk-x11-2.0.so.0 +0x002445D8] gtk_main_do_event+0x000003F5 [/usr/lib/libgtk-x11-2.0.so.0 +0x0012A7E5] UNKNOWN [/usr/lib/libgdk-x11-2.0.so.0 +0x0002B7FF] gdk_window_process_all_updates+0x00000097 [/usr/lib/libgdk-x11-2.0.so.0 +0x0002BA47] UNKNOWN [/usr/lib/libgdk-x11-2.0.so.0 +0x0002BAC5] UNKNOWN [/lib/libglib-2.0.so.0 +0x000295E1] g_main_context_dispatch+0x00000182 [/lib/libglib-2.0.so.0 +0x0002B342] UNKNOWN [/lib/libglib-2.0.so.0 +0x0002E31F] g_main_context_iteration+0x00000065 [/lib/libglib-2.0.so.0 +0x0002E885] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x01010BAD] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x01032C81] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x01033100] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x011BBB93] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x011579CD] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x010333D6] UNKNOWN [/usr/lib/xulrunner-1.9/libxul.so +0x00D64E45] XRE_main+0x00002A4C [/usr/lib/xulrunner-1.9/libxul.so +0x001AAB28] UNKNOWN [/usr/lib/firefox-3.0.5/firefox +0x000010A2] __libc_start_main+0x000000DC [/lib/libc.so.6 +0x00015E8C] Sleeping for 300 seconds. Type 'gdb /usr/lib/firefox-3.0.5/firefox 10681' to attach your debugger to this thread. db /usr/lib/firefox-3.0.5/firefox 10681^[OH^[[D (npviewer.bin:10703): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed (npviewer.bin:10703): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed (npviewer.bin:10703): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed /usr/lib/firefox-3.0.5/run-mozilla.sh: line 131: 10681 Killed "$prog" ${1+"$@"}
Created attachment 337842 [details] from firefox bug reporting tool This might also be useless - attaching just in case. I do have the xulrunner-debuginfo installed from comment 23
The backtrace looks partially useful: #5 0x00000000 in ?? () No symbol table info available. #6 0x01958de3 in nsViewManager::DispatchEvent (this=0xe6af9d0, aEvent=0xbfb43c58, aStatus=0xbfb43b70) at nsViewManager.cpp:1079 vm = (nsViewManager *) 0xe6af9d0 didResize = 0 event = (nsPaintEvent *) 0xbfb43c58 view = (class nsView *) 0x10455db8 region = {mRawPtr = 0xdc9e680} It's from nsViewManager.cpp:1079: vm->UpdateView(vm->mRootView, NS_VMREFRESH_NO_SYNC); But the vm is non null so we're missing some debug informations here (I guess the bactrace comes from the optimized build, right?) My best guess is that vm->mRootView == NULL, so it crashes in: NS_IMETHODIMP nsViewManager::UpdateView(nsIView *aView, PRUint32 aUpdateFlags) { // Mark the entire view as damaged nsView* view = static_cast<nsView*>(aView); nsRect bounds = view->GetBounds(); view->ConvertFromParentCoords(&bounds.x, &bounds.y); return UpdateView(view, bounds, aUpdateFlags); } When you manage to crash the browser again, can you please attach content of vm? (by p* vm)
(In reply to comment #36) > When you manage to crash the browser again, can you please attach content of > vm? > (by p* vm) Sorry - can you spell that out a bit more? what are the exact steps i need to take?
When firefox crashes in gdb, select a stack frame in function "nsViewManager::DispatchEvent()" by gdb command 'frame' or 'up'. Then print content of vm variable (by gdb command 'p* vm') and attach it here.
It looks like nsViewManager is already deleted and no longer valid. Okay I'll try to find a patch for it.
Hm, I believe the bug is unfixed in the current 3.1 beta 3. Please try to run firefox inside valgrind. Run 'valgrind --trace-children=yes /usr/bin/firefox' and try to reproduce the crash. Then please do the same with firefox binary from comment #17 and attach the logs here.
I've been getting crashes almost every time I tried to edit, with certain pages causing the crash every time. Now I'm trying with 3.1 beta 3 and no crash occured so far. Alhough, I'm not using Fedora nor RHEL, just noting FYI.
Firefox fails to start the browser window when run in valgrind. It exits after ~4min. There is quite a bit of output, but since it was not possible to even attempt to duplicate the problem I'm not sure how useful it will be. Attaching.
Created attachment 338535 [details] valgrind output, browser fails to start
OK, I cannot reproduce this with standard RHEL 5.3 with firefox-3.0.7-1.el5 and xulrunner-1.9.0.7-3.el5, which is what I have in BRQ satellite. So we need a little bit more information on this: 1) The best thing which can happen to this bug would be if somebody *FROM GSS* in Brno would be able to reproduce this and then hand the computer to Martin or Jan. Could you try, please? 2) If not that could you try to reproduce it with firefox being started in safe mode, i.e., run firefox -safe-mode on in gnome-terminal. Could you do that? 3) Backtrace is still not complete, it could be useful, but still we could get better. Could you please (before doing any further testing) run (as root) sed -i -e '/^enabled=/s/0/1/' /etc/yum.repos.d/rhel-debuginfo.repo yum install yum-utils debuginfo-install firefox That should make much better backtraces. Thank you very much in advance for any information.
I've forwarded this to several individuals working on the problem, but it occurred to me that I should attach to the ticket for posterity. For what it's worth: I can consistently (100%) crash Firefox in Clearspace using the following set of specific steps. I only spent an hour or so on the issue, so I can't provide much analysis. However, when it naturally happens to me, I noticed that it was always happened when I was editing a previously created document with complex content in a second+ tab. I used this information to find the following sequence that will consistently crash (for me, at least). There are two main parts that follow what I experience naturally: (1) creating the document and (2) editing the document. I have been able to get into a loop where the second sequence crashes again and again. I hope this provides some assistance; please let me know how else I can assist you in your efforts. (prep sequence:) . Start firefox . Open new tab . Go to a space (e.g. https://docspace.corp.redhat.com/clearspace/community/project/knowledge?view=overview) . Open "Create a new document" in a new tab . Click Continue (Write a New Document) . Enter any name for the document like "test123" for the document . Switch to HTML . Paste attached HTML as the content . Click Publish . Quit Firefox & click "Save and Quit" (edit sequence:) . Start firefox (which should open two tabs from previous session) . Click OK to any authentication windows that pop up. . Click to focus on the second tab . Click on "Edit document" link *CRASH*
Created attachment 340086 [details] HTML for the a sample document that crashes when editing
I've found a way how reproduce it pretty reliably so you can take a break with the reproducers for now...
Thanks Martin.. I was able to re-create it multiple times with the settings said above.
I removed "nspluginwrapper" from my CSB system, but I am still seeing the crash.
Please try to reproduce with the lately released packages RHEL-5: firefox-3.0.9-1.el5 xulrunner-1.9.0.9-1.el5 don't forget to install flash plugin (although it doesn't look significant here). nspluginwrapper doesn't matter.
(In reply to comment #72) > Please try to reproduce with the lately released packages RHEL-5: > > firefox-3.0.9-1.el5 > xulrunner-1.9.0.9-1.el5 > > don't forget to install flash plugin (although it doesn't look significant > here). nspluginwrapper doesn't matter. Just to clarify - do we think there is a patch in here that will address the isue, or is this just a test to see if the new version fixes it? Have you been able to reproduce on the new version? Thanks, Sam
firefox-3.0.9/xulrunner-1.9.0.9 should crash too, I don't see any special fix here but Tomas can't reproduce the crash with it.
(In reply to comment #72) > Please try to reproduce with the lately released packages RHEL-5: > > firefox-3.0.9-1.el5 > xulrunner-1.9.0.9-1.el5 > > don't forget to install flash plugin (although it doesn't look significant > here). nspluginwrapper doesn't matter. Is it possible to get these another way? I'm on a Mac platform.
There is the errata there - http://rhn.redhat.com/errata/RHSA-2009-0436.html
Please try to reproduce the bug with the latest firefox package. It's because I'm going to escalate the issue upstream (at mozilla.org).
Filled upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=490425
Martin - are your efforts continuing on this or are we depending on Mozilla 100% here? I just want to make sure I understand where we are. Can you not reproduce this anymore on your system? Thanks, Sam
Yes, I can't reproduce this anymore on my system (with 3.0.9) so I'm asking you for reproduction.
FYI, I reproduced the issue immediately after updating to latest 3.0.10. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
new packages with fix are at http://porkchop.devel.redhat.com/~stransky/xulrunner/ (xulrunner-1.9.0.10-1.test)
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #82) > new packages with fix are at > http://porkchop.devel.redhat.com/~stransky/xulrunner/ > (xulrunner-1.9.0.10-1.test) Martin - any details on what changed? were you able to reproduce?
xulrunner-1.9.0.10-1.test contains a patch which should fix this issue (or at least help to move forward) and I can't reproduce the crash with the latest official&fixed packages.
Out of curiosity, is it possible to (temporarily?) provide Mozilla a public instance of Clearspace? It would be helpful if they can reproduce the problem, too.
(In reply to comment #89) Try wiki.jboss.org. It uses Clearspace 2.5. Anyone can create an account there then write a document in the wiki space.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1095.html