Closed Bug 30427 Opened 25 years ago Closed 24 years ago

mozilla dumps core

Categories

(Core :: JavaScript Engine, defect, P3)

SGI
IRIX
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jsd, Assigned: var)

Details

Attachments

(2 files)

first startup gives: MOZILLA_FIVE_HOME=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin LD_LIBRARY_PATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin:/lib:/usr/lib:/global/arch/mips-sgi-irix6.5/lib:. SHLIB_PATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin LIBPATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin MOZ_PROGRAM=viewer MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering begins. *** Registering nsDirectoryViewerModule components (all right -- a generic module!) nsFindComponent registration successful *** Registering datetime components (all right -- a generic module!) *** Registering uconv components *** Registering nsWalletViewerModule components (all right -- a generic module!) *** Registering nsStreamConvModule components (all right -- a generic module!) *** Registering nsPrefMigrationModule components (all right -- a generic module!) *** Registering nsTextServicesModule components (all right -- a generic module!) *** Registering nsBookmarkModule components (all right -- a generic module!) *** Registering nsRDFModule components (all right -- a generic module!) *** Registering shistory components (all right -- a generic module!) *** Registering Network Data Cache components (all right -- a generic module!) *** Registering nsWalletModule components (all right -- a generic module!) *** Registering nsStringBundleModule components (all right -- a generic module!) *** Registering XPInstallUpdateNotifierModule components (all right -- a generic module!) *** Registering nsPrefModule components (all right -- a generic module!) *** Registering nsFileProtocolModule components (all right -- a generic module!) *** Registering nsToolkitModule components (all right -- a generic module!) *** Registering nsRelatedLinksModule *** Registering history components *** Registering nsMorkModule components (all right -- a generic module!) *** Registering locale components *** Registering nsImportServiceModule components (all right -- a generic module!) *** Registering xpconnect test components (all right -- a generic module!) *** Registering nsRDFDOMViewerModule components (all right -- a generic module!) *** Registering nsSearchModule *** Registering UcharUtil components (all right -- a generic module!) *** Registering nsConvModule components (all right -- a generic module!) *** Registering net components (all right -- a generic module!) *** Registering nsTextImportModule components (all right -- a generic module!) *** Registering nsSecurityManagerModule components (all right -- a generic module!) *** Registering nsSoftwareUpdate components (all right -- a generic module!) *** Registering nsMIMEService components (all right -- a generic module!) *** Registering nsMsgNewsModule components (all right -- a generic module!) *** Registering nsTransactionManagerModule components (all right -- a generic module!) *** Registering xpconnect components (all right -- a generic module!) *** Registering finger components (all right -- a generic module!) *** Registering keyword components (all right -- a generic module!) *** Registering nsBrowserModule components (all right -- a generic module!) nsUnknownContentTypeHandler registration successful *** Registering layout components *** Registering appshell components (all right -- a generic module!) *** Registering nsUCvTWModule components (all right -- a generic module!) RegSelf Unicode to Big5 converter complete RegSelf Unicode to x-x-big5 converter complete RegSelf Big5 to Unicode converter complete *** Registering CharDet components *** Registering nsJarModule components (all right -- a generic module!) *** Registering nsDataProtocolModule components (all right -- a generic module!) *** Registering nsTimeBomb components (all right -- a generic module!) *** Registering nsHTTPHandlerModule components (all right -- a generic module!) nsStreamTransfer registration successful *** Registering nsProfileModule components (all right -- a generic module!) *** Registering nsJarProtocolModule components (all right -- a generic module!) *** Registering nsEditorModule components (all right -- a generic module!) *** Registering nsSampleModule components (all right -- a generic module!) *** Registering nsChromeModule components (all right -- a generic module!) *** Registering nsCJVMManagerModule components (all right -- a generic module!) *** Registering nsMsgComposeModule components (all right -- a generic module!) *** Registering nsVCardModule components (all right -- a generic module!) *** Registering javascript: protocol components (all right -- a generic module!) *** Registering nsLWBrkModule components (all right -- a generic module!) *** Registering mozJSComponentLoader components (all right -- an almost-generic module!) *** Registering nsMimeEmitterModule components (all right -- a generic module!) *** Registering nsResourceProtocolModule components (all right -- a generic module!) *** Registering nsRegistryViewerModule components (all right -- a generic module!) *** Registering ftp components (all right -- a generic module!) *** Registering nsGfxPSModule components (all right -- a generic module!) *** Registering nsAboutProtocolModule components (all right -- a generic module!) *** Registering res components (all right -- a generic module!) *** Registering nsURILoaderModule components (all right -- a generic module!) *** Registering nsAbModule components (all right -- a generic module!) *** Registering nsCookieModule components (all right -- a generic module!) nsNativeComponentLoader: autoregistering succeeded ./run-mozilla.sh[30]: 207015 Bus error(coredump) second run gives: MOZILLA_FIVE_HOME=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin LD_LIBRARY_PATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin:/lib:/usr/lib:/global/arch/mips-sgi-irix6.5/lib:. SHLIB_PATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin LIBPATH=/global/src/mozilla-build-mips-sgi-irix6.5-native/dist/bin MOZ_PROGRAM=viewer MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded ./run-mozilla.sh[30]: 207108 Bus error(coredump) please contact me back for stack trace (can't paste them in here, dunno why) mips-sgi-irix6.5 using mipspro 7.3.1.1 env COMPILER_DEFAULTS_PATH=/global/src/egcs CC="cc" CFLAGS="-g -woff all" CXX="CC" CXXFLAGS="-gslim -woff all -LANG:exceptions=OFF" ../mozilla/configure --enable-crash-on-assert --with-pthreads --enable-x11-shm --enable-monolithic-toolkit --with-extensions --disable-md --enable-logrefcnt --enable-nspr-autoconf compiler.defaults: -DEFAULT:abi=n32:isa=mips3 btw. mozilla/nsprpub/pr/src/md/unix/os_Irix.s is missing an include path to mozilla/nsprpub/pr/include, the correct line is as -D_ASM -n32 -o os_Irix.o -c ../../../../../../mozilla/nsprpub/pr/src/md/unix/os_Irix.s -I ../../../../../../mozilla/nsprpub/pr/include also, --enable-nspr-autoconf should be on per default. at last, i'd like to suggest using the -ar option of cc|CC under irix using mipspro 7.3+ (see man cc) for building archives. the same goes for shared libraries (-shared). regards, j.
XPCom problem?
Assignee: cbegle → dp
Component: Browser-General → XPCOM
QA Contact: asadotzler → leger
This looks more like a javascript problem, the stack trace starts in js_FinishCodeGenerator (js/src/jsemit.c:88).
i've rebuild everything under mozilla/js using CC="gcc" CFLAGS="". mozilla now does start up. however sending an e-mail crashed the whole thing, but that seems to be another story. some tests under "Debug" are working but i didn't test them all. any hints where i can read about this further? question: what's the difference in compiling the javascript stuff w/ the native c compiler and the gnu c compiler. btw. my gcc version is 2.96 19991106 (experimental)
Sorry for delayed response. My bug query wasn't looking at UNCONFIRMED bugs :-( So is this resolved by now..
I am resolving this hoping this is all a transient behaviour. Reopen if this is still the case.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
- Per last comments, age of bug, and no reopen - Marking Verified/invalid. Please reopen if still a problem.
verified
Status: RESOLVED → VERIFIED
I am compiling the M17 release with Irix native compilers 7.3.1.1 on irix 6.5, and am getting the same crash and stack trace. The problem stems from cg->codeMark pointing to an address within cx->codePool, which results in JS_CLEAR_UNUSED corrupting the cx structure from there on. The following is some info prior to the codePool release. jsemit:87 JS_ARENA_RELEASE(&cx->codePool, cg->codeMark); (dbx) p cx->codePool struct JSArenaPool { first = struct JSArena { next = 0x10133f90 base = 269574112 limit = 269574112 avail = 269574112 } current = 0x10133f90 arenasize = 1024 mask = 0 } (dbx) p cg->codeMark 0x10115fe0 (dbx) p &(cx->codePool.current) 0x10115fe0
This bug still is a problem when compiling with the SGI 7.3.1.1 compilers. Rob has more details in his ADD. Victor Riley SGI
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Rob doesn't have authority to Confirm the bug so I will do it for him. Victor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patrick, js problem ugh!
Assignee: dp → beard
Well, I'll take your word that the corruption is caused by JS, but the attached stack crawl indicates that the script passed to JS_EvaluateScript() is garbage: JS_EvaluateScript(cx = 0x1016d398, obj = 0x101593b0, bytes = 0x1017eb28 = "\332\ 332\332...")
The garbage you are seeing (octal 332) is hex 0xDA the JS_FREE_PATTERN which is used by JS_CLEAR_UNUSED and JS_CLEAR_ARENA. Stopping execution prior to the call to JS_ARENA_RELEASE(&cx->codePool, cg->codeMark); in js_FinishCodeGenerator everything looks pretty healthy. The release (and subsequent clobbering of everything with 0xDA is being done from &cx->codePool.current (this is what cg->codeMark->current->avail is pointing to) all the way off to where it has allocated some arena memory. The free pattern 0xDA is only used with DEBUG defined. Without DEBUG it seems to get further but still crashes with a corrupted address in the same sort of area.
Changed component.
Assignee: beard → rogerl
Component: XPCOM → Javascript Engine
QA Contact: leger → pschwartau
Robert Low: could you say why that memset((void*)(a)->avail, 0xDA, (a)->limit - (a)->avail) is storing more than zero bytes? Notice that the base, avail, and limit cursors in cx->codePool.first are all 269574112, which is 0x10115fe0 or the address of the next word after cx->codePool.first, i.e. &cx->codePool.current. There is no surprise here: a JSArenaPool by definition begins with an empty, zero-capacity JSArena called first. The JS_CLEAR_UNUSED macro should properly subtract avail from limit and call memset(whocares, 0xDA, 0), which should do nothing. Is it possible that memset(..., ..., 0) is running amock and not respecting the zero third argument? /be
Ooops, the memset is not called with last argument zero. The problem is that MIPSPro compiler is being smart here - it simplifies the expression JS_UPTRDIFF(a,c) <= JS_UPTRDIFF(b,c) to a <= b From that, in JS_ARENA_RELEASE, _a->avail is set to _m even if that belongs to the first arena. JS_CLEAR_UNUSED than happily clears all memory from mark to the current arena limit, thus destroying *cx and everything beyond that. I tried to insert (jsuword)_m >= _a->base condition into JS_ARENA_RELEASE (and similar to JS_ArenaRelease) and mozilla then (with a lot of beeping) comes up. I am not sending a patch - there are more places where JS_UPTRDIFF is used like that.
> Ooops, the memset is not called with last argument zero. The problem is that > MIPSPro compiler is being smart here - it simplifies the expression > JS_UPTRDIFF(a,c) <= JS_UPTRDIFF(b,c) > to > a <= b Sorry, that's a compile bug and it should be fixed. Consider the expansion: (jsuword)a - (jsuword)c <= (jsuword)b - (jsuword)c a is allowed to be < c, which makes a - c a negative number, but the unsigned cast difference becomes a very large jsuword, which is not <= b - c (which if you study how avail and base relate, is always non-negative even if signed). The compiler cannot add c to both sides of a-c <= b-c and preserve the relation, that works only with signed integral types. What's more, I'm now concerned you're dealing with old source. Can someone show me the entire source versio of the JS_ARENA_RELEASE macro that's failing for you in this way? If it does not look like this: #define JS_ARENA_RELEASE(pool, mark) \ JS_BEGIN_MACRO \ char *_m = (char *)(mark); \ JSArena *_a = (pool)->current; \ if (_a != &(pool)->first && \ JS_UPTRDIFF(_m, _a->base) <= JS_UPTRDIFF(_a->avail, _a->base)) { \ _a->avail = (jsuword)JS_ARENA_ALIGN(pool, _m); \ JS_CLEAR_UNUSED(_a); \ JS_ArenaCountRetract(pool, _m); \ } else { \ JS_ArenaRelease(pool, _m); \ } \ JS_ArenaCountRelease(pool, _m); \ JS_END_MACRO then you are using old source, and lack a patch for an already-reported and fixed bug. /be
I am using the M17 source code, and have checked that the JS_ARENA_RELEASE macro is as requested. Note: I have compiled and run with some success with gcc compilers, it is the MIPSpro compilation which is causing problems. It is wanted to get the MIPSpro version working. Breaking at jsemit.c:87 prior to first codePool release: JS_ARENA_MACRO macro is using values as follows:- _m is being assigned cg->codeMark (which is the address of cx->codePool.current, and also what codePool.first values point to). (dbx) p cg->codeMark 0x10115fe0 (dbx) p &cx->codePool.current 0x10115fe0 (dbx) p 0x10115fe0 269574112 (dbx) p cx->codePool struct JSArenaPool { first = struct JSArena { next = 0x10133f90 base = 269574112 limit = 269574112 avail = 269574112 } current = 0x10133f90 arenasize = 1024 mask = 0 } _a is being assigned codePool.current which refers to a region elsewhere (dbx) p *cx->codePool.current struct JSArena { next = (nil) base = 269696928 limit = 269697952 avail = 269697184 } cg->codeMark still has the value from js_InitCodeGenerator. Not knowing really at all how it all works, I am unsure why the macro then goes on to compare _m (an address inside cx) with the values stored in _a (current). Assigning _a->avail the value of _m and then clearing the memory is the killer. Maybe cg->codeMark should be pointing to memory inside cx->current ? Is it correct that cx->first still appears to have newly initialised values, but we have an allocated current arena ?
Everything you describe looks correct. The current arena, cx->codePool.current or _a, is linked from cx->codePool.first (which is a zero-capacity header arena) kept to unify some cases in the code. The codeMark is at the beginning of the pool, at the address of the zero-byte first arena's payload just after cx->codePool.first. The JS_ARENA_RELEASE macro should see that _m is not in _a's [base, avail) half-open range, using the single <= test of JS_UPTRDIFFs, and take the else path into JS_ArenaRelease. But it does not. That's because from all that I hear and can tell, the MIPS compiler or optimizer has a bug: it tries to optimize (a-c <= b-c) into (a < b) for unsigned values. That's wrong: consider a=10, b=20, c=15: for signed ints, -5 is indeed < 10, but (unsigned)-5 is a very large number (0xfffffffb for 32-bit unsigned), and that's certainly not < 10. Please get a fixed compiler if you can, and fast. Otherwise, give me something to test with #if for a temporary workaround. And please do make sure this hack is temporary! We should keep this bug open to remind us to remove the hack once the compiler is fixed and distributed. /be
Hi Victor, is this a known compiler bug (if diagnosed correctly, see Michal Vocu's comments)? Is there a patch of fixed version out yet? Thanks, /be
Assignee: rogerl → var
Attached file MIPSpro compiler bug proof. (deleted) —
I agree now that it seems to be a compiler bug. I've attached a proof of the bug, with source and assembler output etc. Refer to lines 80 and 140 in the assembler output. For line 140 (casts to unsigned) there appears to be some sort of optimising out of the subtraction part. thanks all for your input. Rob
(Obviously I started typing < where I meant <= in my a, b, c example -- sorry, typing too fast.) Thanks for the testcase. I was at SGI for seven years, starting in 1985. Still like that MIPS ISA and assembly code! /be
This has now been filed at SGI against the compiler simplifier. It is assigned PV bug 800890 in SGI's bug system. This has not been fixed at this time and I will see what I can do to make sure it gets addressed in the 7.3.1.2 compiler release. In the mean time here is a recommended workaround: You could try specifying -OPT:wn_simplify=off to see if it fixes the problem. Can someone please try this out and see if it resolves this problem? I am accepting ownership of this bug since it's an SGI compiler bug and will notify everyone when it is fixed in the new compilers. Victor
Status: NEW → ASSIGNED
Yes the -OPT:wn_simplify=off fixes both the attachment bug proof test case, and the mozilla code. I'm still crashing mozilla-bin in RDFServiceImpl::GetDataSource, but that doesn't seem to be related to JS arena problem. Not sure of the best place to add this to CFLAGS (and CXXFLAGS), I just added it in local ./js/src/ Makefile.in, but maybe need it at a higher level to cover the whole build. ............. % cvs diff -c Makefile.in | expand Index: Makefile.in =================================================================== RCS file: /cvsroot/mozilla/js/src/Makefile.in,v retrieving revision 3.52 diff -c -r3.52 Makefile.in *** Makefile.in 2000/07/13 05:19:16 3.52 --- Makefile.in 2000/09/06 05:12:09 *************** *** 224,229 **** --- 224,231 ---- ifneq ($(basename $(OS_RELEASE)),5) LDFLAGS += -n32 DASH_R += -n32 + CFLAGS += -OPT:wn_simplify=off + CXXFLAGS += -OPT:wn_simplify=off endif endif ifeq ($(OS_ARCH),Linux)
This problem has now been fixed in the 7.3.1.2m compiler maintenance release. When the product releases you can find it at: http://support.sgi.com/colls/patches/tools/relstream/index.html Victor
Hey, I just saw on the build page that we have an irix build, presumably a workaround. Want to close this bug?
The MIPS 7.3.1.2m compilers have released with the fix for this bug and are available at: http://support.sgi.com/colls/patches/tools/relstream/index.html Please install the new 7.3.1.2 compilers for building these sources. Victor
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
Brendan, I notice your comment above at 2000-08-31 18:45: "Please get a fixed compiler if you can, and fast. Otherwise, give me something to test with #if for a temporary workaround. And please do make sure this hack is temporary! We should keep this bug open to remind us to remove the hack once the compiler is fixed and distributed." Before I mark this bug as verified, is there any "hack" that has to be removed from JS source, now that the compiler bug has been fixed?
Phil: no workaround was ever checked in, so you can close this one. I mailed leaf and mccabe just to confirm that the SeaMonkey-Ports tinderbox builds are using the new compiler release. /be
OK, thanks - marking Verified.
Status: RESOLVED → VERIFIED
*** Bug 86687 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: