Segfault in JS_NewContext()

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Segfault in JS_NewContext()

cal (Bugzilla)
Hello,

I'm trying to work through the example embedder's guide using the current
tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see the
same issue.

The bare minimum code to recreate this is really simple:

#include <jsapi.h>
#include <js/Initialization.h>

int main(int argc, const char *argv[])
{
    JS_Init();

    JSRuntime *rt = JS_NewRuntime(
        JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
    );
    if (!rt)
        return 1;

    JSContext *cx = JS_NewContext(rt, 8192);
    if (!cx)
        return 1;

    JS_DestroyContext(cx);
    JS_DestroyRuntime(rt);
    JS_ShutDown();

    return 0;

}

And, I believe I followed the compile options correctly as well:

g++ -g -std=gnu++0x \
   -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
   -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz -lpthread
-ldl
In file included from /usr/include/string.h:32:0,
                 from /usr/local/include/mozjs-46a1/js/Utility.h:19,
                 from /usr/local/include/mozjs-46a1/jsalloc.h:18,
                 from /usr/local/include/mozjs-46a1/jsapi.h:24,
                 from js4.c:1:
/usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid access to
non-static data member
‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL object
[-Winvalid-offsetof]
     static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy,
mainThread);
                                                                          ^
/usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]

Besides the warnings it seems to compile fine.

Here's the stack trace from gdb when running it:

[New Thread 0x7ffff56cb700 (LWP 20062)]
[New Thread 0x7ffff54ca700 (LWP 20065)]
[New Thread 0x7ffff52c9700 (LWP 20066)]
[New Thread 0x7ffff50c8700 (LWP 20067)]
[New Thread 0x7ffff4ec7700 (LWP 20068)]
[New Thread 0x7ffff4cc6700 (LWP 20069)]
[New Thread 0x7ffff4ac5700 (LWP 20070)]
[New Thread 0x7ffff48c4700 (LWP 20071)]
[New Thread 0x7ffff46c3700 (LWP 20072)]
[New Thread 0x7ffff44c2700 (LWP 20073)]
[New Thread 0x7ffff42c1700 (LWP 20074)]
[New Thread 0x7ffff40c0700 (LWP 20075)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff6d771bb in hash (l=..., l=...) at
/download/mozilla-central/js/src/jsscript.h:2408
#2  prepareHash (l=<synthetic pointer>) at
../../dist/include/js/HashTable.h:1121
#3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
../../dist/include/js/HashTable.h:1633
#4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
../../dist/include/js/HashTable.h:383
#5  SaveSharedScriptData (cx=cx@entry=0x624540, script=..., ssd=0x634400,
nsrcnotes=1)
    at /download/mozilla-central/js/src/jsscript.cpp:2517
#6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry=0x624540,
script=..., script@entry=...)
    at /download/mozilla-central/js/src/jsscript.cpp:2901
#7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
key=<optimized out>)
    at /download/mozilla-central/js/src/jsfun.cpp:785
#8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
(cx=0x624540, global=..., key=JSProto_Function)
    at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
#9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
(cx=cx@entry=0x624540,
global=..., global@entry=...,
    key=key@entry=JSProto_Function) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:98
#10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
key=<optimized out>)
    at /download/mozilla-central/js/src/builtin/Object.cpp:1035
#11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
(cx=0x624540, global=..., key=JSProto_Object)
    at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
#12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
(cx=cx@entry=0x624540,
global=..., global@entry=...,
    key=key@entry=JSProto_Object) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:98
#13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
this=<optimized out>)
    at /download/mozilla-central/js/src/vm/GlobalObject.h:342
#14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
/download/mozilla-central/js/src/jsarray.cpp:3234
#15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
global=..., global@entry=...,
    protoKey=protoKey@entry=JSProto_Array) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:368
#16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
(cx=cx@entry=0x624540,
    global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
<intrinsic_functions>)
    at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
#17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal (cx=cx@entry
=0x624540)
    at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
#18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry=0x602e10,
cx=cx@entry=0x624540)
    at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
#19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
stackChunkSize=<optimized out>)
    at /download/mozilla-central/js/src/jscntxt.cpp:122
#20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at js1.c:12

Am I missing something simple here?

Thank you!

--Cal
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Kent Williams
Haven't used that signature for JS_NewRuntime.  The example (recently
updated to a version that will actually run to completion with a Debug
build) uses the other form which has useHelperThreads as a second parameter.

First suggestion, use something less than JS::DefaultHeapMaxBytes, like
8192 * 1024 * 1024.

Otherwise try the other signature, as in the example below:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine

On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:

> Hello,
>
> I'm trying to work through the example embedder's guide using the current
> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see the
> same issue.
>
> The bare minimum code to recreate this is really simple:
>
> #include <jsapi.h>
> #include <js/Initialization.h>
>
> int main(int argc, const char *argv[])
> {
>      JS_Init();
>
>      JSRuntime *rt = JS_NewRuntime(
>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>      );
>      if (!rt)
>          return 1;
>
>      JSContext *cx = JS_NewContext(rt, 8192);
>      if (!cx)
>          return 1;
>
>      JS_DestroyContext(cx);
>      JS_DestroyRuntime(rt);
>      JS_ShutDown();
>
>      return 0;
>
> }
>
> And, I believe I followed the compile options correctly as well:
>
> g++ -g -std=gnu++0x \
>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz -lpthread
> -ldl
> In file included from /usr/include/string.h:32:0,
>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>                   from js4.c:1:
> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid access to
> non-static data member
> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL object
> [-Winvalid-offsetof]
>       static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy,
> mainThread);
>                                                                            ^
> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>
> Besides the warnings it seems to compile fine.
>
> Here's the stack trace from gdb when running it:
>
> [New Thread 0x7ffff56cb700 (LWP 20062)]
> [New Thread 0x7ffff54ca700 (LWP 20065)]
> [New Thread 0x7ffff52c9700 (LWP 20066)]
> [New Thread 0x7ffff50c8700 (LWP 20067)]
> [New Thread 0x7ffff4ec7700 (LWP 20068)]
> [New Thread 0x7ffff4cc6700 (LWP 20069)]
> [New Thread 0x7ffff4ac5700 (LWP 20070)]
> [New Thread 0x7ffff48c4700 (LWP 20071)]
> [New Thread 0x7ffff46c3700 (LWP 20072)]
> [New Thread 0x7ffff44c2700 (LWP 20073)]
> [New Thread 0x7ffff42c1700 (LWP 20074)]
> [New Thread 0x7ffff40c0700 (LWP 20075)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
> /download/mozilla-central/js/src/jsscript.h:2408
> #2  prepareHash (l=<synthetic pointer>) at
> ../../dist/include/js/HashTable.h:1121
> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
> ../../dist/include/js/HashTable.h:1633
> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
> ../../dist/include/js/HashTable.h:383
> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=..., ssd=0x634400,
> nsrcnotes=1)
>      at /download/mozilla-central/js/src/jsscript.cpp:2517
> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry=0x624540,
> script=..., script@entry=...)
>      at /download/mozilla-central/js/src/jsscript.cpp:2901
> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
> key=<optimized out>)
>      at /download/mozilla-central/js/src/jsfun.cpp:785
> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
> (cx=0x624540, global=..., key=JSProto_Function)
>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
> (cx=cx@entry=0x624540,
> global=..., global@entry=...,
>      key=key@entry=JSProto_Function) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
> key=<optimized out>)
>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
> (cx=0x624540, global=..., key=JSProto_Object)
>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
> (cx=cx@entry=0x624540,
> global=..., global@entry=...,
>      key=key@entry=JSProto_Object) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
> this=<optimized out>)
>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
> /download/mozilla-central/js/src/jsarray.cpp:3234
> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
> global=..., global@entry=...,
>      protoKey=protoKey@entry=JSProto_Array) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
> (cx=cx@entry=0x624540,
>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
> <intrinsic_functions>)
>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal (cx=cx@entry
> =0x624540)
>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry=0x602e10,
> cx=cx@entry=0x624540)
>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
> stackChunkSize=<optimized out>)
>      at /download/mozilla-central/js/src/jscntxt.cpp:122
> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at js1.c:12
>
> Am I missing something simple here?
>
> Thank you!
>
> --Cal
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is 32MB.  I
bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
bytes to 1MB.  Same issue, I get the same segfault with the same stack
trace.

I also switched to the other function definition without the nursery bytes,
like this:
    JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
and I still see the same segfault.

Any other suggestions?  Maybe a runtime option that is required to create a
new context?  I'm currently studying the js.cpp shell and trying out
different settings to see if anything has an effect.

Thank you!

--Cal



On Mon, Dec 28, 2015 at 11:14 AM, kent williams <[hidden email]>
wrote:

> Haven't used that signature for JS_NewRuntime.  The example (recently
> updated to a version that will actually run to completion with a Debug
> build) uses the other form which has useHelperThreads as a second parameter.
>
> First suggestion, use something less than JS::DefaultHeapMaxBytes, like
> 8192 * 1024 * 1024.
>
> Otherwise try the other signature, as in the example below:
>
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>
>
> On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>
>> Hello,
>>
>> I'm trying to work through the example embedder's guide using the current
>> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see the
>> same issue.
>>
>> The bare minimum code to recreate this is really simple:
>>
>> #include <jsapi.h>
>> #include <js/Initialization.h>
>>
>> int main(int argc, const char *argv[])
>> {
>>      JS_Init();
>>
>>      JSRuntime *rt = JS_NewRuntime(
>>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>>      );
>>      if (!rt)
>>          return 1;
>>
>>      JSContext *cx = JS_NewContext(rt, 8192);
>>      if (!cx)
>>          return 1;
>>
>>      JS_DestroyContext(cx);
>>      JS_DestroyRuntime(rt);
>>      JS_ShutDown();
>>
>>      return 0;
>>
>> }
>>
>> And, I believe I followed the compile options correctly as well:
>>
>> g++ -g -std=gnu++0x \
>>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>> -lpthread
>> -ldl
>> In file included from /usr/include/string.h:32:0,
>>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
>>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>>                   from js4.c:1:
>> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid access to
>> non-static data member
>> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL object
>> [-Winvalid-offsetof]
>>       static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy,
>> mainThread);
>>
>>  ^
>> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
>> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>>
>> Besides the warnings it seems to compile fine.
>>
>> Here's the stack trace from gdb when running it:
>>
>> [New Thread 0x7ffff56cb700 (LWP 20062)]
>> [New Thread 0x7ffff54ca700 (LWP 20065)]
>> [New Thread 0x7ffff52c9700 (LWP 20066)]
>> [New Thread 0x7ffff50c8700 (LWP 20067)]
>> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>> [New Thread 0x7ffff48c4700 (LWP 20071)]
>> [New Thread 0x7ffff46c3700 (LWP 20072)]
>> [New Thread 0x7ffff44c2700 (LWP 20073)]
>> [New Thread 0x7ffff42c1700 (LWP 20074)]
>> [New Thread 0x7ffff40c0700 (LWP 20075)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000000000 in ?? ()
>> (gdb) bt
>> #0  0x0000000000000000 in ?? ()
>> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>> /download/mozilla-central/js/src/jsscript.h:2408
>> #2  prepareHash (l=<synthetic pointer>) at
>> ../../dist/include/js/HashTable.h:1121
>> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>> ../../dist/include/js/HashTable.h:1633
>> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>> ../../dist/include/js/HashTable.h:383
>> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=..., ssd=0x634400,
>> nsrcnotes=1)
>>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>> =0x624540,
>> script=..., script@entry=...)
>>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>> key=<optimized out>)
>>      at /download/mozilla-central/js/src/jsfun.cpp:785
>> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>> (cx=0x624540, global=..., key=JSProto_Function)
>>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>> (cx=cx@entry=0x624540,
>> global=..., global@entry=...,
>>      key=key@entry=JSProto_Function) at
>> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>> key=<optimized out>)
>>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>> (cx=0x624540, global=..., key=JSProto_Object)
>>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>> (cx=cx@entry=0x624540,
>> global=..., global@entry=...,
>>      key=key@entry=JSProto_Object) at
>> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>> this=<optimized out>)
>>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>> /download/mozilla-central/js/src/jsarray.cpp:3234
>> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
>> global=..., global@entry=...,
>>      protoKey=protoKey@entry=JSProto_Array) at
>> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>> (cx=cx@entry=0x624540,
>>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
>> <intrinsic_functions>)
>>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal (cx=cx@entry
>> =0x624540)
>>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry
>> =0x602e10,
>> cx=cx@entry=0x624540)
>>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>> stackChunkSize=<optimized out>)
>>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at js1.c:12
>>
>> Am I missing something simple here?
>>
>> Thank you!
>>
>> --Cal
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
Are you running with a debug build? There are lots of helpful assertions
that will catch potential problems.

On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]> wrote:

> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is 32MB.  I
> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
> bytes to 1MB.  Same issue, I get the same segfault with the same stack
> trace.
>
> I also switched to the other function definition without the nursery bytes,
> like this:
>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
> and I still see the same segfault.
>
> Any other suggestions?  Maybe a runtime option that is required to create a
> new context?  I'm currently studying the js.cpp shell and trying out
> different settings to see if anything has an effect.
>
> Thank you!
>
> --Cal
>
>
>
> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <[hidden email]>
> wrote:
>
> > Haven't used that signature for JS_NewRuntime.  The example (recently
> > updated to a version that will actually run to completion with a Debug
> > build) uses the other form which has useHelperThreads as a second
> parameter.
> >
> > First suggestion, use something less than JS::DefaultHeapMaxBytes, like
> > 8192 * 1024 * 1024.
> >
> > Otherwise try the other signature, as in the example below:
> >
> >
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
> >
> >
> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
> >
> >> Hello,
> >>
> >> I'm trying to work through the example embedder's guide using the
> current
> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see
> the
> >> same issue.
> >>
> >> The bare minimum code to recreate this is really simple:
> >>
> >> #include <jsapi.h>
> >> #include <js/Initialization.h>
> >>
> >> int main(int argc, const char *argv[])
> >> {
> >>      JS_Init();
> >>
> >>      JSRuntime *rt = JS_NewRuntime(
> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
> >>      );
> >>      if (!rt)
> >>          return 1;
> >>
> >>      JSContext *cx = JS_NewContext(rt, 8192);
> >>      if (!cx)
> >>          return 1;
> >>
> >>      JS_DestroyContext(cx);
> >>      JS_DestroyRuntime(rt);
> >>      JS_ShutDown();
> >>
> >>      return 0;
> >>
> >> }
> >>
> >> And, I believe I followed the compile options correctly as well:
> >>
> >> g++ -g -std=gnu++0x \
> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
> >> -lpthread
> >> -ldl
> >> In file included from /usr/include/string.h:32:0,
> >>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
> >>                   from js4.c:1:
> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid access
> to
> >> non-static data member
> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
> object
> >> [-Winvalid-offsetof]
> >>       static const size_t RuntimeMainThreadOffset =
> offsetof(RuntimeDummy,
> >> mainThread);
> >>
> >>  ^
> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
> >>
> >> Besides the warnings it seems to compile fine.
> >>
> >> Here's the stack trace from gdb when running it:
> >>
> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x0000000000000000 in ?? ()
> >> (gdb) bt
> >> #0  0x0000000000000000 in ?? ()
> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
> >> /download/mozilla-central/js/src/jsscript.h:2408
> >> #2  prepareHash (l=<synthetic pointer>) at
> >> ../../dist/include/js/HashTable.h:1121
> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
> >> ../../dist/include/js/HashTable.h:1633
> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
> >> ../../dist/include/js/HashTable.h:383
> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
> ssd=0x634400,
> >> nsrcnotes=1)
> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
> >> =0x624540,
> >> script=..., script@entry=...)
> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
> >> key=<optimized out>)
> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
> >> (cx=0x624540, global=..., key=JSProto_Function)
> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
> >> (cx=cx@entry=0x624540,
> >> global=..., global@entry=...,
> >>      key=key@entry=JSProto_Function) at
> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
> >> key=<optimized out>)
> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
> >> (cx=0x624540, global=..., key=JSProto_Object)
> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
> >> (cx=cx@entry=0x624540,
> >> global=..., global@entry=...,
> >>      key=key@entry=JSProto_Object) at
> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
> >> this=<optimized out>)
> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
> >> /download/mozilla-central/js/src/jsarray.cpp:3234
> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
> >> global=..., global@entry=...,
> >>      protoKey=protoKey@entry=JSProto_Array) at
> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
> >> (cx=cx@entry=0x624540,
> >>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
> >> <intrinsic_functions>)
> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
> (cx=cx@entry
> >> =0x624540)
> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry
> >> =0x602e10,
> >> cx=cx@entry=0x624540)
> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
> >> stackChunkSize=<optimized out>)
> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at js1.c:12
> >>
> >> Am I missing something simple here?
> >>
> >> Thank you!
> >>
> >> --Cal
> >> _______________________________________________
> >> dev-tech-js-engine mailing list
> >> [hidden email]
> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
> >>
> >
> > _______________________________________________
> > dev-tech-js-engine mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
> >
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
No I was using the release build.  I'll try that next, thanks!


On Mon, Dec 28, 2015 at 2:35 PM, Bobby Holley <[hidden email]> wrote:

> Are you running with a debug build? There are lots of helpful assertions
> that will catch potential problems.
>
> On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]> wrote:
>
>> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is 32MB.  I
>> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
>> bytes to 1MB.  Same issue, I get the same segfault with the same stack
>> trace.
>>
>> I also switched to the other function definition without the nursery
>> bytes,
>> like this:
>>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
>> and I still see the same segfault.
>>
>> Any other suggestions?  Maybe a runtime option that is required to create
>> a
>> new context?  I'm currently studying the js.cpp shell and trying out
>> different settings to see if anything has an effect.
>>
>> Thank you!
>>
>> --Cal
>>
>>
>>
>> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <[hidden email]>
>> wrote:
>>
>> > Haven't used that signature for JS_NewRuntime.  The example (recently
>> > updated to a version that will actually run to completion with a Debug
>> > build) uses the other form which has useHelperThreads as a second
>> parameter.
>> >
>> > First suggestion, use something less than JS::DefaultHeapMaxBytes, like
>> > 8192 * 1024 * 1024.
>> >
>> > Otherwise try the other signature, as in the example below:
>> >
>> >
>> >
>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>> >
>> >
>> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>> >
>> >> Hello,
>> >>
>> >> I'm trying to work through the example embedder's guide using the
>> current
>> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see
>> the
>> >> same issue.
>> >>
>> >> The bare minimum code to recreate this is really simple:
>> >>
>> >> #include <jsapi.h>
>> >> #include <js/Initialization.h>
>> >>
>> >> int main(int argc, const char *argv[])
>> >> {
>> >>      JS_Init();
>> >>
>> >>      JSRuntime *rt = JS_NewRuntime(
>> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>> >>      );
>> >>      if (!rt)
>> >>          return 1;
>> >>
>> >>      JSContext *cx = JS_NewContext(rt, 8192);
>> >>      if (!cx)
>> >>          return 1;
>> >>
>> >>      JS_DestroyContext(cx);
>> >>      JS_DestroyRuntime(rt);
>> >>      JS_ShutDown();
>> >>
>> >>      return 0;
>> >>
>> >> }
>> >>
>> >> And, I believe I followed the compile options correctly as well:
>> >>
>> >> g++ -g -std=gnu++0x \
>> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>> >> -lpthread
>> >> -ldl
>> >> In file included from /usr/include/string.h:32:0,
>> >>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
>> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>> >>                   from js4.c:1:
>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid
>> access to
>> >> non-static data member
>> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
>> object
>> >> [-Winvalid-offsetof]
>> >>       static const size_t RuntimeMainThreadOffset =
>> offsetof(RuntimeDummy,
>> >> mainThread);
>> >>
>> >>  ^
>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
>> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>> >>
>> >> Besides the warnings it seems to compile fine.
>> >>
>> >> Here's the stack trace from gdb when running it:
>> >>
>> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
>> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
>> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
>> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
>> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
>> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
>> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
>> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
>> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
>> >>
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x0000000000000000 in ?? ()
>> >> (gdb) bt
>> >> #0  0x0000000000000000 in ?? ()
>> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>> >> /download/mozilla-central/js/src/jsscript.h:2408
>> >> #2  prepareHash (l=<synthetic pointer>) at
>> >> ../../dist/include/js/HashTable.h:1121
>> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>> >> ../../dist/include/js/HashTable.h:1633
>> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>> >> ../../dist/include/js/HashTable.h:383
>> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
>> ssd=0x634400,
>> >> nsrcnotes=1)
>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>> >> =0x624540,
>> >> script=..., script@entry=...)
>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>> >> key=<optimized out>)
>> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
>> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>> >> (cx=0x624540, global=..., key=JSProto_Function)
>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>> >> (cx=cx@entry=0x624540,
>> >> global=..., global@entry=...,
>> >>      key=key@entry=JSProto_Function) at
>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>> >> key=<optimized out>)
>> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>> >> (cx=0x624540, global=..., key=JSProto_Object)
>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>> >> (cx=cx@entry=0x624540,
>> >> global=..., global@entry=...,
>> >>      key=key@entry=JSProto_Object) at
>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>> >> this=<optimized out>)
>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>> >> /download/mozilla-central/js/src/jsarray.cpp:3234
>> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
>> >> global=..., global@entry=...,
>> >>      protoKey=protoKey@entry=JSProto_Array) at
>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>> >> (cx=cx@entry=0x624540,
>> >>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
>> >> <intrinsic_functions>)
>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
>> (cx=cx@entry
>> >> =0x624540)
>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry
>> >> =0x602e10,
>> >> cx=cx@entry=0x624540)
>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>> >> stackChunkSize=<optimized out>)
>> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at
>> js1.c:12
>> >>
>> >> Am I missing something simple here?
>> >>
>> >> Thank you!
>> >>
>> >> --Cal
>> >> _______________________________________________
>> >> dev-tech-js-engine mailing list
>> >> [hidden email]
>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>> >>
>> >
>> > _______________________________________________
>> > dev-tech-js-engine mailing list
>> > [hidden email]
>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>> >
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
I still see the same segfault.  Am I building the debug build correctly?

in js/src$  mkdir build_DBG.OBJ
$ cd build_DBG.OBJ
$ ../configure --enable-debug --disable-optimize

The shared library object is actually *smaller* than the release one.
118MB vs 157MB.  When I link against the debug shared library, I still get
a segfault.  I was expecting it to toss some assertions if it were
correctly compiled as a debug library.

I also tried statically linking against libjs_static.a which was 384MB, and
still have the same segfault.

Any other suggestions to try?

Thank you!

--Cal


On Mon, Dec 28, 2015 at 2:59 PM, Cal Heldenbrand <[hidden email]> wrote:

> No I was using the release build.  I'll try that next, thanks!
>
>
> On Mon, Dec 28, 2015 at 2:35 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> Are you running with a debug build? There are lots of helpful assertions
>> that will catch potential problems.
>>
>> On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]>
>> wrote:
>>
>>> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is 32MB.  I
>>> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
>>> bytes to 1MB.  Same issue, I get the same segfault with the same stack
>>> trace.
>>>
>>> I also switched to the other function definition without the nursery
>>> bytes,
>>> like this:
>>>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
>>> and I still see the same segfault.
>>>
>>> Any other suggestions?  Maybe a runtime option that is required to
>>> create a
>>> new context?  I'm currently studying the js.cpp shell and trying out
>>> different settings to see if anything has an effect.
>>>
>>> Thank you!
>>>
>>> --Cal
>>>
>>>
>>>
>>> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <[hidden email]>
>>> wrote:
>>>
>>> > Haven't used that signature for JS_NewRuntime.  The example (recently
>>> > updated to a version that will actually run to completion with a Debug
>>> > build) uses the other form which has useHelperThreads as a second
>>> parameter.
>>> >
>>> > First suggestion, use something less than JS::DefaultHeapMaxBytes, like
>>> > 8192 * 1024 * 1024.
>>> >
>>> > Otherwise try the other signature, as in the example below:
>>> >
>>> >
>>> >
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>>> >
>>> >
>>> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>>> >
>>> >> Hello,
>>> >>
>>> >> I'm trying to work through the example embedder's guide using the
>>> current
>>> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and see
>>> the
>>> >> same issue.
>>> >>
>>> >> The bare minimum code to recreate this is really simple:
>>> >>
>>> >> #include <jsapi.h>
>>> >> #include <js/Initialization.h>
>>> >>
>>> >> int main(int argc, const char *argv[])
>>> >> {
>>> >>      JS_Init();
>>> >>
>>> >>      JSRuntime *rt = JS_NewRuntime(
>>> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>>> >>      );
>>> >>      if (!rt)
>>> >>          return 1;
>>> >>
>>> >>      JSContext *cx = JS_NewContext(rt, 8192);
>>> >>      if (!cx)
>>> >>          return 1;
>>> >>
>>> >>      JS_DestroyContext(cx);
>>> >>      JS_DestroyRuntime(rt);
>>> >>      JS_ShutDown();
>>> >>
>>> >>      return 0;
>>> >>
>>> >> }
>>> >>
>>> >> And, I believe I followed the compile options correctly as well:
>>> >>
>>> >> g++ -g -std=gnu++0x \
>>> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>>> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>>> >> -lpthread
>>> >> -ldl
>>> >> In file included from /usr/include/string.h:32:0,
>>> >>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
>>> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>>> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>>> >>                   from js4.c:1:
>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid
>>> access to
>>> >> non-static data member
>>> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
>>> object
>>> >> [-Winvalid-offsetof]
>>> >>       static const size_t RuntimeMainThreadOffset =
>>> offsetof(RuntimeDummy,
>>> >> mainThread);
>>> >>
>>> >>  ^
>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
>>> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>>> >>
>>> >> Besides the warnings it seems to compile fine.
>>> >>
>>> >> Here's the stack trace from gdb when running it:
>>> >>
>>> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
>>> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
>>> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
>>> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
>>> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>>> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>>> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>>> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
>>> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
>>> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
>>> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
>>> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
>>> >>
>>> >> Program received signal SIGSEGV, Segmentation fault.
>>> >> 0x0000000000000000 in ?? ()
>>> >> (gdb) bt
>>> >> #0  0x0000000000000000 in ?? ()
>>> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>>> >> /download/mozilla-central/js/src/jsscript.h:2408
>>> >> #2  prepareHash (l=<synthetic pointer>) at
>>> >> ../../dist/include/js/HashTable.h:1121
>>> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>> >> ../../dist/include/js/HashTable.h:1633
>>> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>> >> ../../dist/include/js/HashTable.h:383
>>> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
>>> ssd=0x634400,
>>> >> nsrcnotes=1)
>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>>> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>>> >> =0x624540,
>>> >> script=..., script@entry=...)
>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>>> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>>> >> key=<optimized out>)
>>> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
>>> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>>> >> (cx=0x624540, global=..., key=JSProto_Function)
>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>>> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>> >> (cx=cx@entry=0x624540,
>>> >> global=..., global@entry=...,
>>> >>      key=key@entry=JSProto_Function) at
>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>>> >> key=<optimized out>)
>>> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>>> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>>> >> (cx=0x624540, global=..., key=JSProto_Object)
>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>>> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>> >> (cx=cx@entry=0x624540,
>>> >> global=..., global@entry=...,
>>> >>      key=key@entry=JSProto_Object) at
>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>>> >> this=<optimized out>)
>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>>> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>>> >> /download/mozilla-central/js/src/jsarray.cpp:3234
>>> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
>>> >> global=..., global@entry=...,
>>> >>      protoKey=protoKey@entry=JSProto_Array) at
>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>>> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>>> >> (cx=cx@entry=0x624540,
>>> >>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
>>> >> <intrinsic_functions>)
>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>>> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
>>> (cx=cx@entry
>>> >> =0x624540)
>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>>> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry
>>> >> =0x602e10,
>>> >> cx=cx@entry=0x624540)
>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>>> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>>> >> stackChunkSize=<optimized out>)
>>> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>>> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at
>>> js1.c:12
>>> >>
>>> >> Am I missing something simple here?
>>> >>
>>> >> Thank you!
>>> >>
>>> >> --Cal
>>> >> _______________________________________________
>>> >> dev-tech-js-engine mailing list
>>> >> [hidden email]
>>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>> >>
>>> >
>>> > _______________________________________________
>>> > dev-tech-js-engine mailing list
>>> > [hidden email]
>>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>> >
>>> _______________________________________________
>>> dev-tech-js-engine mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>
>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
Does your new stacktrace have full stack variables (i.e. without the
"optimized out" bits)?

On Mon, Dec 28, 2015 at 1:51 PM, Cal Heldenbrand <[hidden email]> wrote:

> I still see the same segfault.  Am I building the debug build correctly?
>
> in js/src$  mkdir build_DBG.OBJ
> $ cd build_DBG.OBJ
> $ ../configure --enable-debug --disable-optimize
>
> The shared library object is actually *smaller* than the release one.
> 118MB vs 157MB.  When I link against the debug shared library, I still get
> a segfault.  I was expecting it to toss some assertions if it were
> correctly compiled as a debug library.
>
> I also tried statically linking against libjs_static.a which was 384MB,
> and still have the same segfault.
>
> Any other suggestions to try?
>
> Thank you!
>
> --Cal
>
>
>
> On Mon, Dec 28, 2015 at 2:59 PM, Cal Heldenbrand <[hidden email]> wrote:
>
>> No I was using the release build.  I'll try that next, thanks!
>>
>>
>> On Mon, Dec 28, 2015 at 2:35 PM, Bobby Holley <[hidden email]>
>> wrote:
>>
>>> Are you running with a debug build? There are lots of helpful assertions
>>> that will catch potential problems.
>>>
>>> On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]>
>>> wrote:
>>>
>>>> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is 32MB.
>>>> I
>>>> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
>>>> bytes to 1MB.  Same issue, I get the same segfault with the same stack
>>>> trace.
>>>>
>>>> I also switched to the other function definition without the nursery
>>>> bytes,
>>>> like this:
>>>>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
>>>> and I still see the same segfault.
>>>>
>>>> Any other suggestions?  Maybe a runtime option that is required to
>>>> create a
>>>> new context?  I'm currently studying the js.cpp shell and trying out
>>>> different settings to see if anything has an effect.
>>>>
>>>> Thank you!
>>>>
>>>> --Cal
>>>>
>>>>
>>>>
>>>> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <[hidden email]
>>>> >
>>>> wrote:
>>>>
>>>> > Haven't used that signature for JS_NewRuntime.  The example (recently
>>>> > updated to a version that will actually run to completion with a Debug
>>>> > build) uses the other form which has useHelperThreads as a second
>>>> parameter.
>>>> >
>>>> > First suggestion, use something less than JS::DefaultHeapMaxBytes,
>>>> like
>>>> > 8192 * 1024 * 1024.
>>>> >
>>>> > Otherwise try the other signature, as in the example below:
>>>> >
>>>> >
>>>> >
>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>>>> >
>>>> >
>>>> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>>>> >
>>>> >> Hello,
>>>> >>
>>>> >> I'm trying to work through the example embedder's guide using the
>>>> current
>>>> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and
>>>> see the
>>>> >> same issue.
>>>> >>
>>>> >> The bare minimum code to recreate this is really simple:
>>>> >>
>>>> >> #include <jsapi.h>
>>>> >> #include <js/Initialization.h>
>>>> >>
>>>> >> int main(int argc, const char *argv[])
>>>> >> {
>>>> >>      JS_Init();
>>>> >>
>>>> >>      JSRuntime *rt = JS_NewRuntime(
>>>> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>>>> >>      );
>>>> >>      if (!rt)
>>>> >>          return 1;
>>>> >>
>>>> >>      JSContext *cx = JS_NewContext(rt, 8192);
>>>> >>      if (!cx)
>>>> >>          return 1;
>>>> >>
>>>> >>      JS_DestroyContext(cx);
>>>> >>      JS_DestroyRuntime(rt);
>>>> >>      JS_ShutDown();
>>>> >>
>>>> >>      return 0;
>>>> >>
>>>> >> }
>>>> >>
>>>> >> And, I believe I followed the compile options correctly as well:
>>>> >>
>>>> >> g++ -g -std=gnu++0x \
>>>> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>>>> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>>>> >> -lpthread
>>>> >> -ldl
>>>> >> In file included from /usr/include/string.h:32:0,
>>>> >>                   from /usr/local/include/mozjs-46a1/js/Utility.h:19,
>>>> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>>>> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>>>> >>                   from js4.c:1:
>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid
>>>> access to
>>>> >> non-static data member
>>>> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
>>>> object
>>>> >> [-Winvalid-offsetof]
>>>> >>       static const size_t RuntimeMainThreadOffset =
>>>> offsetof(RuntimeDummy,
>>>> >> mainThread);
>>>> >>
>>>> >>  ^
>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps the
>>>> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>>>> >>
>>>> >> Besides the warnings it seems to compile fine.
>>>> >>
>>>> >> Here's the stack trace from gdb when running it:
>>>> >>
>>>> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
>>>> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
>>>> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
>>>> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
>>>> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>>>> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>>>> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>>>> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
>>>> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
>>>> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
>>>> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
>>>> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
>>>> >>
>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>> >> 0x0000000000000000 in ?? ()
>>>> >> (gdb) bt
>>>> >> #0  0x0000000000000000 in ?? ()
>>>> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>>>> >> /download/mozilla-central/js/src/jsscript.h:2408
>>>> >> #2  prepareHash (l=<synthetic pointer>) at
>>>> >> ../../dist/include/js/HashTable.h:1121
>>>> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>> >> ../../dist/include/js/HashTable.h:1633
>>>> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>> >> ../../dist/include/js/HashTable.h:383
>>>> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
>>>> ssd=0x634400,
>>>> >> nsrcnotes=1)
>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>>>> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>>>> >> =0x624540,
>>>> >> script=..., script@entry=...)
>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>>>> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>>>> >> key=<optimized out>)
>>>> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
>>>> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>>>> >> (cx=0x624540, global=..., key=JSProto_Function)
>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>>>> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>> >> (cx=cx@entry=0x624540,
>>>> >> global=..., global@entry=...,
>>>> >>      key=key@entry=JSProto_Function) at
>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>>>> >> key=<optimized out>)
>>>> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>>>> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>>>> >> (cx=0x624540, global=..., key=JSProto_Object)
>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>>>> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>> >> (cx=cx@entry=0x624540,
>>>> >> global=..., global@entry=...,
>>>> >>      key=key@entry=JSProto_Object) at
>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>>>> >> this=<optimized out>)
>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>>>> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>>>> >> /download/mozilla-central/js/src/jsarray.cpp:3234
>>>> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry=0x624540,
>>>> >> global=..., global@entry=...,
>>>> >>      protoKey=protoKey@entry=JSProto_Array) at
>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>>>> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>>>> >> (cx=cx@entry=0x624540,
>>>> >>      global=global@entry=..., builtins=builtins@entry=0x7ffff7db89c0
>>>> >> <intrinsic_functions>)
>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>>>> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
>>>> (cx=cx@entry
>>>> >> =0x624540)
>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>>>> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting (this=this@entry
>>>> >> =0x602e10,
>>>> >> cx=cx@entry=0x624540)
>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>>>> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>>>> >> stackChunkSize=<optimized out>)
>>>> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>>>> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at
>>>> js1.c:12
>>>> >>
>>>> >> Am I missing something simple here?
>>>> >>
>>>> >> Thank you!
>>>> >>
>>>> >> --Cal
>>>> >> _______________________________________________
>>>> >> dev-tech-js-engine mailing list
>>>> >> [hidden email]
>>>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > dev-tech-js-engine mailing list
>>>> > [hidden email]
>>>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>> >
>>>> _______________________________________________
>>>> dev-tech-js-engine mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>
>>>
>>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
Yes, looks like it.  Here's the new stack trace below.  I don't understand
why it's going through all of this global class init and bytecode stuff
when my app hasn't even started that yet.  Does it have something to do
with the self hosting stuff?

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000009841bd in js::ScriptBytecodeHasher::hash (l=...)
    at /download/mozilla-central/js/src/jsscript.h:2408
#2  0x000000000099f18f in js::detail::HashTable<js::SharedScriptData*
const, js::HashSet<js::SharedScriptData*, js::ScriptBytecodeHasher,
js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::prepareHash (l=...)
at ../../dist/include/js/HashTable.h:1121
#3  0x000000000099812d in js::detail::HashTable<js::SharedScriptData*
const, js::HashSet<js::SharedScriptData*, js::ScriptBytecodeHasher,
js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookupForAdd
(this=0x2117830, l=...) at ../../dist/include/js/HashTable.h:1633
#4  0x000000000098f6a3 in js::HashSet<js::SharedScriptData*,
js::ScriptBytecodeHasher, js::SystemAllocPolicy>::lookupForAdd
(this=0x2117830, l=...) at ../../dist/include/js/HashTable.h:383
#5  0x000000000095bf28 in SaveSharedScriptData (cx=0x2130db0, script=...,
ssd=0x213c540,
    nsrcnotes=1) at /download/mozilla-central/js/src/jsscript.cpp:2517
#6  0x000000000095ce46 in JSScript::fullyInitTrivial (cx=0x2130db0,
script=...)
    at /download/mozilla-central/js/src/jsscript.cpp:2901
#7  0x00000000008b271a in CreateFunctionPrototype (cx=0x2130db0,
key=JSProto_Function)
    at /download/mozilla-central/js/src/jsfun.cpp:785
#8  0x0000000000a494be in js::GlobalObject::resolveConstructor
(cx=0x2130db0, global=...,
    key=JSProto_Function) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:158
#9  0x0000000000a4921e in js::GlobalObject::ensureConstructor
(cx=0x2130db0, global=...,
    key=JSProto_Function) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:98
#10 0x00000000007ab35b in CreateObjectConstructor (cx=0x2130db0,
key=JSProto_Object)
    at /download/mozilla-central/js/src/builtin/Object.cpp:1035
#11 0x0000000000a49560 in js::GlobalObject::resolveConstructor
(cx=0x2130db0, global=...,
    key=JSProto_Object) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:166
#12 0x0000000000a4921e in js::GlobalObject::ensureConstructor
(cx=0x2130db0, global=...,
    key=JSProto_Object) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:98
#13 0x00000000004484d7 in js::GlobalObject::getOrCreateObjectPrototype
(this=0x7ffff7e22060,
    cx=0x2130db0) at /download/mozilla-central/js/src/vm/GlobalObject.h:342
#14 0x0000000000e289a0 in CreateArrayPrototype (cx=0x2130db0,
key=JSProto_Array)
    at /download/mozilla-central/js/src/jsarray.cpp:3234
#15 0x0000000000a4a63e in InitBareBuiltinCtor (cx=0x2130db0, global=...,
    protoKey=JSProto_Array) at
/download/mozilla-central/js/src/vm/GlobalObject.cpp:368
#16 0x0000000000a4a9ba in js::GlobalObject::initSelfHostingBuiltins
(cx=0x2130db0,
    global=..., builtins=0x20ea7a0 <intrinsic_functions>)
    at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
#17 0x0000000000b5000b in JSRuntime::createSelfHostingGlobal (cx=0x2130db0)
    at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
#18 0x0000000000b5016a in JSRuntime::initSelfHosting (this=0x210eeb0,
cx=0x2130db0)
    at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
#19 0x000000000086b392 in js::NewContext (rt=0x210eeb0, stackChunkSize=8192)
    at /download/mozilla-central/js/src/jscntxt.cpp:122
#20 0x0000000000856ed6 in JS_NewContext (rt=0x210eeb0, stackChunkSize=8192)
    at /download/mozilla-central/js/src/jsapi.cpp:568
#21 0x0000000000405858 in main (argc=1, argv=0x7fffffffd6a8) at js4.c:22



On Mon, Dec 28, 2015 at 3:53 PM, Bobby Holley <[hidden email]> wrote:

> Does your new stacktrace have full stack variables (i.e. without the
> "optimized out" bits)?
>
> On Mon, Dec 28, 2015 at 1:51 PM, Cal Heldenbrand <[hidden email]> wrote:
>
>> I still see the same segfault.  Am I building the debug build correctly?
>>
>> in js/src$  mkdir build_DBG.OBJ
>> $ cd build_DBG.OBJ
>> $ ../configure --enable-debug --disable-optimize
>>
>> The shared library object is actually *smaller* than the release one.
>> 118MB vs 157MB.  When I link against the debug shared library, I still get
>> a segfault.  I was expecting it to toss some assertions if it were
>> correctly compiled as a debug library.
>>
>> I also tried statically linking against libjs_static.a which was 384MB,
>> and still have the same segfault.
>>
>> Any other suggestions to try?
>>
>> Thank you!
>>
>> --Cal
>>
>>
>>
>> On Mon, Dec 28, 2015 at 2:59 PM, Cal Heldenbrand <[hidden email]> wrote:
>>
>>> No I was using the release build.  I'll try that next, thanks!
>>>
>>>
>>> On Mon, Dec 28, 2015 at 2:35 PM, Bobby Holley <[hidden email]>
>>> wrote:
>>>
>>>> Are you running with a debug build? There are lots of helpful
>>>> assertions that will catch potential problems.
>>>>
>>>> On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]>
>>>> wrote:
>>>>
>>>>> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is
>>>>> 32MB.  I
>>>>> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the nursery
>>>>> bytes to 1MB.  Same issue, I get the same segfault with the same stack
>>>>> trace.
>>>>>
>>>>> I also switched to the other function definition without the nursery
>>>>> bytes,
>>>>> like this:
>>>>>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
>>>>> and I still see the same segfault.
>>>>>
>>>>> Any other suggestions?  Maybe a runtime option that is required to
>>>>> create a
>>>>> new context?  I'm currently studying the js.cpp shell and trying out
>>>>> different settings to see if anything has an effect.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> --Cal
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> > Haven't used that signature for JS_NewRuntime.  The example (recently
>>>>> > updated to a version that will actually run to completion with a
>>>>> Debug
>>>>> > build) uses the other form which has useHelperThreads as a second
>>>>> parameter.
>>>>> >
>>>>> > First suggestion, use something less than JS::DefaultHeapMaxBytes,
>>>>> like
>>>>> > 8192 * 1024 * 1024.
>>>>> >
>>>>> > Otherwise try the other signature, as in the example below:
>>>>> >
>>>>> >
>>>>> >
>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>>>>> >
>>>>> >
>>>>> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>>>>> >
>>>>> >> Hello,
>>>>> >>
>>>>> >> I'm trying to work through the example embedder's guide using the
>>>>> current
>>>>> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and
>>>>> see the
>>>>> >> same issue.
>>>>> >>
>>>>> >> The bare minimum code to recreate this is really simple:
>>>>> >>
>>>>> >> #include <jsapi.h>
>>>>> >> #include <js/Initialization.h>
>>>>> >>
>>>>> >> int main(int argc, const char *argv[])
>>>>> >> {
>>>>> >>      JS_Init();
>>>>> >>
>>>>> >>      JSRuntime *rt = JS_NewRuntime(
>>>>> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>>>>> >>      );
>>>>> >>      if (!rt)
>>>>> >>          return 1;
>>>>> >>
>>>>> >>      JSContext *cx = JS_NewContext(rt, 8192);
>>>>> >>      if (!cx)
>>>>> >>          return 1;
>>>>> >>
>>>>> >>      JS_DestroyContext(cx);
>>>>> >>      JS_DestroyRuntime(rt);
>>>>> >>      JS_ShutDown();
>>>>> >>
>>>>> >>      return 0;
>>>>> >>
>>>>> >> }
>>>>> >>
>>>>> >> And, I believe I followed the compile options correctly as well:
>>>>> >>
>>>>> >> g++ -g -std=gnu++0x \
>>>>> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>>>>> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>>>>> >> -lpthread
>>>>> >> -ldl
>>>>> >> In file included from /usr/include/string.h:32:0,
>>>>> >>                   from
>>>>> /usr/local/include/mozjs-46a1/js/Utility.h:19,
>>>>> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>>>>> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>>>>> >>                   from js4.c:1:
>>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid
>>>>> access to
>>>>> >> non-static data member
>>>>> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
>>>>> object
>>>>> >> [-Winvalid-offsetof]
>>>>> >>       static const size_t RuntimeMainThreadOffset =
>>>>> offsetof(RuntimeDummy,
>>>>> >> mainThread);
>>>>> >>
>>>>> >>  ^
>>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps
>>>>> the
>>>>> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>>>>> >>
>>>>> >> Besides the warnings it seems to compile fine.
>>>>> >>
>>>>> >> Here's the stack trace from gdb when running it:
>>>>> >>
>>>>> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
>>>>> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
>>>>> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
>>>>> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
>>>>> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>>>>> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>>>>> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>>>>> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
>>>>> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
>>>>> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
>>>>> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
>>>>> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
>>>>> >>
>>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>>> >> 0x0000000000000000 in ?? ()
>>>>> >> (gdb) bt
>>>>> >> #0  0x0000000000000000 in ?? ()
>>>>> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>>>>> >> /download/mozilla-central/js/src/jsscript.h:2408
>>>>> >> #2  prepareHash (l=<synthetic pointer>) at
>>>>> >> ../../dist/include/js/HashTable.h:1121
>>>>> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>>> >> ../../dist/include/js/HashTable.h:1633
>>>>> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>>> >> ../../dist/include/js/HashTable.h:383
>>>>> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
>>>>> ssd=0x634400,
>>>>> >> nsrcnotes=1)
>>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>>>>> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>>>>> >> =0x624540,
>>>>> >> script=..., script@entry=...)
>>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>>>>> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>>>>> >> key=<optimized out>)
>>>>> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
>>>>> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>>>>> >> (cx=0x624540, global=..., key=JSProto_Function)
>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>>>>> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>>> >> (cx=cx@entry=0x624540,
>>>>> >> global=..., global@entry=...,
>>>>> >>      key=key@entry=JSProto_Function) at
>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>>> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>>>>> >> key=<optimized out>)
>>>>> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>>>>> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>>>>> >> (cx=0x624540, global=..., key=JSProto_Object)
>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>>>>> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>>> >> (cx=cx@entry=0x624540,
>>>>> >> global=..., global@entry=...,
>>>>> >>      key=key@entry=JSProto_Object) at
>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>>> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>>>>> >> this=<optimized out>)
>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>>>>> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>>>>> >> /download/mozilla-central/js/src/jsarray.cpp:3234
>>>>> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry
>>>>> =0x624540,
>>>>> >> global=..., global@entry=...,
>>>>> >>      protoKey=protoKey@entry=JSProto_Array) at
>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>>>>> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>>>>> >> (cx=cx@entry=0x624540,
>>>>> >>      global=global@entry=..., builtins=builtins@entry
>>>>> =0x7ffff7db89c0
>>>>> >> <intrinsic_functions>)
>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>>>>> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
>>>>> (cx=cx@entry
>>>>> >> =0x624540)
>>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>>>>> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting
>>>>> (this=this@entry
>>>>> >> =0x602e10,
>>>>> >> cx=cx@entry=0x624540)
>>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>>>>> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>>>>> >> stackChunkSize=<optimized out>)
>>>>> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>>>>> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at
>>>>> js1.c:12
>>>>> >>
>>>>> >> Am I missing something simple here?
>>>>> >>
>>>>> >> Thank you!
>>>>> >>
>>>>> >> --Cal
>>>>> >> _______________________________________________
>>>>> >> dev-tech-js-engine mailing list
>>>>> >> [hidden email]
>>>>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > dev-tech-js-engine mailing list
>>>>> > [hidden email]
>>>>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>> >
>>>>> _______________________________________________
>>>>> dev-tech-js-engine mailing list
>>>>> [hidden email]
>>>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
Yes, SpiderMonkey inits a special global at startup which is used for
self-hosted code.

The stacktrace still has too many omissions for me to make sense of it. Can
you load your program in a debugger, figure out what we're segfaulting on
(presumably something is null), and then walk up the stack to figure out
where that null value comes from?

On Mon, Dec 28, 2015 at 2:14 PM, Cal Heldenbrand <[hidden email]> wrote:

> Yes, looks like it.  Here's the new stack trace below.  I don't understand
> why it's going through all of this global class init and bytecode stuff
> when my app hasn't even started that yet.  Does it have something to do
> with the self hosting stuff?
>
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00000000009841bd in js::ScriptBytecodeHasher::hash (l=...)
>     at /download/mozilla-central/js/src/jsscript.h:2408
> #2  0x000000000099f18f in js::detail::HashTable<js::SharedScriptData*
> const, js::HashSet<js::SharedScriptData*, js::ScriptBytecodeHasher,
> js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::prepareHash (l=...)
> at ../../dist/include/js/HashTable.h:1121
> #3  0x000000000099812d in js::detail::HashTable<js::SharedScriptData*
> const, js::HashSet<js::SharedScriptData*, js::ScriptBytecodeHasher,
> js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookupForAdd
> (this=0x2117830, l=...) at ../../dist/include/js/HashTable.h:1633
> #4  0x000000000098f6a3 in js::HashSet<js::SharedScriptData*,
> js::ScriptBytecodeHasher, js::SystemAllocPolicy>::lookupForAdd
> (this=0x2117830, l=...) at ../../dist/include/js/HashTable.h:383
> #5  0x000000000095bf28 in SaveSharedScriptData (cx=0x2130db0, script=...,
> ssd=0x213c540,
>     nsrcnotes=1) at /download/mozilla-central/js/src/jsscript.cpp:2517
> #6  0x000000000095ce46 in JSScript::fullyInitTrivial (cx=0x2130db0,
> script=...)
>     at /download/mozilla-central/js/src/jsscript.cpp:2901
> #7  0x00000000008b271a in CreateFunctionPrototype (cx=0x2130db0,
> key=JSProto_Function)
>     at /download/mozilla-central/js/src/jsfun.cpp:785
> #8  0x0000000000a494be in js::GlobalObject::resolveConstructor
> (cx=0x2130db0, global=...,
>     key=JSProto_Function) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
> #9  0x0000000000a4921e in js::GlobalObject::ensureConstructor
> (cx=0x2130db0, global=...,
>     key=JSProto_Function) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> #10 0x00000000007ab35b in CreateObjectConstructor (cx=0x2130db0,
> key=JSProto_Object)
>     at /download/mozilla-central/js/src/builtin/Object.cpp:1035
> #11 0x0000000000a49560 in js::GlobalObject::resolveConstructor
> (cx=0x2130db0, global=...,
>     key=JSProto_Object) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
> #12 0x0000000000a4921e in js::GlobalObject::ensureConstructor
> (cx=0x2130db0, global=...,
>     key=JSProto_Object) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
> #13 0x00000000004484d7 in js::GlobalObject::getOrCreateObjectPrototype
> (this=0x7ffff7e22060,
>     cx=0x2130db0) at /download/mozilla-central/js/src/vm/GlobalObject.h:342
> #14 0x0000000000e289a0 in CreateArrayPrototype (cx=0x2130db0,
> key=JSProto_Array)
>     at /download/mozilla-central/js/src/jsarray.cpp:3234
> #15 0x0000000000a4a63e in InitBareBuiltinCtor (cx=0x2130db0, global=...,
>     protoKey=JSProto_Array) at
> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
> #16 0x0000000000a4a9ba in js::GlobalObject::initSelfHostingBuiltins
> (cx=0x2130db0,
>     global=..., builtins=0x20ea7a0 <intrinsic_functions>)
>     at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
> #17 0x0000000000b5000b in JSRuntime::createSelfHostingGlobal (cx=0x2130db0)
>     at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
> #18 0x0000000000b5016a in JSRuntime::initSelfHosting (this=0x210eeb0,
> cx=0x2130db0)
>     at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
> #19 0x000000000086b392 in js::NewContext (rt=0x210eeb0,
> stackChunkSize=8192)
>     at /download/mozilla-central/js/src/jscntxt.cpp:122
> #20 0x0000000000856ed6 in JS_NewContext (rt=0x210eeb0, stackChunkSize=8192)
>     at /download/mozilla-central/js/src/jsapi.cpp:568
> #21 0x0000000000405858 in main (argc=1, argv=0x7fffffffd6a8) at js4.c:22
>
>
>
>
> On Mon, Dec 28, 2015 at 3:53 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> Does your new stacktrace have full stack variables (i.e. without the
>> "optimized out" bits)?
>>
>> On Mon, Dec 28, 2015 at 1:51 PM, Cal Heldenbrand <[hidden email]> wrote:
>>
>>> I still see the same segfault.  Am I building the debug build correctly?
>>>
>>> in js/src$  mkdir build_DBG.OBJ
>>> $ cd build_DBG.OBJ
>>> $ ../configure --enable-debug --disable-optimize
>>>
>>> The shared library object is actually *smaller* than the release one.
>>> 118MB vs 157MB.  When I link against the debug shared library, I still get
>>> a segfault.  I was expecting it to toss some assertions if it were
>>> correctly compiled as a debug library.
>>>
>>> I also tried statically linking against libjs_static.a which was 384MB,
>>> and still have the same segfault.
>>>
>>> Any other suggestions to try?
>>>
>>> Thank you!
>>>
>>> --Cal
>>>
>>>
>>>
>>> On Mon, Dec 28, 2015 at 2:59 PM, Cal Heldenbrand <[hidden email]>
>>> wrote:
>>>
>>>> No I was using the release build.  I'll try that next, thanks!
>>>>
>>>>
>>>> On Mon, Dec 28, 2015 at 2:35 PM, Bobby Holley <[hidden email]>
>>>> wrote:
>>>>
>>>>> Are you running with a debug build? There are lots of helpful
>>>>> assertions that will catch potential problems.
>>>>>
>>>>> On Mon, Dec 28, 2015 at 12:10 PM, Cal Heldenbrand <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the reply Kent.  It looks like DefaultHeapMaxBytes is
>>>>>> 32MB.  I
>>>>>> bumped mine down to 8MB (8 * 1024 * 1024), and also reduced the
>>>>>> nursery
>>>>>> bytes to 1MB.  Same issue, I get the same segfault with the same stack
>>>>>> trace.
>>>>>>
>>>>>> I also switched to the other function definition without the nursery
>>>>>> bytes,
>>>>>> like this:
>>>>>>     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
>>>>>> and I still see the same segfault.
>>>>>>
>>>>>> Any other suggestions?  Maybe a runtime option that is required to
>>>>>> create a
>>>>>> new context?  I'm currently studying the js.cpp shell and trying out
>>>>>> different settings to see if anything has an effect.
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> --Cal
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 28, 2015 at 11:14 AM, kent williams <
>>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> > Haven't used that signature for JS_NewRuntime.  The example
>>>>>> (recently
>>>>>> > updated to a version that will actually run to completion with a
>>>>>> Debug
>>>>>> > build) uses the other form which has useHelperThreads as a second
>>>>>> parameter.
>>>>>> >
>>>>>> > First suggestion, use something less than JS::DefaultHeapMaxBytes,
>>>>>> like
>>>>>> > 8192 * 1024 * 1024.
>>>>>> >
>>>>>> > Otherwise try the other signature, as in the example below:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine
>>>>>> >
>>>>>> >
>>>>>> > On 12/23/2015 3:48 PM, Cal Heldenbrand wrote:
>>>>>> >
>>>>>> >> Hello,
>>>>>> >>
>>>>>> >> I'm trying to work through the example embedder's guide using the
>>>>>> current
>>>>>> >> tip (SM 46) in Mercurial.  I've also tried rolling back to 45 and
>>>>>> see the
>>>>>> >> same issue.
>>>>>> >>
>>>>>> >> The bare minimum code to recreate this is really simple:
>>>>>> >>
>>>>>> >> #include <jsapi.h>
>>>>>> >> #include <js/Initialization.h>
>>>>>> >>
>>>>>> >> int main(int argc, const char *argv[])
>>>>>> >> {
>>>>>> >>      JS_Init();
>>>>>> >>
>>>>>> >>      JSRuntime *rt = JS_NewRuntime(
>>>>>> >>          JS::DefaultHeapMaxBytes, JS::DefaultNurseryBytes
>>>>>> >>      );
>>>>>> >>      if (!rt)
>>>>>> >>          return 1;
>>>>>> >>
>>>>>> >>      JSContext *cx = JS_NewContext(rt, 8192);
>>>>>> >>      if (!cx)
>>>>>> >>          return 1;
>>>>>> >>
>>>>>> >>      JS_DestroyContext(cx);
>>>>>> >>      JS_DestroyRuntime(rt);
>>>>>> >>      JS_ShutDown();
>>>>>> >>
>>>>>> >>      return 0;
>>>>>> >>
>>>>>> >> }
>>>>>> >>
>>>>>> >> And, I believe I followed the compile options correctly as well:
>>>>>> >>
>>>>>> >> g++ -g -std=gnu++0x \
>>>>>> >>     -include /usr/local/include/mozjs-46a1/js/RequiredDefines.h \
>>>>>> >>     -I/usr/local/include/mozjs-46a1 js1.c -o js1 -lmozjs-46a1 -lz
>>>>>> >> -lpthread
>>>>>> >> -ldl
>>>>>> >> In file included from /usr/include/string.h:32:0,
>>>>>> >>                   from
>>>>>> /usr/local/include/mozjs-46a1/js/Utility.h:19,
>>>>>> >>                   from /usr/local/include/mozjs-46a1/jsalloc.h:18,
>>>>>> >>                   from /usr/local/include/mozjs-46a1/jsapi.h:24,
>>>>>> >>                   from js4.c:1:
>>>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: invalid
>>>>>> access to
>>>>>> >> non-static data member
>>>>>> >> ‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL
>>>>>> object
>>>>>> >> [-Winvalid-offsetof]
>>>>>> >>       static const size_t RuntimeMainThreadOffset =
>>>>>> offsetof(RuntimeDummy,
>>>>>> >> mainThread);
>>>>>> >>
>>>>>> >>  ^
>>>>>> >> /usr/local/include/mozjs-46a1/jspubtd.h:474:74: warning: (perhaps
>>>>>> the
>>>>>> >> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
>>>>>> >>
>>>>>> >> Besides the warnings it seems to compile fine.
>>>>>> >>
>>>>>> >> Here's the stack trace from gdb when running it:
>>>>>> >>
>>>>>> >> [New Thread 0x7ffff56cb700 (LWP 20062)]
>>>>>> >> [New Thread 0x7ffff54ca700 (LWP 20065)]
>>>>>> >> [New Thread 0x7ffff52c9700 (LWP 20066)]
>>>>>> >> [New Thread 0x7ffff50c8700 (LWP 20067)]
>>>>>> >> [New Thread 0x7ffff4ec7700 (LWP 20068)]
>>>>>> >> [New Thread 0x7ffff4cc6700 (LWP 20069)]
>>>>>> >> [New Thread 0x7ffff4ac5700 (LWP 20070)]
>>>>>> >> [New Thread 0x7ffff48c4700 (LWP 20071)]
>>>>>> >> [New Thread 0x7ffff46c3700 (LWP 20072)]
>>>>>> >> [New Thread 0x7ffff44c2700 (LWP 20073)]
>>>>>> >> [New Thread 0x7ffff42c1700 (LWP 20074)]
>>>>>> >> [New Thread 0x7ffff40c0700 (LWP 20075)]
>>>>>> >>
>>>>>> >> Program received signal SIGSEGV, Segmentation fault.
>>>>>> >> 0x0000000000000000 in ?? ()
>>>>>> >> (gdb) bt
>>>>>> >> #0  0x0000000000000000 in ?? ()
>>>>>> >> #1  0x00007ffff6d771bb in hash (l=..., l=...) at
>>>>>> >> /download/mozilla-central/js/src/jsscript.h:2408
>>>>>> >> #2  prepareHash (l=<synthetic pointer>) at
>>>>>> >> ../../dist/include/js/HashTable.h:1121
>>>>>> >> #3  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>>>> >> ../../dist/include/js/HashTable.h:1633
>>>>>> >> #4  lookupForAdd (l=<synthetic pointer>, this=0x60b358) at
>>>>>> >> ../../dist/include/js/HashTable.h:383
>>>>>> >> #5  SaveSharedScriptData (cx=cx@entry=0x624540, script=...,
>>>>>> ssd=0x634400,
>>>>>> >> nsrcnotes=1)
>>>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2517
>>>>>> >> #6  0x00007ffff6d776d5 in JSScript::fullyInitTrivial (cx=cx@entry
>>>>>> >> =0x624540,
>>>>>> >> script=..., script@entry=...)
>>>>>> >>      at /download/mozilla-central/js/src/jsscript.cpp:2901
>>>>>> >> #7  0x00007ffff6d38d29 in CreateFunctionPrototype (cx=0x624540,
>>>>>> >> key=<optimized out>)
>>>>>> >>      at /download/mozilla-central/js/src/jsfun.cpp:785
>>>>>> >> #8  0x00007ffff6decc01 in js::GlobalObject::resolveConstructor
>>>>>> >> (cx=0x624540, global=..., key=JSProto_Function)
>>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:158
>>>>>> >> #9  0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>>>> >> (cx=cx@entry=0x624540,
>>>>>> >> global=..., global@entry=...,
>>>>>> >>      key=key@entry=JSProto_Function) at
>>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>>>> >> #10 0x00007ffff6c6f58f in CreateObjectConstructor (cx=0x624540,
>>>>>> >> key=<optimized out>)
>>>>>> >>      at /download/mozilla-central/js/src/builtin/Object.cpp:1035
>>>>>> >> #11 0x00007ffff6decc75 in js::GlobalObject::resolveConstructor
>>>>>> >> (cx=0x624540, global=..., key=JSProto_Object)
>>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:166
>>>>>> >> #12 0x00007ffff6ded0e9 in js::GlobalObject::ensureConstructor
>>>>>> >> (cx=cx@entry=0x624540,
>>>>>> >> global=..., global@entry=...,
>>>>>> >>      key=key@entry=JSProto_Object) at
>>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:98
>>>>>> >> #13 0x00007ffff6a5b948 in getOrCreateObjectPrototype (cx=0x624540,
>>>>>> >> this=<optimized out>)
>>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.h:342
>>>>>> >> #14 CreateArrayPrototype (cx=0x624540, key=<optimized out>) at
>>>>>> >> /download/mozilla-central/js/src/jsarray.cpp:3234
>>>>>> >> #15 0x00007ffff6def431 in InitBareBuiltinCtor (cx=cx@entry
>>>>>> =0x624540,
>>>>>> >> global=..., global@entry=...,
>>>>>> >>      protoKey=protoKey@entry=JSProto_Array) at
>>>>>> >> /download/mozilla-central/js/src/vm/GlobalObject.cpp:368
>>>>>> >> #16 0x00007ffff6def630 in js::GlobalObject::initSelfHostingBuiltins
>>>>>> >> (cx=cx@entry=0x624540,
>>>>>> >>      global=global@entry=..., builtins=builtins@entry
>>>>>> =0x7ffff7db89c0
>>>>>> >> <intrinsic_functions>)
>>>>>> >>      at /download/mozilla-central/js/src/vm/GlobalObject.cpp:413
>>>>>> >> #17 0x00007ffff6e7f66e in JSRuntime::createSelfHostingGlobal
>>>>>> (cx=cx@entry
>>>>>> >> =0x624540)
>>>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1738
>>>>>> >> #18 0x00007ffff6e7f795 in JSRuntime::initSelfHosting
>>>>>> (this=this@entry
>>>>>> >> =0x602e10,
>>>>>> >> cx=cx@entry=0x624540)
>>>>>> >>      at /download/mozilla-central/js/src/vm/SelfHosting.cpp:1762
>>>>>> >> #19 0x00007ffff6cf9d83 in js::NewContext (rt=0x602e10,
>>>>>> >> stackChunkSize=<optimized out>)
>>>>>> >>      at /download/mozilla-central/js/src/jscntxt.cpp:122
>>>>>> >> #20 0x00000000004008e8 in main (argc=1, argv=0x7fffffffd6d8) at
>>>>>> js1.c:12
>>>>>> >>
>>>>>> >> Am I missing something simple here?
>>>>>> >>
>>>>>> >> Thank you!
>>>>>> >>
>>>>>> >> --Cal
>>>>>> >> _______________________________________________
>>>>>> >> dev-tech-js-engine mailing list
>>>>>> >> [hidden email]
>>>>>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>>> >>
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > dev-tech-js-engine mailing list
>>>>>> > [hidden email]
>>>>>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>>> >
>>>>>> _______________________________________________
>>>>>> dev-tech-js-engine mailing list
>>>>>> [hidden email]
>>>>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
Hi Bobby,

I have some info to provide, but I'm no expert on the intricacies of this
API.  Attached is a file of the console output from me screwing around in
gdb.  I believe what it comes down to, is the hash Lookup object "l"
contains only 1 byte of code, but the length has been assigned to 4.
The mozilla::HashBytes() function is working with operations in words of 8
bytes.  It's stepping past the length of l.code and smashing the stack.

But I don't quite understand where the 4 bytes is coming from.

In frame 6, the *ssd object is set to:

    ssd->data[0] = JSOP_RETRVAL;
    ssd->data[1] = SRC_NULL;

The SharedScriptData::new_ constructor has a really complicated method for
calculating the length, and I suspect the hard coded

     SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);

in fullyInitTrivial() might be to blame there.  The script source itself is
just "() {\n}" and is 6 bytes.  It's coming from CreateFunctionPrototype()
in jsfun.cpp.

Hope this sheds some light on the issue!  Let me know if you want any other
variables printed.  Do you think I should submit a bugzilla issue for this?

Thank you,

--Cal

On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]> wrote:

> Yes, SpiderMonkey inits a special global at startup which is used for
> self-hosted code.
>
> The stacktrace still has too many omissions for me to make sense of it.
> Can you load your program in a debugger, figure out what we're segfaulting
> on (presumably something is null), and then walk up the stack to figure out
> where that null value comes from?
>
>

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine

gdb.txt (28K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
As a follow up, the more I play with this, the more I think there is some
kind of problem with the definition of the mozilla::HashBytes() function
itself.  If I add some debug prints to the function, they never print.
(But I see them when running the js shell binary)

If I just call something simple in my main() function, like this:

    int hash = mozilla::HashBytes("1234", 4);

It also segfaults.  The stack trace shows the same style of segfault, the
frame address is 0x0000000000000000.

--Cal
<[hidden email]>

On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]> wrote:

> Hi Bobby,
>
> I have some info to provide, but I'm no expert on the intricacies of this
> API.  Attached is a file of the console output from me screwing around in
> gdb.  I believe what it comes down to, is the hash Lookup object "l"
> contains only 1 byte of code, but the length has been assigned to 4.
> The mozilla::HashBytes() function is working with operations in words of 8
> bytes.  It's stepping past the length of l.code and smashing the stack.
>
> But I don't quite understand where the 4 bytes is coming from.
>
> In frame 6, the *ssd object is set to:
>
>     ssd->data[0] = JSOP_RETRVAL;
>     ssd->data[1] = SRC_NULL;
>
> The SharedScriptData::new_ constructor has a really complicated method for
> calculating the length, and I suspect the hard coded
>
>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>
> in fullyInitTrivial() might be to blame there.  The script source itself
> is just "() {\n}" and is 6 bytes.  It's coming from
> CreateFunctionPrototype() in jsfun.cpp.
>
> Hope this sheds some light on the issue!  Let me know if you want any
> other variables printed.  Do you think I should submit a bugzilla issue for
> this?
>
> Thank you,
>
> --Cal
>
> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> Yes, SpiderMonkey inits a special global at startup which is used for
>> self-hosted code.
>>
>> The stacktrace still has too many omissions for me to make sense of it.
>> Can you load your program in a debugger, figure out what we're segfaulting
>> on (presumably something is null), and then walk up the stack to figure out
>> where that null value comes from?
>>
>>
>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
What is the stacktrace of the HashBytes crash? I don't see that in your
original stack.

Anyway, it sounds like you're pretty close to figuring it out. Please file
a bug with the patch when you do. :-)

On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]> wrote:

> As a follow up, the more I play with this, the more I think there is some
> kind of problem with the definition of the mozilla::HashBytes() function
> itself.  If I add some debug prints to the function, they never print.
> (But I see them when running the js shell binary)
>
> If I just call something simple in my main() function, like this:
>
>     int hash = mozilla::HashBytes("1234", 4);
>
> It also segfaults.  The stack trace shows the same style of segfault, the
> frame address is 0x0000000000000000.
>
> --Cal
> <[hidden email]>
>
> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]> wrote:
>
>> Hi Bobby,
>>
>> I have some info to provide, but I'm no expert on the intricacies of this
>> API.  Attached is a file of the console output from me screwing around in
>> gdb.  I believe what it comes down to, is the hash Lookup object "l"
>> contains only 1 byte of code, but the length has been assigned to 4.
>> The mozilla::HashBytes() function is working with operations in words of
>> 8 bytes.  It's stepping past the length of l.code and smashing the stack.
>>
>> But I don't quite understand where the 4 bytes is coming from.
>>
>> In frame 6, the *ssd object is set to:
>>
>>     ssd->data[0] = JSOP_RETRVAL;
>>     ssd->data[1] = SRC_NULL;
>>
>> The SharedScriptData::new_ constructor has a really complicated method
>> for calculating the length, and I suspect the hard coded
>>
>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>>
>> in fullyInitTrivial() might be to blame there.  The script source itself
>> is just "() {\n}" and is 6 bytes.  It's coming from
>> CreateFunctionPrototype() in jsfun.cpp.
>>
>> Hope this sheds some light on the issue!  Let me know if you want any
>> other variables printed.  Do you think I should submit a bugzilla issue for
>> this?
>>
>> Thank you,
>>
>> --Cal
>>
>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]>
>> wrote:
>>
>>> Yes, SpiderMonkey inits a special global at startup which is used for
>>> self-hosted code.
>>>
>>> The stacktrace still has too many omissions for me to make sense of it.
>>> Can you load your program in a debugger, figure out what we're segfaulting
>>> on (presumably something is null), and then walk up the stack to figure out
>>> where that null value comes from?
>>>
>>>
>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
Well this doesn't make any sense to me, but it has something to do with the
prototype of HashBytes in HashFunctions.h:

MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
HashBytes(const void* bytes, size_t aLength);

All I have to do to make it crash is this:

------------------------------------------
#include <js-confdefs.h>
#include <mozilla/HashFunctions.h>

int main(int argc, char** argv, char** envp)
{
  int hash = mozilla::HashBytes("1234", 4);
}
------------------------------------------
The backtrace just shows:
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000040059b in main (argc=1, argv=0x7fffffffd6c8) at js6.c:6

If I modify HashFunctions.h and add another function without the macro
prefixes, and call it, then it works.

HashFunctions.h
-------------------------------------------
  ...
/**
 * Hash some number of bytes.
 *
 * This hash walks word-by-word, rather than byte-by-byte, so you won't get
the
 * same result out of HashBytes as you would out of HashString.
 */
MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
HashBytes(const void* bytes, size_t aLength);

uint32_t testfun(void);
-------------------------------------------
(Note that if I include MOZ_WARN_UNUSED_RESULT extern MFBT_API on the
testfun() prototype, the program will still crash.)

HashFunctions.cpp
-------------------------------------------
namespace mozilla {
uint32_t testfun(void)
{
  fprintf(stderr, "IN testfun()\n");
  return 0;
}
...
-------------------------------------------


Here's the C program that does not segfault:

------------------------------------------
#include <js-confdefs.h>
#include <mozilla/HashFunctions.h>

int main(int argc, char** argv, char** envp)
{
    mozilla::testfun();
    int hash = mozilla::HashBytes("1234", 4);
    fprintf(stderr, "hash test: %d\n", hash);
    return 0;
}
------------------------------------------

which outputs:
------------------------------------------
IN testfun()
hash test: 953478926
------------------------------------------

If I do not call testfun() from main, the program also crashes.

I'll submit a bug report on this, and document my compiler and kernel
versions and all that.  This at least gets me far enough to proceed with my
project.

Thanks!

--Cal

<[hidden email]>

On Tue, Dec 29, 2015 at 4:33 PM, Bobby Holley <[hidden email]> wrote:

> What is the stacktrace of the HashBytes crash? I don't see that in your
> original stack.
>
> Anyway, it sounds like you're pretty close to figuring it out. Please file
> a bug with the patch when you do. :-)
>
> On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]> wrote:
>
>> As a follow up, the more I play with this, the more I think there is some
>> kind of problem with the definition of the mozilla::HashBytes() function
>> itself.  If I add some debug prints to the function, they never print.
>> (But I see them when running the js shell binary)
>>
>> If I just call something simple in my main() function, like this:
>>
>>     int hash = mozilla::HashBytes("1234", 4);
>>
>> It also segfaults.  The stack trace shows the same style of segfault, the
>> frame address is 0x0000000000000000.
>>
>> --Cal
>> <[hidden email]>
>>
>> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]> wrote:
>>
>>> Hi Bobby,
>>>
>>> I have some info to provide, but I'm no expert on the intricacies of
>>> this API.  Attached is a file of the console output from me screwing around
>>> in gdb.  I believe what it comes down to, is the hash Lookup object "l"
>>> contains only 1 byte of code, but the length has been assigned to 4.
>>> The mozilla::HashBytes() function is working with operations in words of
>>> 8 bytes.  It's stepping past the length of l.code and smashing the stack.
>>>
>>> But I don't quite understand where the 4 bytes is coming from.
>>>
>>> In frame 6, the *ssd object is set to:
>>>
>>>     ssd->data[0] = JSOP_RETRVAL;
>>>     ssd->data[1] = SRC_NULL;
>>>
>>> The SharedScriptData::new_ constructor has a really complicated method
>>> for calculating the length, and I suspect the hard coded
>>>
>>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>>>
>>> in fullyInitTrivial() might be to blame there.  The script source itself
>>> is just "() {\n}" and is 6 bytes.  It's coming from
>>> CreateFunctionPrototype() in jsfun.cpp.
>>>
>>> Hope this sheds some light on the issue!  Let me know if you want any
>>> other variables printed.  Do you think I should submit a bugzilla issue for
>>> this?
>>>
>>> Thank you,
>>>
>>> --Cal
>>>
>>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]>
>>> wrote:
>>>
>>>> Yes, SpiderMonkey inits a special global at startup which is used for
>>>> self-hosted code.
>>>>
>>>> The stacktrace still has too many omissions for me to make sense of it.
>>>> Can you load your program in a debugger, figure out what we're segfaulting
>>>> on (presumably something is null), and then walk up the stack to figure out
>>>> where that null value comes from?
>>>>
>>>>
>>>
>>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
Presumably, the preprocessor expansion of MFBT_API is causing trouble. You
can easily get to the bottom of it by spitting out the preprocessed source
(i.e. seeing what MFBT_API expands to in your environment) and comparing
the generated assembly with and without the decorators.

This might be a good time to make sure you're compiling with a supported
toolchain. See
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions#Build_prerequisites

On Wed, Dec 30, 2015 at 12:07 PM, Cal Heldenbrand <[hidden email]> wrote:

> Well this doesn't make any sense to me, but it has something to do with
> the prototype of HashBytes in HashFunctions.h:
>
> MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
> HashBytes(const void* bytes, size_t aLength);
>
> All I have to do to make it crash is this:
>
> ------------------------------------------
> #include <js-confdefs.h>
> #include <mozilla/HashFunctions.h>
>
> int main(int argc, char** argv, char** envp)
> {
>   int hash = mozilla::HashBytes("1234", 4);
> }
> ------------------------------------------
> The backtrace just shows:
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x000000000040059b in main (argc=1, argv=0x7fffffffd6c8) at js6.c:6
>
> If I modify HashFunctions.h and add another function without the macro
> prefixes, and call it, then it works.
>
> HashFunctions.h
> -------------------------------------------
>   ...
> /**
>  * Hash some number of bytes.
>  *
>  * This hash walks word-by-word, rather than byte-by-byte, so you won't
> get the
>  * same result out of HashBytes as you would out of HashString.
>  */
> MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
> HashBytes(const void* bytes, size_t aLength);
>
> uint32_t testfun(void);
> -------------------------------------------
> (Note that if I include MOZ_WARN_UNUSED_RESULT extern MFBT_API on the
> testfun() prototype, the program will still crash.)
>
> HashFunctions.cpp
> -------------------------------------------
> namespace mozilla {
> uint32_t testfun(void)
> {
>   fprintf(stderr, "IN testfun()\n");
>   return 0;
> }
> ...
> -------------------------------------------
>
>
> Here's the C program that does not segfault:
>
> ------------------------------------------
> #include <js-confdefs.h>
> #include <mozilla/HashFunctions.h>
>
> int main(int argc, char** argv, char** envp)
> {
>     mozilla::testfun();
>     int hash = mozilla::HashBytes("1234", 4);
>     fprintf(stderr, "hash test: %d\n", hash);
>     return 0;
> }
> ------------------------------------------
>
> which outputs:
> ------------------------------------------
> IN testfun()
> hash test: 953478926
> ------------------------------------------
>
> If I do not call testfun() from main, the program also crashes.
>
> I'll submit a bug report on this, and document my compiler and kernel
> versions and all that.  This at least gets me far enough to proceed with my
> project.
>
> Thanks!
>
> --Cal
>
> <[hidden email]>
>
> On Tue, Dec 29, 2015 at 4:33 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> What is the stacktrace of the HashBytes crash? I don't see that in your
>> original stack.
>>
>> Anyway, it sounds like you're pretty close to figuring it out. Please
>> file a bug with the patch when you do. :-)
>>
>> On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]> wrote:
>>
>>> As a follow up, the more I play with this, the more I think there is
>>> some kind of problem with the definition of the mozilla::HashBytes()
>>> function itself.  If I add some debug prints to the function, they never
>>> print.  (But I see them when running the js shell binary)
>>>
>>> If I just call something simple in my main() function, like this:
>>>
>>>     int hash = mozilla::HashBytes("1234", 4);
>>>
>>> It also segfaults.  The stack trace shows the same style of segfault,
>>> the frame address is 0x0000000000000000.
>>>
>>> --Cal
>>> <[hidden email]>
>>>
>>> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]>
>>> wrote:
>>>
>>>> Hi Bobby,
>>>>
>>>> I have some info to provide, but I'm no expert on the intricacies of
>>>> this API.  Attached is a file of the console output from me screwing around
>>>> in gdb.  I believe what it comes down to, is the hash Lookup object "l"
>>>> contains only 1 byte of code, but the length has been assigned to 4.
>>>> The mozilla::HashBytes() function is working with operations in words
>>>> of 8 bytes.  It's stepping past the length of l.code and smashing the stack.
>>>>
>>>> But I don't quite understand where the 4 bytes is coming from.
>>>>
>>>> In frame 6, the *ssd object is set to:
>>>>
>>>>     ssd->data[0] = JSOP_RETRVAL;
>>>>     ssd->data[1] = SRC_NULL;
>>>>
>>>> The SharedScriptData::new_ constructor has a really complicated method
>>>> for calculating the length, and I suspect the hard coded
>>>>
>>>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>>>>
>>>> in fullyInitTrivial() might be to blame there.  The script source
>>>> itself is just "() {\n}" and is 6 bytes.  It's coming from
>>>> CreateFunctionPrototype() in jsfun.cpp.
>>>>
>>>> Hope this sheds some light on the issue!  Let me know if you want any
>>>> other variables printed.  Do you think I should submit a bugzilla issue for
>>>> this?
>>>>
>>>> Thank you,
>>>>
>>>> --Cal
>>>>
>>>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]>
>>>> wrote:
>>>>
>>>>> Yes, SpiderMonkey inits a special global at startup which is used for
>>>>> self-hosted code.
>>>>>
>>>>> The stacktrace still has too many omissions for me to make sense of
>>>>> it. Can you load your program in a debugger, figure out what we're
>>>>> segfaulting on (presumably something is null), and then walk up the stack
>>>>> to figure out where that null value comes from?
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
Hmm, yeah running my GNU g++ with -E on my test program gives me a
definition like:

__attribute__ ((warn_unused_result)) extern __attribute__((weak))
__attribute__((visibility("default"))) uint32_t
HashBytes(const void* bytes, size_t aLength);

I'm using a plain Ubuntu 14.04 Trusty machine, gcc 4.8.4, kernel 3.13.0.
Just glancing through the prerequisites list, it looks like I'm okay.

Although, I didn't use the mach build system, I followed the SpiderMonkey
Build Documentation page and just ran configure in the js/src directory.
Could that be the issue? I suppose I could go through a full Firefox build
and see if anything changes.


On Wed, Dec 30, 2015 at 2:16 PM, Bobby Holley <[hidden email]> wrote:

> Presumably, the preprocessor expansion of MFBT_API is causing trouble. You
> can easily get to the bottom of it by spitting out the preprocessed source
> (i.e. seeing what MFBT_API expands to in your environment) and comparing
> the generated assembly with and without the decorators.
>
> This might be a good time to make sure you're compiling with a supported
> toolchain. See
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions#Build_prerequisites
>
> On Wed, Dec 30, 2015 at 12:07 PM, Cal Heldenbrand <[hidden email]> wrote:
>
> > Well this doesn't make any sense to me, but it has something to do with
> > the prototype of HashBytes in HashFunctions.h:
> >
> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
> > HashBytes(const void* bytes, size_t aLength);
> >
> > All I have to do to make it crash is this:
> >
> > ------------------------------------------
> > #include <js-confdefs.h>
> > #include <mozilla/HashFunctions.h>
> >
> > int main(int argc, char** argv, char** envp)
> > {
> >   int hash = mozilla::HashBytes("1234", 4);
> > }
> > ------------------------------------------
> > The backtrace just shows:
> > (gdb) bt
> > #0  0x0000000000000000 in ?? ()
> > #1  0x000000000040059b in main (argc=1, argv=0x7fffffffd6c8) at js6.c:6
> >
> > If I modify HashFunctions.h and add another function without the macro
> > prefixes, and call it, then it works.
> >
> > HashFunctions.h
> > -------------------------------------------
> >   ...
> > /**
> >  * Hash some number of bytes.
> >  *
> >  * This hash walks word-by-word, rather than byte-by-byte, so you won't
> > get the
> >  * same result out of HashBytes as you would out of HashString.
> >  */
> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
> > HashBytes(const void* bytes, size_t aLength);
> >
> > uint32_t testfun(void);
> > -------------------------------------------
> > (Note that if I include MOZ_WARN_UNUSED_RESULT extern MFBT_API on the
> > testfun() prototype, the program will still crash.)
> >
> > HashFunctions.cpp
> > -------------------------------------------
> > namespace mozilla {
> > uint32_t testfun(void)
> > {
> >   fprintf(stderr, "IN testfun()\n");
> >   return 0;
> > }
> > ...
> > -------------------------------------------
> >
> >
> > Here's the C program that does not segfault:
> >
> > ------------------------------------------
> > #include <js-confdefs.h>
> > #include <mozilla/HashFunctions.h>
> >
> > int main(int argc, char** argv, char** envp)
> > {
> >     mozilla::testfun();
> >     int hash = mozilla::HashBytes("1234", 4);
> >     fprintf(stderr, "hash test: %d\n", hash);
> >     return 0;
> > }
> > ------------------------------------------
> >
> > which outputs:
> > ------------------------------------------
> > IN testfun()
> > hash test: 953478926
> > ------------------------------------------
> >
> > If I do not call testfun() from main, the program also crashes.
> >
> > I'll submit a bug report on this, and document my compiler and kernel
> > versions and all that.  This at least gets me far enough to proceed with
> my
> > project.
> >
> > Thanks!
> >
> > --Cal
> >
> > <[hidden email]>
> >
> > On Tue, Dec 29, 2015 at 4:33 PM, Bobby Holley <[hidden email]>
> > wrote:
> >
> >> What is the stacktrace of the HashBytes crash? I don't see that in your
> >> original stack.
> >>
> >> Anyway, it sounds like you're pretty close to figuring it out. Please
> >> file a bug with the patch when you do. :-)
> >>
> >> On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]>
> wrote:
> >>
> >>> As a follow up, the more I play with this, the more I think there is
> >>> some kind of problem with the definition of the mozilla::HashBytes()
> >>> function itself.  If I add some debug prints to the function, they
> never
> >>> print.  (But I see them when running the js shell binary)
> >>>
> >>> If I just call something simple in my main() function, like this:
> >>>
> >>>     int hash = mozilla::HashBytes("1234", 4);
> >>>
> >>> It also segfaults.  The stack trace shows the same style of segfault,
> >>> the frame address is 0x0000000000000000.
> >>>
> >>> --Cal
> >>> <[hidden email]>
> >>>
> >>> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]>
> >>> wrote:
> >>>
> >>>> Hi Bobby,
> >>>>
> >>>> I have some info to provide, but I'm no expert on the intricacies of
> >>>> this API.  Attached is a file of the console output from me screwing
> around
> >>>> in gdb.  I believe what it comes down to, is the hash Lookup object
> "l"
> >>>> contains only 1 byte of code, but the length has been assigned to 4.
> >>>> The mozilla::HashBytes() function is working with operations in words
> >>>> of 8 bytes.  It's stepping past the length of l.code and smashing the
> stack.
> >>>>
> >>>> But I don't quite understand where the 4 bytes is coming from.
> >>>>
> >>>> In frame 6, the *ssd object is set to:
> >>>>
> >>>>     ssd->data[0] = JSOP_RETRVAL;
> >>>>     ssd->data[1] = SRC_NULL;
> >>>>
> >>>> The SharedScriptData::new_ constructor has a really complicated method
> >>>> for calculating the length, and I suspect the hard coded
> >>>>
> >>>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
> >>>>
> >>>> in fullyInitTrivial() might be to blame there.  The script source
> >>>> itself is just "() {\n}" and is 6 bytes.  It's coming from
> >>>> CreateFunctionPrototype() in jsfun.cpp.
> >>>>
> >>>> Hope this sheds some light on the issue!  Let me know if you want any
> >>>> other variables printed.  Do you think I should submit a bugzilla
> issue for
> >>>> this?
> >>>>
> >>>> Thank you,
> >>>>
> >>>> --Cal
> >>>>
> >>>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>> Yes, SpiderMonkey inits a special global at startup which is used for
> >>>>> self-hosted code.
> >>>>>
> >>>>> The stacktrace still has too many omissions for me to make sense of
> >>>>> it. Can you load your program in a debugger, figure out what we're
> >>>>> segfaulting on (presumably something is null), and then walk up the
> stack
> >>>>> to figure out where that null value comes from?
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

Bobby Holley-2
Yes, definitely try a Firefox build if you haven't already and see if that
works with your toolchain.

On Wed, Dec 30, 2015 at 12:47 PM, Cal Heldenbrand <[hidden email]> wrote:

