Closed Bug 30427 Opened 24 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: 24 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
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: 24 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: