Closed Bug 176303 Opened 22 years ago Closed 14 years ago

Optimized build crashes in nsNodeInfoManager

Categories

(Core :: DOM: Core & HTML, defect)

Sun
Solaris
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: p.boven, Unassigned)

Details

(Keywords: crash)

System is a SunBlade 100 running Solaris 9, using Forte 7 compiler.
Compiling with optimization used to work till apx a month ago (last successfull
build was 2002-09-28-20).

ac_add_options --enable-optimize="-dalign -xO4 -xtarget=native -xbuiltin=%all
-xlibmil"

The crash happens before any window manages to open, but the profile manager
comes up if another instance of mozilla is running.

Stack backtrace:
bash-2.05$ pstack core
core 'core' of 14915:	dist/bin/mozilla-bin
-----------------  lwp# 1 / thread# 1  --------------------
 fdf5a6d4 __1cKnsNodeInfoEInit6MpnHnsIAtom_2ipnRnsNodeInfoManager__I_ (498478,
64e038, 0, 0, 4ea9c8, 0) + 60
 fdf5bc54 __1cRnsNodeInfoManagerLGetNodeInfo6MpnHnsIAtom_2irpnLnsINodeInfo__I_
(4ea9c8, 64e038, 0, 0, ffbfca84, 498478) + a4
 fde5daa8 __1cMnsXULElementHSetAttr6MipnHnsIAtom_rknJnsAString_i_I_ (61f898, 0,
64e038, ffbfcb9c, 1, fdf5bbb0) + 94
 fcf05dd8 __1cVnsGfxScrollFrameInnerMSetAttribute6MpnGnsIBox_pnHnsIAtom_ii_i_
(0, 64e6f4, 64e038, fde576e8, 1, ffbfcb9c) + 154
 fcf05158 __1cVnsGfxScrollFrameInnerGLayout6MrnQnsBoxLayoutState__I_ (64feb8,
ffbfd1a0, fe140310, ffbfcd00, fd1aae6c, 1) + 6a8
 fcf049e0 __1cQnsGfxScrollFrameIDoLayout6MrnQnsBoxLayoutState__I_ (64e33c,
ffbfd1a0, fd1b0468, fd1c08c0, 64e33c, fd01ab68) + 24
 fd018ba4 __1cFnsBoxGLayout6MrnQnsBoxLayoutState__I_ (64e370, ffbfd1a0,
ffbfd158, fd1b0654, fcf06ab0, fcf06ae0) + 20
 fd033a14
__1cKnsBoxFrameGReflow6MpnOnsIPresContext_rnTnsHTMLReflowMetrics_rknRnsHTMLReflowState_rI_I_
(64e33c, 0, ffbfd954, ffbfd898, ffbfdb94, 0) + 1fc
 fcf03b84
__1cQnsGfxScrollFrameGReflow6MpnOnsIPresContext_rnTnsHTMLReflowMetrics_rknRnsHTMLReflowState_rI_I_
(64e33c, 650a10, ffbfd954, ffbfd898, ffbfdb94, 81c40407) + 30
 fcef0acc
__1cQnsContainerFrameLReflowChild6MpnInsIFrame_pnOnsIPresContext_rnTnsHTMLReflowMetrics_rknRnsHTMLReflowState_iiIrI_I_
(fcef6a24, 64e33c, 650a10, ffbfd954, ffbfd898, 0) + 78
 fcf6a5b8
__1cNViewportFrameGReflow6MpnOnsIPresContext_rnTnsHTMLReflowMetrics_rknRnsHTMLReflowState_rI_I_
(64e000, 650a10, ffbfdc50, ffbfdb98, ffbfdb94, 0) + 7f4
 fcf40ef8 __1cJPresShellNInitialReflow6Mii_I_ (608498, fd0779ec, fe14cfb8,
80000000, 0, fd1aae6c) + 264
 fdd7308c __1cPHTMLContentSinkLStartLayout6M_v_ (5be220, 3e64, ffbfde6c,
ffbfde70, ff1ef4ac, 0) + 1d4
 fdd71324 __1cPHTMLContentSinkIOpenBody6MrknNnsIParserNode__I_ (5be220,
fdf1b0c0, fe136d68, 1, 1, 0) + 220
 fda247d4 __1cHCNavDTDIOpenBody6MpknNnsCParserNode__I_ (4c56f0, 65aa60, f,
fe135fc0, 0, fda995d0) + 34
 fda21158
