207204 - Mozilla gcc-3.4 build hangs when opening bookmark sidebar

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[[e-mail]]

Occurs in a cvs firebird build (pulled 20030524, the day after 1.5a opened)
built using cvs gcc 3.4 (also pulled 20030524). this occurs irrelevant of
whether a fresh profile is used.

the hang does not occur with the same trunk built with gcc 3.2.2.

steps to reproduce:
1. start MozillaFirebird
2. press ctrl-b

result:
the timing of the hang varies - sometimes an empty bookmark sidebar gets painted
(i.e. without any bookmarks), sometimes it just reflows the current webpage but
doesn't get as far as painting the sidebar.

this probably also affects mozilla, but i don't yet have a gcc 3.4 build of that
to test.

it's very possible this is a regression in gcc cvs, or just something whacked
with my libs (ABI problems between versions), but until i have more info, i'll
file this here in case folks have any thoughts. ;)

Comment 1

[[e-mail]]

adding Jan to cc - i have no idea whether this relates to his recent changes or
not, though.

Comment 2

[[e-mail]]

Attachment: .mozconfig

here's my .mozconfig used w/ 3.4, for reference. i used the same thing to build
with 3.2.2, minus the 3.4-specific bits obviously.

Comment 3

[[e-mail]]

okay, i tracked down the offender... singling out one source file from amongst
the entire source tree is _not_ fun.

the culprit is content/xul/templates/src/nsXULTreeBuilder.cpp. the cause of the
problem is optimization: compiling with -fno-inline (the default) gives a
correct result; compiling with -finline produces the hang. this is in the
absence of any other optimization options. so, it's an optimizer bug in trunk gcc.

after stepping around with gdb and looking at asm output, i found an infinite
loop in nsXULTreeBuilder::IsContainerEmpty(),
http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTreeBuilder.cpp#607.

asm outputs for this method to follow.

this bug isn't fb-specific so i'm reassigning to myself, browser component.

Comment 4

[[e-mail]]

er, sorry, the previous comment should've read
nsXULTreeBuilder::IsContainerOpen(),
http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTreeBuilder.cpp#585.

so just to be clear, the .asm outputs i'm about to attach were generated by
replacing |-O2 -march=pentium3| with |-fno-inline -g3| and |-finline -g3|
respectively, on the command line to g++, for nsXULTreeBuilder.cpp only. (i did
this by calling g++ and re-linking by hand).

Comment 5

[[e-mail]]

Attachment: asm of relevant method, with -fno-inline

see comments marked as !*** for relevant portions.

it looks like an if {} else {} construct is going into a loop because the
terminating |jmp| of one of the branches, jumps back to a point before the |if|
block, when it should jump after.

Comment 6

[[e-mail]]

Attachment: asm of relevant method, with -finline

this is correct asm.

Comment 7

[[e-mail]]

i got the comments around the wrong way, obviously the -fno-inline one is
correct asm and the -finline is incorrect.

anyone have any comments? i'll probably submit this bug to the gcc folk at some
point.

Comment 8

[[e-mail]]

yet more info:

so it looks like gcc is having problems with the specific "foo()->x = y ? a : b"
construct, where foo() is an inlined function, per:

265         Row* operator->() { return &(mLink[mTop].GetRow()); }

(http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsTreeRows.h#265)

this pattern occurs in three very similiar functions in nsXULTreeBuilder.cpp,
#563, #585 & #607. in each of the three cases, gcc emits structurally correct
asm, but gets the offset of the |jmp| exit clause of the false leg wrong. it
gets it wrong by exactly the same amount in the three cases (probably because
the functions are otherwise identical); 193 bytes. hex-editing libgklayout.so
and adding 193 to the least-significant-byte of those three jmp instructions
fixes the problem.

how very strange.

Comment 9

[Bradley Baetz (:bbaetz)]

Now all you need is a self-contained test case to file in gcc's new bugzilla
install, as a regression. :)

Comment 10

[[e-mail]]

i filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11009 for this, but i really
need to get around to reducing the testcase. the preprocessed source is 1.4mb ;)

Comment 11

[[e-mail]]

this got fixed in gcc mainline a while ago.

Comment 12

[Aleksey Nogin]

Could I be seeing the same thing with "gcc (GCC) 3.3.1 20030915 (Red Hat Linux
3.3.1-5)" from one of the recent Red Hat Beta releases on i386? I have a 100%
reproducible hang in MailNews that also appears to be in
nsXULTreeBuilder::IsContainerOpen() - see bug 223356

Comment 13

[[e-mail]]

i very much doubt it. this was a 3.4-only regression.

*however*, i did try the redhat 3.3.1-5 gcc release some weeks ago, and i found
it to be buggy. (i got hangs in various places in a mozilla built using it.)

3.3.1-6 seems to not suffer these problems. go download it. ;)