> Hmm, yeah running my GNU g++ with -E on my test program gives me a
> definition like:
>
> __attribute__ ((warn_unused_result)) extern __attribute__((weak))
> __attribute__((visibility("default"))) uint32_t
> HashBytes(const void* bytes, size_t aLength);
>
> I'm using a plain Ubuntu 14.04 Trusty machine, gcc 4.8.4, kernel 3.13.0.
> Just glancing through the prerequisites list, it looks like I'm okay.
>
> Although, I didn't use the mach build system, I followed the SpiderMonkey
> Build Documentation page and just ran configure in the js/src directory.
> Could that be the issue? I suppose I could go through a full Firefox build
> and see if anything changes.
>
>
> On Wed, Dec 30, 2015 at 2:16 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> Presumably, the preprocessor expansion of MFBT_API is causing trouble. You
>> can easily get to the bottom of it by spitting out the preprocessed source
>> (i.e. seeing what MFBT_API expands to in your environment) and comparing
>> the generated assembly with and without the decorators.
>>
>> This might be a good time to make sure you're compiling with a supported
>> toolchain. See
>>
>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions#Build_prerequisites
>>
>> On Wed, Dec 30, 2015 at 12:07 PM, Cal Heldenbrand <[hidden email]>
>> wrote:
>>
>> > Well this doesn't make any sense to me, but it has something to do with
>> > the prototype of HashBytes in HashFunctions.h:
>> >
>> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
>> > HashBytes(const void* bytes, size_t aLength);
>> >
>> > All I have to do to make it crash is this:
>> >
>> > ------------------------------------------
>> > #include <js-confdefs.h>
>> > #include <mozilla/HashFunctions.h>
>> >
>> > int main(int argc, char** argv, char** envp)
>> > {
>> >   int hash = mozilla::HashBytes("1234", 4);
>> > }
>> > ------------------------------------------
>> > The backtrace just shows:
>> > (gdb) bt
>> > #0  0x0000000000000000 in ?? ()
>> > #1  0x000000000040059b in main (argc=1, argv=0x7fffffffd6c8) at js6.c:6
>> >
>> > If I modify HashFunctions.h and add another function without the macro
>> > prefixes, and call it, then it works.
>> >
>> > HashFunctions.h
>> > -------------------------------------------
>> >   ...
>> > /**
>> >  * Hash some number of bytes.
>> >  *
>> >  * This hash walks word-by-word, rather than byte-by-byte, so you won't
>> > get the
>> >  * same result out of HashBytes as you would out of HashString.
>> >  */
>> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
>> > HashBytes(const void* bytes, size_t aLength);
>> >
>> > uint32_t testfun(void);
>> > -------------------------------------------
>> > (Note that if I include MOZ_WARN_UNUSED_RESULT extern MFBT_API on the
>> > testfun() prototype, the program will still crash.)
>> >
>> > HashFunctions.cpp
>> > -------------------------------------------
>> > namespace mozilla {
>> > uint32_t testfun(void)
>> > {
>> >   fprintf(stderr, "IN testfun()\n");
>> >   return 0;
>> > }
>> > ...
>> > -------------------------------------------
>> >
>> >
>> > Here's the C program that does not segfault:
>> >
>> > ------------------------------------------
>> > #include <js-confdefs.h>
>> > #include <mozilla/HashFunctions.h>
>> >
>> > int main(int argc, char** argv, char** envp)
>> > {
>> >     mozilla::testfun();
>> >     int hash = mozilla::HashBytes("1234", 4);
>> >     fprintf(stderr, "hash test: %d\n", hash);
>> >     return 0;
>> > }
>> > ------------------------------------------
>> >
>> > which outputs:
>> > ------------------------------------------
>> > IN testfun()
>> > hash test: 953478926
>> > ------------------------------------------
>> >
>> > If I do not call testfun() from main, the program also crashes.
>> >
>> > I'll submit a bug report on this, and document my compiler and kernel
>> > versions and all that.  This at least gets me far enough to proceed
>> with my
>> > project.
>> >
>> > Thanks!
>> >
>> > --Cal
>> >
>> > <[hidden email]>
>> >
>> > On Tue, Dec 29, 2015 at 4:33 PM, Bobby Holley <[hidden email]>
>> > wrote:
>> >
>> >> What is the stacktrace of the HashBytes crash? I don't see that in your
>> >> original stack.
>> >>
>> >> Anyway, it sounds like you're pretty close to figuring it out. Please
>> >> file a bug with the patch when you do. :-)
>> >>
>> >> On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]>
>> wrote:
>> >>
>> >>> As a follow up, the more I play with this, the more I think there is
>> >>> some kind of problem with the definition of the mozilla::HashBytes()
>> >>> function itself.  If I add some debug prints to the function, they
>> never
>> >>> print.  (But I see them when running the js shell binary)
>> >>>
>> >>> If I just call something simple in my main() function, like this:
>> >>>
>> >>>     int hash = mozilla::HashBytes("1234", 4);
>> >>>
>> >>> It also segfaults.  The stack trace shows the same style of segfault,
>> >>> the frame address is 0x0000000000000000.
>> >>>
>> >>> --Cal
>> >>> <[hidden email]>
>>
>> >>>
>> >>> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]>
>> >>> wrote:
>> >>>
>> >>>> Hi Bobby,
>> >>>>
>> >>>> I have some info to provide, but I'm no expert on the intricacies of
>> >>>> this API.  Attached is a file of the console output from me screwing
>> around
>> >>>> in gdb.  I believe what it comes down to, is the hash Lookup object
>> "l"
>> >>>> contains only 1 byte of code, but the length has been assigned to 4.
>> >>>> The mozilla::HashBytes() function is working with operations in words
>> >>>> of 8 bytes.  It's stepping past the length of l.code and smashing
>> the stack.
>> >>>>
>> >>>> But I don't quite understand where the 4 bytes is coming from.
>> >>>>
>> >>>> In frame 6, the *ssd object is set to:
>> >>>>
>> >>>>     ssd->data[0] = JSOP_RETRVAL;
>> >>>>     ssd->data[1] = SRC_NULL;
>> >>>>
>> >>>> The SharedScriptData::new_ constructor has a really complicated
>> method
>> >>>> for calculating the length, and I suspect the hard coded
>> >>>>
>> >>>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>> >>>>
>> >>>> in fullyInitTrivial() might be to blame there.  The script source
>> >>>> itself is just "() {\n}" and is 6 bytes.  It's coming from
>> >>>> CreateFunctionPrototype() in jsfun.cpp.
>> >>>>
>> >>>> Hope this sheds some light on the issue!  Let me know if you want any
>> >>>> other variables printed.  Do you think I should submit a bugzilla
>> issue for
>> >>>> this?
>> >>>>
>> >>>> Thank you,
>> >>>>
>> >>>> --Cal
>> >>>>
>> >>>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <[hidden email]
>> >
>> >>>> wrote:
>> >>>>
>> >>>>> Yes, SpiderMonkey inits a special global at startup which is used
>> for
>> >>>>> self-hosted code.
>> >>>>>
>> >>>>> The stacktrace still has too many omissions for me to make sense of
>> >>>>> it. Can you load your program in a debugger, figure out what we're
>> >>>>> segfaulting on (presumably something is null), and then walk up the
>> stack
>> >>>>> to figure out where that null value comes from?
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in JS_NewContext()

cal (Bugzilla)
I tried both a release and debug compile with the mach build system, and
received the same results.  But I found a little more info by trial & error
and documented it in bug 1236085
<https://bugzilla.mozilla.org/show_bug.cgi?id=1236085>, if anyone wants to
watch and follow this issue.

Thanks everyone!

--Cal

On Wed, Dec 30, 2015 at 2:50 PM, Bobby Holley <[hidden email]> wrote:

> Yes, definitely try a Firefox build if you haven't already and see if that
> works with your toolchain.
>
> On Wed, Dec 30, 2015 at 12:47 PM, Cal Heldenbrand <[hidden email]> wrote:
>
>> Hmm, yeah running my GNU g++ with -E on my test program gives me a
>> definition like:
>>
>> __attribute__ ((warn_unused_result)) extern __attribute__((weak))
>> __attribute__((visibility("default"))) uint32_t
>> HashBytes(const void* bytes, size_t aLength);
>>
>> I'm using a plain Ubuntu 14.04 Trusty machine, gcc 4.8.4, kernel 3.13.0.
>> Just glancing through the prerequisites list, it looks like I'm okay.
>>
>> Although, I didn't use the mach build system, I followed the SpiderMonkey
>> Build Documentation page and just ran configure in the js/src directory.
>> Could that be the issue? I suppose I could go through a full Firefox build
>> and see if anything changes.
>>
>>
>> On Wed, Dec 30, 2015 at 2:16 PM, Bobby Holley <[hidden email]>
>> wrote:
>>
>>> Presumably, the preprocessor expansion of MFBT_API is causing trouble.
>>> You
>>> can easily get to the bottom of it by spitting out the preprocessed
>>> source
>>> (i.e. seeing what MFBT_API expands to in your environment) and comparing
>>> the generated assembly with and without the decorators.
>>>
>>> This might be a good time to make sure you're compiling with a supported
>>> toolchain. See
>>>
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions#Build_prerequisites
>>>
>>> On Wed, Dec 30, 2015 at 12:07 PM, Cal Heldenbrand <[hidden email]>
>>> wrote:
>>>
>>> > Well this doesn't make any sense to me, but it has something to do with
>>> > the prototype of HashBytes in HashFunctions.h:
>>> >
>>> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
>>> > HashBytes(const void* bytes, size_t aLength);
>>> >
>>> > All I have to do to make it crash is this:
>>> >
>>> > ------------------------------------------
>>> > #include <js-confdefs.h>
>>> > #include <mozilla/HashFunctions.h>
>>> >
>>> > int main(int argc, char** argv, char** envp)
>>> > {
>>> >   int hash = mozilla::HashBytes("1234", 4);
>>> > }
>>> > ------------------------------------------
>>> > The backtrace just shows:
>>> > (gdb) bt
>>> > #0  0x0000000000000000 in ?? ()
>>> > #1  0x000000000040059b in main (argc=1, argv=0x7fffffffd6c8) at js6.c:6
>>> >
>>> > If I modify HashFunctions.h and add another function without the macro
>>> > prefixes, and call it, then it works.
>>> >
>>> > HashFunctions.h
>>> > -------------------------------------------
>>> >   ...
>>> > /**
>>> >  * Hash some number of bytes.
>>> >  *
>>> >  * This hash walks word-by-word, rather than byte-by-byte, so you won't
>>> > get the
>>> >  * same result out of HashBytes as you would out of HashString.
>>> >  */
>>> > MOZ_WARN_UNUSED_RESULT extern MFBT_API uint32_t
>>> > HashBytes(const void* bytes, size_t aLength);
>>> >
>>> > uint32_t testfun(void);
>>> > -------------------------------------------
>>> > (Note that if I include MOZ_WARN_UNUSED_RESULT extern MFBT_API on the
>>> > testfun() prototype, the program will still crash.)
>>> >
>>> > HashFunctions.cpp
>>> > -------------------------------------------
>>> > namespace mozilla {
>>> > uint32_t testfun(void)
>>> > {
>>> >   fprintf(stderr, "IN testfun()\n");
>>> >   return 0;
>>> > }
>>> > ...
>>> > -------------------------------------------
>>> >
>>> >
>>> > Here's the C program that does not segfault:
>>> >
>>> > ------------------------------------------
>>> > #include <js-confdefs.h>
>>> > #include <mozilla/HashFunctions.h>
>>> >
>>> > int main(int argc, char** argv, char** envp)
>>> > {
>>> >     mozilla::testfun();
>>> >     int hash = mozilla::HashBytes("1234", 4);
>>> >     fprintf(stderr, "hash test: %d\n", hash);
>>> >     return 0;
>>> > }
>>> > ------------------------------------------
>>> >
>>> > which outputs:
>>> > ------------------------------------------
>>> > IN testfun()
>>> > hash test: 953478926
>>> > ------------------------------------------
>>> >
>>> > If I do not call testfun() from main, the program also crashes.
>>> >
>>> > I'll submit a bug report on this, and document my compiler and kernel
>>> > versions and all that.  This at least gets me far enough to proceed
>>> with my
>>> > project.
>>> >
>>> > Thanks!
>>> >
>>> > --Cal
>>> >
>>> > <[hidden email]>
>>> >
>>> > On Tue, Dec 29, 2015 at 4:33 PM, Bobby Holley <[hidden email]>
>>> > wrote:
>>> >
>>> >> What is the stacktrace of the HashBytes crash? I don't see that in
>>> your
>>> >> original stack.
>>> >>
>>> >> Anyway, it sounds like you're pretty close to figuring it out. Please
>>> >> file a bug with the patch when you do. :-)
>>> >>
>>> >> On Tue, Dec 29, 2015 at 2:25 PM, Cal Heldenbrand <[hidden email]>
>>> wrote:
>>> >>
>>> >>> As a follow up, the more I play with this, the more I think there is
>>> >>> some kind of problem with the definition of the mozilla::HashBytes()
>>> >>> function itself.  If I add some debug prints to the function, they
>>> never
>>> >>> print.  (But I see them when running the js shell binary)
>>> >>>
>>> >>> If I just call something simple in my main() function, like this:
>>> >>>
>>> >>>     int hash = mozilla::HashBytes("1234", 4);
>>> >>>
>>> >>> It also segfaults.  The stack trace shows the same style of segfault,
>>> >>> the frame address is 0x0000000000000000.
>>> >>>
>>> >>> --Cal
>>> >>> <[hidden email]>
>>>
>>> >>>
>>> >>> On Tue, Dec 29, 2015 at 9:50 AM, Cal Heldenbrand <[hidden email]>
>>> >>> wrote:
>>> >>>
>>> >>>> Hi Bobby,
>>> >>>>
>>> >>>> I have some info to provide, but I'm no expert on the intricacies of
>>> >>>> this API.  Attached is a file of the console output from me
>>> screwing around
>>> >>>> in gdb.  I believe what it comes down to, is the hash Lookup object
>>> "l"
>>> >>>> contains only 1 byte of code, but the length has been assigned to 4.
>>> >>>> The mozilla::HashBytes() function is working with operations in
>>> words
>>> >>>> of 8 bytes.  It's stepping past the length of l.code and smashing
>>> the stack.
>>> >>>>
>>> >>>> But I don't quite understand where the 4 bytes is coming from.
>>> >>>>
>>> >>>> In frame 6, the *ssd object is set to:
>>> >>>>
>>> >>>>     ssd->data[0] = JSOP_RETRVAL;
>>> >>>>     ssd->data[1] = SRC_NULL;
>>> >>>>
>>> >>>> The SharedScriptData::new_ constructor has a really complicated
>>> method
>>> >>>> for calculating the length, and I suspect the hard coded
>>> >>>>
>>> >>>>      SharedScriptData* ssd = SharedScriptData::new_(cx, 1, 1, 0);
>>> >>>>
>>> >>>> in fullyInitTrivial() might be to blame there.  The script source
>>> >>>> itself is just "() {\n}" and is 6 bytes.  It's coming from
>>> >>>> CreateFunctionPrototype() in jsfun.cpp.
>>> >>>>
>>> >>>> Hope this sheds some light on the issue!  Let me know if you want
>>> any
>>> >>>> other variables printed.  Do you think I should submit a bugzilla
>>> issue for
>>> >>>> this?
>>> >>>>
>>> >>>> Thank you,
>>> >>>>
>>> >>>> --Cal
>>> >>>>
>>> >>>> On Mon, Dec 28, 2015 at 4:29 PM, Bobby Holley <
>>> [hidden email]>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Yes, SpiderMonkey inits a special global at startup which is used
>>> for
>>> >>>>> self-hosted code.
>>> >>>>>
>>> >>>>> The stacktrace still has too many omissions for me to make sense of
>>> >>>>> it. Can you load your program in a debugger, figure out what we're
>>> >>>>> segfaulting on (presumably something is null), and then walk up
>>> the stack
>>> >>>>> to figure out where that null value comes from?
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>> _______________________________________________
>>> dev-tech-js-engine mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>
>>
>>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine