Closed
Bug 30427
Opened 25 years ago
Closed 24 years ago
mozilla dumps core
Categories
(Core :: JavaScript Engine, defect, P3)
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.
Comment 2•25 years ago
|
||
XPCom problem?
Assignee: cbegle → dp
Component: Browser-General → XPCOM
QA Contact: asadotzler → leger
Comment 3•25 years ago
|
||
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)
Comment 5•25 years ago
|
||
Sorry for delayed response. My bug query wasn't looking at UNCONFIRMED bugs :-(
So is this resolved by now..
Comment 6•25 years ago
|
||
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
Comment 7•24 years ago
|
||
- Per last comments, age of bug, and no reopen - Marking Verified/invalid.
Please reopen if still a problem.
Comment 9•24 years ago
|
||
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
Assignee | ||
Comment 10•24 years ago
|
||
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 → ---
Assignee | ||
Comment 11•24 years ago
|
||
Rob doesn't have authority to Confirm the bug so I will do it for him.
Victor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 13•24 years ago
|
||
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...")
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
Changed component.
Assignee: beard → rogerl
Component: XPCOM → Javascript Engine
QA Contact: leger → pschwartau
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
> 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
Comment 19•24 years ago
|
||
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 ?
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
Comment 23•24 years ago
|
||
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
Comment 24•24 years ago
|
||
(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
Assignee | ||
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
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)
Assignee | ||
Comment 27•24 years ago
|
||
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
Comment 28•24 years ago
|
||
Hey, I just saw on the build page that we have an irix build, presumably a
workaround.
Want to close this bug?
Assignee | ||
Comment 29•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 30•24 years ago
|
||
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?
Comment 31•24 years ago
|
||
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
Comment 33•23 years ago
|
||
*** 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.
Description
•