Closed Bug 321670 Opened 19 years ago Closed 18 years ago

back button causes crash; follows document window going all green

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
1.8 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rm.riches, Unassigned)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(9 files)

GDB output including "where" command output
11.98 KB, text/plain
Details
my .mozconfig file for attempt at debug build
356 bytes, text/plain
Details
'script' of attempted debugging session
6.12 KB, text/plain
Details
typescript from debugging attempt
205.56 KB, text/plain
Details
typescript of valgrind session
265.35 KB, text/plain
Details
typescript of ldd session
2.29 KB, text/plain
Details
typescript of gdb 'info shar'
207.54 KB, text/plain
Details
.mozconfig used for non-debug 1.5.0.1 and CVS trunk build
326 bytes, text/plain
Details
screenshot of Firefox window with green washout
11.79 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051209 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051209 Firefox/1.5

Clicking on a link with Flash-related javascript causes document window to go all green (after initially rendering content).  Then, back button causes segmentation violation and core dump.  Neither the all-green window nor the segmentation violation happen in 1.0.7.


Reproducible: Always

Steps to Reproduce:
1. Bring up http://www.lds.org
2. In the right-hand column, locate "Newsroom for news media", locate the (or a) story link.
3. Left-click on the story link.
4. After document has finished displaying, use Alt-Left-Arrow for "Back".
Actual Results:  
After clicking on the story link, the document window is painted with content.  Then, the document window is overwritten with solid bright green, making all content invisible.  The all-green washout happens even if a new browser window is created via right-click.

After attempting to go "back", Firefox produces a segmentation violation and core dump.

Expected Results:  
After clicking the story link, the rendered content should remain and not be washed out with all green.

After attempting to go "back", Firefox should not produce a segmentation violation.

The all-green washout appears to be caused by the Javascript code in or called by the news story page that appears to try to ask the user to install the Flash player.  I do not have the Flash player installed--and will not install one due to the audit provision in the player's EULA.

My browser is built from source, using -O2 optimization (to work around the 100% CPU use hang on startup), and using gtk1 (to work around hideous font geometry calculation errors with gtk2).  I compile with a small patch I wrote (for [Bug 20573]) to make the "geometry" X resource work.  My 1.0.7 built with the same patch does show neither the all-green problem nor the segmentation violation.

I will attempt to attach a stack backtrace from GDB (the "where" command).
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
Keywords: crash
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 1.5.0.1 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, bugzilla@tecnocode.co.uk 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
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 1.5.0.1.  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[1] (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.)
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 1.5.0.1.  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).
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
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.
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.
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 1.5.0.1 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?
Here's a play-by-play of what happens:

I bring up the built-from-CVS Dear Park Alpha 2 and go to www.lds.org.

I left-click on the headline link under "Newsroom for news media"
about 25% of the way down the right-hand column.

What appears to be a reasonable web page loads, with a block in the
upper center, something like "Click here to download plugin" with a
green jigsaw puzzle piece icon.  There is tool-bar-like widget below
the usual toolbars that says "Additional plugins are required to
display all the media on this page."

Between a half-second and a second passes.

Spontaneously, the page content is replaced by solid bright yellowish
green with a jigsaw puzzle piece icon in a small white box in the
upper left.  The "missing plugins" tool-bar-like widget remains.
Other than the toolbars, "missing plugins" tool-bar-like widget, and
status bar, the green washout consumes the entire browser window.

I have a hunch the green washout is caused by Javascript code that
tries to ask the user to download and install the Flash plugin.  (I
refuse to install this plugin or player because of the 'audit' clause
in the EULA.)  Some time ago, I tried playing with the Javascript, but
I was not able to accomplish anything useful in terms of getting rid
of the green washout.

Please note that this browser, built from March 13 CVS trunk source,
is using gtk1 and the -O2 optimization option to get around the 100%
CPU bug mentioned earlier.  The reason for gtk1 (rather than gtk2) is
to avoid the serious font geometry calculation problems with gtk2 that
(among other things) cause much page text to look double-spaced.

With 1.5.0.1, pressing Alt-Left-arrow or the back button would crash
the browser.  With the CVS source, the browser does not crash.

The green washout is permanent, at least for several minutes while I
typed everything from "What appears ..." above to this.
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?
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, 1.5.0.2 has the same behavior as 1.5.0.1.  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
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: