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)
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
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?
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'.
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
Last Resolved: 7 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.