__1cHCNavDTDXHandleDefaultStartToken6MpnGCToken_nJnsHTMLTag_pnNnsCParserNode__I_
(4c56f0, 1, f, 65aa60, 1, 438) + 3f0
 fda22000 __1cHCNavDTDQHandleStartToken6MpnGCToken__I_ (4c56f0, 61da90, 0, 0,
fda439a4, f) + 2d8
 fda20474 __1cHCNavDTDLHandleToken6MpnGCToken_pnJnsIParser__I_ (4c56f0, 61da90,
0, f, 1, 0) + 618 fda1f380
__1cHCNavDTDKBuildModel6MpnJnsIParser_pnMnsITokenizer_pnQnsITokenObserver_pnOnsIContentSink__I_
(4c56f0, 65bc40, 0, ffbfe240, c8, fe135fc0) + 330
 fda3b0b0 __1cInsParserKBuildModel6M_I_ (65bc40, fda9c83c, 0, fda1f050,
fda9c83c, 804e0000) + a8
 fda3ab60 __1cInsParserLResumeParse6Miii_I_ (65bc40, 804e03e8, 0, 372278,
804e03f0, 804e03ef) + 3cc
 fda3c818
__1cInsParserPOnDataAvailable6MpnKnsIRequest_pnLnsISupports_pnOnsIInputStream_II_I_
(65bc40, 616a88, 0, 616c94, fda3a794, fda9f4b0) + 144
 fe456954 __1cWnsOnDataAvailableEventLHandleEvent6M_v_ (4b3b50, fe4568b4,
fe53d0c0, 75, 80000000, ffbfe5e0) + a0
 ff157010 PL_ProcessPendingEvents (8e308, 3, ff3405f4, 0, ff1e1108, 8a390) + 248
ff1589e8 __1cQnsEventQdDueueImplUProcessPendingEvents6M_I_ (dd138, 3, ff1589b8,
ff1e1108, 49400, ff1ec884) + 30
 fe281048 __1cRour_gdk_io_invoke6FpnL_GIOChannel_nMGIOCondition_pv_i_ (207be8,
1, 2b6090, 0, 12fd10, fe28137c) + 24
 fecc6c08 g_main_dispatch (0, feceedb8, feceedb4, feceedbc, fecb1980, 1) + 104
 fecc741c g_main_iterate (1, 1, 0, feceed28, 1, fecc4ea4) + 758
 fecc7658 g_main_run (2b60a0, 0, 8f1e8, fe2817f0, 42800, fe2ca9d0) + 94
 fec0fde0 gtk_main (0, ff15a444, ff1ec9b0, ffbfe8bc, fe2ca9d0, 0) + f8
 fe2818d4 __1cKnsAppShellDRun6M_I_ (14d168, fe281670, fe2cd1b8, c1f30000, 2e000,
3) + 3c
 0001aaac __1cFmain16FippcpnLnsISupports__I_ (0, fe2f9f40, ffbfeba4, ffbfeb64,
ff1ef4ac, ff1ef688) + 9f8
 0001b40c main     (1dc88, ffbfee3c, 0, 0, 0, 80000000) + 70c
 0001576c _start   (0, 0, 0, 0, 0, 0) + 108
-----------------  lwp# 2 / thread# 2  --------------------
(snip)
Severity: normal → critical
Keywords: crash
According to mozilla -g:
Program received signal SIGSEGV, Segmentation fault.
0xfdf5a970 in __1cKnsNodeInfoEInit6MpnHnsIAtom_2ipnRnsNodeInfoManager__I_ ()
from /export/home/paul/mozbuild/mozilla/dist/bin/components/libgkcontent.so
OS: SunOS → Solaris
Just tried a new optimized build, still get exactly the same crash, using Sun
One (aka Forte 7) with the latest compiler-patches.
Crash produces a corefile about half the time, othwerwise it crashes silently
before opening any windows.
Did a make clean, removed the optimization from .mozconfig and rebuilt the
lizard. Runs fine, am typing this update while using it (Build ID: 2002120223).
Going to try and find out when this actually broke.
Tried the same on a Sun E450, Solaris 7, SunOne/F7 compiler, checkout on 2002-12-05
core file = core -- program ``mozilla-bin'' on platform SUNW,Ultra-4
SIGBUS: Bus Error
__1cKnsNodeInfoEInit6MpnHnsIAtom_2ipnRnsNodeInfoManager__I_(491968,5afebc,0,0,502538,0)
+ 60
__1cRnsNodeInfoManagerLGetNodeInfo6MpnHnsIAtom_2irpnLnsINodeInfo__I_(502538,5afebc,0,0,ffbec9f4,491968)
+ a4
After a lot of experimentation, these are my conclusions so far:

I've gone back all the way to Mozilla-1.1 for these results:

1. compiling with '--enable-optimize=-Dultra -fast -xarch=v8plusa' does not work
(though crashes differently than the above crash)
2. compiling with C(XX)FLAGS="-Dultra -fast -xarch=v8plusa" does yield a
working, optimized mozilla.
In both cases, I've set an additional -fsimple=1 in mozilla/js/src because these
files do not work when compiled with -fsimple=2 (implied by -fast)

Method 2, which at least worked back in the 1.1 days, does not work with current
and most past mozilla versions. I have not yet been able to find the point where
this broke, despite lots of checkouts and compilations.

Method 1, which seems like the 'proper' way to do this, does not work even for
Mozilla-1.1

Is anyone else able to compile an optimized Mozilla with the Sun Compiler on
Solaris? If so, what flags and settings do you use?
It's looking as if F1F7 simply cannot compile any Mozilla with more than -xO2.
I've downgraded to F6U2 with a demo license, and was able to build a 
"-fast -xarch=native -fsimple=1" build yesterday.
Whether this is a bug in the compiler or in Mozilla is unclear.
Paul Boven wrote:
> It's looking as if F1F7 simply cannot compile any Mozilla with more than -xO2.

Well, I don't have problems with that (anymore... ;-/), however it requires to
teach the compiler to be little bit less agressive with type-based aliasing.
I'll file a bug and a patch for that later this weekend (after my last bunch of
test build has finished to prove my current theories) ...

> I've downgraded to F6U2 with a demo license, and was able to build a 
> "-fast -xarch=native -fsimple=1" build yesterday.
> Whether this is a bug in the compiler or in Mozilla is unclear.

Well, based on my last weeks investigations (=welcome to SPARC assember h*ll,
doing debugging of optimised C++ code isn't fun witout having the compiler
sources... ;-/) it's at least 5/6 fault of mozilla's code (AIX's native compiler
has similar issues as Sun Workshop - and their workaround for the issue was the
same as my upcoming patch (the solution would be to rework XPCOM/XPConnect glue
and other stuff, but that's a h*llish piece of work)) and 1/6 fault of the
compiler.
Looking forward to your patches very much.
By the way, only js/src needs to be compiled with -fsimple=1, the rest works
fine with -fsimple=2 (which is the default for -fast). I could make a patch to
special-case this in js/src/Makefile.in if it is desirable to keep the rest of
the tree at -fsimple=2. Is it?
Product: Browser → Seamonkey
Moving this to the right component so that we get someone actually sees it.
Assignee: asa → general
Component: General → DOM: Core
Product: Mozilla Application Suite → Core
QA Contact: asa → ian
Is this still a problem? Seems like a compiler specific problem, though possibly
due to bad mozilla code. We had aliasing problems with nsCOMPtr before, but were
able to get around them by using compiler specific macros to flag a member as
being 'aliasable'.
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
Does this bug still occur in an up-to-date mozilla-central build?
Whiteboard: CLOSEME 2010-11-30
no response to 2 questions, so going with WFM per comment 10.
if you disagree/still see the problem, please comment in the bug.

FWIW, there is at least one sig with nsNodeInfoManager is the following but I didn't check releases and exact sigs...
http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A4.0b9pre&version=Firefox%3A4.0b7&version=Firefox%3A3.6.13&version=Firefox%3A3.6.12&range_value=3&range_unit=days&date=12%2F22%2F2010+10%3A27%3A34&query_search=signature&query_type=contains&query=nsNodeInfoManager&build_id=&process_type=any&hang_type=any&do_query=1
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: CLOSEME 2010-11-30
You need to log in before you can comment on or make changes to this bug.