11.98 KB, text/plain
356 bytes, text/plain
6.12 KB, text/plain
205.56 KB, text/plain
265.35 KB, text/plain
2.29 KB, text/plain
207.54 KB, text/plain
326 bytes, text/plain
11.79 KB, image/png
Created attachment 206961 [details] GDB output including "where" command output Apologies for not knowing how to bring up GDB on the core file in such a way that the stack trace can be fully displayed symbolically. I'm willing to do another backtrace if someone can give a pointer to how to bring up GDB to make the backtrace more meaningful.
Severity: normal → critical
Component: Keyboard Navigation → General
QA Contact: keyboard.navigation → general
Summary: back button causes segmentation violation; follows document window going all green → back button causes crash; follows document window going all green
Version: unspecified → 1.5 Branch
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 Firefox/1.6a1 ID:2005122801 WFM
Could you post your talkback ID here please? (http://kb.mozillazine.org/Talkback)
Please forgive me for being a little slow, but about a half hour of searching, starting with the supplied mozillazine URL, still leaves me clueless about how to enable talkback so I can submit a talkback report and send the ID. I see a few talkback.jst files in the browser and xpinstall directories in the source tree I used when compiling Firefox, but I don't see anything about talkback in the installation area or under tools->extensions. The 'how to build' document I have says to not use --enable-extensions. The crash still happens for me with Firefox 126.96.36.199 and Mandriva 2006. I'd be happy to recompile (if necessary) and send a talkback ID. Would you please be so kind as to loan me a clue as to how to enable talkback? Thanks.
please bear with us, email@example.com shouldn't have suggested talkback to you. you don't have symbols. rebuild w/ --enable-debug --disable-debug w/o --enable-strip and crash again. http://www.mozilla.org/unix/debugging-faq.html
Thanks for the instructions and the URL to the FAQ. Just to clarify, are the instructions correct, to both _enable_ and _disable_ debug? > rebuild w/ --enable-debug --disable-debug w/o --enable-strip and crash again. Or, should it be --enable-debug and --disable-strip? Before rebuilding, I plan to try the binary package just in case the crash happens with it. Again, thanks.
afaik the default is --disable-strip, so i was more afraid of you having an --enable-strip, but sure you can remove any --enable-strips and add a --disable-strip
Created attachment 212978 [details] my .mozconfig file for attempt at debug build I tried the pre-built binary package, and it does not show either the green screen or the crash. This attachment is the .mozconfig file I used to (attempt to) build a debuggable Firefox 188.8.131.52. The build appears to have finished successfully, but the debugging session doesn't get very far at all. I'll attach the output of a session. I have to use gtk (rather than gtk2), because there are hideous font geometry calculation problems with gtk2, most notably that most text looks like it is double-spaced. The ...optimize=-O2 is to work around the problem that causes 100% CPU use on startup and no window creation. (The reason I did not file a bug report about the font size problems with gtk2 is I don't know enough about font issues to make a competent description.)
Created attachment 212981 [details] 'script' of attempted debugging session So far, all attempts to run gdb on Firefox have blown up early on with something similar to the segmentation fault shown in this attachment. Attempts to run Firefox without the debugger show a similar problem but without the debugger's verbosity. Oh, by the way, since the original report, I have switched to Mandriva 2006 and Firefox 184.108.40.206. The original problem symptoms have not changed: after clicking on "news media" story link, window eventuall becomes solid green; 'back' button crashes browser. At this point, my attempts to bring up the debuggable Firefox have failed, with and without the debugger. Nothing in the FAQ appeared to me to be relevant. I'm stumped and begging for a clue. Thanks in advance.
hrm, that's not expected export NO_EM_RESTART=1 export NSPR_LOG_MODULES=all:5 ./run-mozilla.sh -g -d gdb ./firefox-bin run (crash) info locals info threads where list if you actually crash on the line you listed in the crash you attached, try: p nsComponentManagerLog if it's null, try: b nsComponentManagerImpl::Init run (if it doesn't let you actually do the run/restart stuff, the unix debugging faq should explain how you can properly set this breakpoint) oh, you should definitely rebuild if you switch mozconfigs like this, i.e. if you *didn't* do a clobber build between the first build and the one w/ my requested mozconfig flags, then you definitely needed to (sorry i didn't mention it).
Created attachment 213093 [details] typescript from debugging attempt I agree that the crash during initialization, before first browser window creation, is not expected. (Apologies is this rather large attachment is unwelcome. I'll be happy to distill things if that would be more appropriate.) Thanks for the comment about needing to start with a clean slate when changing .mozconfig. I like overkill, so I remove the entire source/build area when making such a change, then reextract from the source tarball. That way, I _know_ it's clean. I followed (or at least attempted to follow) the instructions, with adjustments in shell syntax for my use of /bin/csh. The early crash appears to have happened at the same place as before, and nsComponentManagerLog did not appear to be null. Unfortunately, I get lost in Mozilla/Firefox code so quickly I don't have a clue where to go from here.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/components/nsNativeComponentLoader.cpp&rev=MOZILLA_1_8_0_BRANCH&cvsroot=/cvsroot&mark=400#372 hey, i don't get get lost in mozilla code easily, and i'm as lost as you are. you did all the right things. next step is probably help disassembly or something plus info registers. i.e. find out precisely what it's complaining about at least at an asm level. alternatively. you could first try valgrind, since you're dying very early (be sure to use all the env vars we're already using) ./run-mozilla.sh -g -d `which valgrind` ./firefox-bin it might tell us which thing is actually dying. oh, one other thing to run: ./run-mozilla.sh `which ldd` ./firefox-bin if you're sick of ./run-mozilla.sh, you can do: ./run-mozilla.sh /bin/csh and then do everything else from inside that shell e.g. ./firefox-bin valgrind ./firefox-bin ldd ./firefox-bin from gdb, output of info shar might be useful...
Component: General → XPCOM
Product: Firefox → Core
QA Contact: general → xpcom
Version: 1.5.0.x Branch → 1.8 Branch
Created attachment 213144 [details] typescript of valgrind session This is the typescript of the valgrind session. Toward the bottom, just before the signal 11, it mentions an invalid read of size 4, at what looks like an address of 4. Prior to this point, it mentions many times a conditional branch that (allegedly) depends on an uninitialized value.
Created attachment 213145 [details] typescript of ldd session This is the typescript of a 'ldd' session. I took the liberty of inserting the '-g -d' options in the same places as the earlier instructions on running gdb and valgrind.
Created attachment 213146 [details] typescript of gdb 'info shar' This is the typescript of a gdb run with 'info shar' along with the other commands from attachment 212981 [details]. At this point, I'm back to being stumped. Attachment 212978 [details] is the .mozconfig I used to build this attempt at a debuggable browser, on the off chance it might be useful for someone with more Mozilla debugging skill than my epsilon^4.
Robert, is it possible for you to try a trunk build? Just knowing whether this is also an issue on trunk will give us a good starting point...
Would my guess be correct that "trunk build" means to download the source from CVS and build that? It would be at least a few days before I could make an attempt. I'd be grateful for a pointer to any specific instructions I would need. For example, would I need to modify my .mozconfig file? Would I use the same commands to build/compile? I think I once saw a page that described how to download from CVS. If convenient, a pointer would same me some time searching. Thanks.
Robert, you could also try a prebuilt binary; they're built every day and uploaded to the FTP server. See ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk That's assuming you're seeing the bug with Mozilla.org builds to start with, of course. Thanks for helping out with tracking this down!
I tried the 220.127.116.11 binary package, and it did not show the green screen, crash on back button, or crash on startup. I take it this means there would be no significant value in trying the binary trunk. Please inform if there would be some value in trying the binary trunk. Also, please inform if I need to use a .mozconfig file with any differences from the one in the second attachment. It appears to be attachment #212978 [details], though that does not show up in the above list. It will probably be a few days before I can do the trunk source download and build, because I'm in the middle of moving my wife's computer to Mandriva 2006. Thanks for your help on this report.
So if I understand this correctly, the Mozilla.org builds don't show the problem? But your own builds do, right? What build were you using when you initially ran into the problem? One from your distribution? If so, I would be interested in the following: 1) What happens if you remove the "ac_add_options --enable-optimize=-O2" line from your .mozconfig? Does the bug go away? 2) What about if you just change -O2 to -Os? If the answer to either of those questions is "yes", then: 3) What compiler are you using?
Answers to questions: The binary packages built by mozilla.org don't show the problem. My own builds with the optimize=-O2 workaround and gtk(1) instead of gtk2 do show the green screen and crash on back button problems. A build with debug and nostrip gets the segmentation fault on startup. Except when testing something, I always use my own build because I need my patch for the geometry X resource issue (bug #20573). Without the --enable-optimize=-O2 added option in the .mozconfig, the browser uses 100% CPU and never puts up a window. That happens even without my patch. This is bug #283130. I have not yet tried -Os. My compiler is gcc-4.0.1-5mdk, from Mandriva 2006 (updated regularly). The green screen and crash on back button was originally seen with Mandriva LE2005/10.2 and gcc-3.4.3-7mdk. Again, it will be a few days before I can attempt any more builds. Thanks for the efforts to help solve this.
Benjamin, do you know whether we have known issues with those compilers or build options or anything like that?
I haven't heard of optimization problems before, but assuming that this is the same as bug 283130 and we're getting an optimizer-induced bug in nsAttrValue::ToString, the loop in the eEnum case looks like the easiest for an optimizer to unwind incorrectly: http://lxr.mozilla.org/mozilla/source/content/base/src/nsAttrValue.cpp#350 It would be interesting to see the assembly for this function in -O2 and -Os cases.
I just tried the nightly binary trunk build, firefox-1.6a1.en-US.linux-i686.tar.bz2, dated March 13, 12:40pm. It shows the problem of 100% CPU on startup, the one I had to use the optimization switch for, bug #283130. I let firefox-bin accumulate just over 2 minutes of CPU time on a 2.4GHz Pentium 4"a" (Northwood, IIRC), and it had grown to 205-206MB in virtual size. I have not seen this problem with the production release versions. The trunk build appears to be built for gtk2, so it leaves droppings behind in /tmp and $HOME/tmp, but at least the gconfd process now does eventually go away by itself. I'm going to attempt the build from CVS. Any suggestions for that path?
Mostly good news in terms of the original symptoms: the browser no longer crashes, but the window still goes green. Downloading from CVS and building went well with the original non-debug .mozconfig file, using -O2 optimization, gtk1, strip, no debug. The browser window still goes green, but that may well be the correct behavior. Using the 'back' button does not crash the browser. Is there anything else that ought to be done on this report? In any case, thanks for all the help with instructions for doing the builds and trying to track down the problems' causes.
Hmm... What does the "goes green" thing look like? Is it transient or permanent?
So the green just covers the content area (not the browser UI)? And if you load some other page after this it looks fine? As in, the UI is not being corrupted, the page content is just replaced with this green for this one page?
If by "UI" you mean the menu bar, tool bar, location bar, and status bar then that is correct. Only the page content is overwritten by the green.
Could you attach a screenshot of this green behaviour?
Created attachment 215171 [details] screenshot of Firefox window with green washout This is a screenshot of the Firefox window, built from March 13 CVS source with gtk1 and -O2, as previously described. This is after the green washout has fully taken place. If you wanted a shot of what the window looks like before the green washout happens, that would be tricky but maybe possible.
hrm. so, at a guess from where the green might come from... is it your default background color by chance?
I don't believe I have set an explicit background color. If I had set one, it certainly would not be that shade of green. When I go to Edit -> Preferences, then the Content tab, then click on Colors, it shows text as black, background as white, "Use system colors" not active, and "Allow pages to choose their own colors, ..." active. I was guessing the green background/washout was coming from the green in the puzzle piece icon that shows up whenever something wants the Flash plugin I have not installed.
On the off chance this info would be useful, 18.104.22.168 has the same behavior as 22.214.171.124. After clicking on the link, the content area goes solid green. An attempt to go "back" causes the browser to do a segmentation fault.
After installing the flashblock extention and the Flash plugin, the symptoms seem to have gone away.
WFM also Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a2pre) Gecko/20070206 Minefield/3.0a2pre -> WORKSFORME per #36
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.