Last Comment Bug 770102 - Crash in maybeSlot (this=0x0) at <pre>js/src/jsscope.h:710
: Crash in maybeSlot (this=0x0) at <pre>js/src/jsscope.h:710
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: ARM Linux
: -- normal (vote)
: mozilla16
Assigned To: Luke Wagner [:luke]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 769743
  Show dependency treegraph
Reported: 2012-07-02 01:43 PDT by Oleg Romashin (:romaxa)
Modified: 2012-07-03 19:09 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Oleg Romashin (:romaxa) 2012-07-02 01:43:17 PDT
On attempt to run latest m-c on BeagleBoard Ubuntu oneiric arm, I got this crash:

#4  maybeSlot (this=0x0) at <pre>js/src/jsscope.h:710
#5  slot (this=0x0) at <pre>js/src/jsscope.h:709
#6  js::ScopeCoordinateName (rt=0x46ed5000, script=0x49d332f0, pc=0x46c8c244 "\210")
    at <pre>js/src/vm/ScopeObject.cpp:54
#7  0x4538d4a6 in IsVarSlot (jp=<optimized out>, pc=<optimized out>, varAtom=0x41dfbfdc, localSlot=<optimized out>)
    at <pre>js/src/jsopcode.cpp:1855
#8  0x45392c54 in Decompile (ss=<optimized out>, pc=0x46c8c244 "\210", nb=16)
    at <pre>js/src/jsopcode.cpp:3525
#9  0x45397d00 in DecompileCode (jp=<optimized out>, script=0x49d332f0, pc=0x46c8c244 "\210", len=16, pcdepth=0, initialStackDepth=0)
    at <pre>js/src/jsopcode.cpp:5464

Full backtrace:

Bisect search endup with commit
Bug 769743
On previous changeset it works fine

arm-linux-gnueabi-g++ -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.1 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
Comment 1 Oleg Romashin (:romaxa) 2012-07-02 02:25:32 PDT
took latest tip minus fix from bug 769743  also works good, no crash.
Comment 2 Luke Wagner [:luke] 2012-07-02 09:17:31 PDT
It looks like the crash is during decompilation.  In frame 9 of the backtrace, you can find the filename and line number of the script being decompiled by printing script->filename and script->lineno in gdb.  You can also print out the bytecode by calling js_DumpScript(cx, script).  (You'll probably want a debug build to do both of these.)  Could you attach the results to this bug?
Comment 3 Oleg Romashin (:romaxa) 2012-07-02 10:25:42 PDT
#9  0x43b56684 in DecompileCode (jp=0x47aee150, script=0x4a933340, pc=0x479ffd24 "\210", len=16, pcdepth=0, initialStackDepth=0)
    at /build/mozilla/dev/xulrunner/mozilla-central/js/src/jsopcode.cpp:5464
5464	    bool ok = Decompile(&ss, pc, len) != NULL;
(gdb) p script->filename
$1 = 0x47adff71 "resource://gre/modules/XPCOMUtils.jsm"
(gdb) p script->lineno  
$2 = 172
Comment 4 Oleg Romashin (:romaxa) 2012-07-02 10:47:49 PDT
(gdb) p script->function_
$3 = {<js::EncapsulatedPtr<JSFunction, unsigned int>> = {{value = 0x4ac32720, other = 1254303520}}, <No data fields>}
(gdb) print '$->atom'
$4 = void
(gdb) print '$->dump()'
$5 = void
Comment 5 David Mandelin [:dmandelin] 2012-07-02 11:10:30 PDT
Hopefully the decompiler is going away soon.
Comment 6 Oleg Romashin (:romaxa) 2012-07-02 12:35:36 PDT
>>>>>>Func:JSBool DecompileCode(JSPrinter*, JSScript*, jsbytecode*, unsigned int, unsigned int, unsigned int)::5465 Hey, Just about to Crash!!!
loc   line  op
----- ----  --
00000: 174  getaliasedvar (hops = 0, slot = 0)
00009: 174  dup
00010: 174  callprop "__defineGetter__"
00015: 174  swap
00016: 174  getaliasedvar (hops = 0, slot = 1)
00025: 174  lambda (function () {delete aObject[aName];return aObject[aName] = aLambda.apply(aObject);})
00030: 174  call 2
00033: 174  pop
00034: 177  stop
>>>>>>Func:JSBool DecompileCode(JSPrinter*, JSScript*, jsbytecode*, unsigned int, unsigned int, unsigned int)::5467 2Hey, Just about to Crash!!!
Assertion failure: !empty(), at /build/mozilla/dev/xulrunner/mozilla-central/js/src/jsscope.h:572
Segmentation fault

also I tested same build with Fennec application and it seems to work fine, no crash observer, so it something about XRE_InitEmbedding initialization
Comment 7 Luke Wagner [:luke] 2012-07-02 13:40:54 PDT
Hmm, those hops/slots both seem to be exactly right.  That makes me thing somehow the Bindings is wrong or corrupt.  Could you change the 'while' loop in ScopeCoordinateName (js/src/vm/ScopeObject.cpp:48) to be:

    Shape::Range r = shape->all();
    fprintf(stderr, "looking for slot: %d\n", (int)sc.slot);
    while (r.front().slot() != sc.slot) {
        fprintf(stderr, "slot: %i\n", (int)r.front().slot());
Comment 8 Oleg Romashin (:romaxa) 2012-07-02 13:56:55 PDT
looking for slot: 0
jsid 0x4a71faa0 = JSString* (0x4a71faa0) = jschar * (0x4a71faa8) = "aLambda"

slot: 4
jsid 0x4a71fa80 = JSString* (0x4a71fa80) = jschar * (0x4a71fa88) = "aName"

slot: 3
jsid 0x4a71fa60 = JSString* (0x4a71fa60) = jschar * (0x4a71fa68) = "aObject"

slot: 2
Assertion failure: !empty(), at /build/mozilla/dev/xulrunner/mozilla-central/js/src/jsscope.h:572
Segmentation fault
Comment 9 Luke Wagner [:luke] 2012-07-02 14:25:03 PDT
Wait, something is screwey!  It should be looking for slot 2-4!  (While I look at the bytecode emitter, could you verify you've done a full clobbering rebuild?)
Comment 10 Luke Wagner [:luke] 2012-07-02 14:36:51 PDT
ah ha! i bet it's XDR; I didn't bump the XDR version number!
Comment 11 Luke Wagner [:luke] 2012-07-02 14:57:13 PDT
Oleg, could you verify that the issue is fixed with this push:
Comment 12 Ryan VanderMeulen [:RyanVM] 2012-07-02 19:04:35 PDT

Please resolve the bug if it is indeed fixed now.
Comment 13 Oleg Romashin (:romaxa) 2012-07-02 19:13:59 PDT
(In reply to Luke Wagner [:luke] from comment #11)
> Oleg, could you verify that the issue is fixed with this push:

Yep, it fixes the problem, thanks a lot!
Comment 14 David Mandelin [:dmandelin] 2012-07-03 10:53:51 PDT
Well that was originally an important bug after all!
Comment 15 Luke Wagner [:luke] 2012-07-03 19:09:51 PDT
(In reply to David Mandelin from comment #14)
(Well, yes, for trunk users, but between two FF releases, the XDR version will be bumped plenty of times to cover for one miss.)

Note You need to log in before you can comment on or make changes to this bug.