Segmentation Fault Using JS_GET_CLASS

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

Segmentation Fault Using JS_GET_CLASS

dave-38
I am probably doing something patently wrong, but I was wondering if
someone could help me out. I've written my own, native toJSON() method
that I want to assign to all objects (i.e. to the global object
prototype.) I had it working with a custom build of SpiderMonkey, but
when I tried to use my system's native SpiderMonkey libraries, I get a
segfault.

Here's the rough order of execution of the code:

/** Initialization **/
    //bland object used for adding properties to all objects
    JSObject *bland_object  = JS_NewObject(cx, NULL, NULL, NULL);
    JSObject *bland_prototype = JS_GetPrototype(cx, bland_object);

    if (!JS_DefineFunction(cx, bland_prototype, "toJSON", ToJSON, 0,
0))
        return JS_FALSE;


/** ToJSON Code **/

static JSBool ToJSON(JSContext *cx, JSObject *obj, uintN argc, jsval
*argv, jsval *rval) {
    JSClass *cl = NULL;

    *rval = OBJECT_TO_JSVAL(obj);

    cl = JS_GET_CLASS(cx, obj); //SEGFAULT

//...

}

Here's the backtrace I get from gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd4e39b2750 (LWP 26244)]
0x00007fd4e2f28a5a in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) backtrace
#0  0x00007fd4e2f28a5a in pthread_mutex_lock () from /lib/
libpthread.so.0
#1  0x00007fd4dd1d62f9 in PR_Lock () from /usr/lib/libnspr4.so.0d
#2  0x00007fd4dcf40f90 in ?? () from /usr/lib/libmozjs.so.0d
#3  0x00007fd4dcf415cd in js_GetSlotThreadSafe () from /usr/lib/
libmozjs.so.0d
#4  0x00007fd4dcefdeab in JS_GetClass () from /usr/lib/libmozjs.so.0d
#5  0x00007fd4dd3f565d in ToJSON (cx=0x7fd4e4b13520,
obj=0x7fd4e4b19180, argc=0, argv=0x7fd4e4b50500, rval=0x7fffeba3c650)
at libboojs.c:731
#6  0x00007fd4dcf2e3de in js_Invoke () from /usr/lib/libmozjs.so.0d
#7  0x00007fd4dcf30506 in ?? () from /usr/lib/libmozjs.so.0d
#8  0x00007fd4dcf3ed9f in ?? () from /usr/lib/libmozjs.so.0d
#9  0x00007fd4dcefcd6e in JS_ExecuteScript () from /usr/lib/
libmozjs.so.0d


_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Alex Rickabaugh
On Jan 17, 4:59 pm, dave <[hidden email]> wrote:

> I am probably doing something patently wrong, but I was wondering if
> someone could help me out. I've written my own, native toJSON() method
> that I want to assign to all objects (i.e. to the global object
> prototype.) I had it working with a custom build of SpiderMonkey, but
> when I tried to use my system's native SpiderMonkey libraries, I get a
> segfault.
>
> Here's the rough order of execution of the code:
>
> /** Initialization **/
>     //bland object used for adding properties to all objects
>     JSObject *bland_object  = JS_NewObject(cx, NULL, NULL, NULL);
>     JSObject *bland_prototype = JS_GetPrototype(cx, bland_object);
>
>     if (!JS_DefineFunction(cx, bland_prototype, "toJSON", ToJSON, 0,
> 0))
>         return JS_FALSE;
>
> /** ToJSON Code **/
>
> static JSBool ToJSON(JSContext *cx, JSObject *obj, uintN argc, jsval
> *argv, jsval *rval) {
>     JSClass *cl = NULL;
>
>     *rval = OBJECT_TO_JSVAL(obj);
>
>     cl = JS_GET_CLASS(cx, obj); //SEGFAULT
>
> //...
>
> }
>
> Here's the backtrace I get from gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fd4e39b2750 (LWP 26244)]
> 0x00007fd4e2f28a5a in pthread_mutex_lock () from /lib/libpthread.so.0
> (gdb) backtrace
> #0  0x00007fd4e2f28a5a in pthread_mutex_lock () from /lib/
> libpthread.so.0
> #1  0x00007fd4dd1d62f9 in PR_Lock () from /usr/lib/libnspr4.so.0d
> #2  0x00007fd4dcf40f90 in ?? () from /usr/lib/libmozjs.so.0d
> #3  0x00007fd4dcf415cd in js_GetSlotThreadSafe () from /usr/lib/
> libmozjs.so.0d
> #4  0x00007fd4dcefdeab in JS_GetClass () from /usr/lib/libmozjs.so.0d
> #5  0x00007fd4dd3f565d in ToJSON (cx=0x7fd4e4b13520,
> obj=0x7fd4e4b19180, argc=0, argv=0x7fd4e4b50500, rval=0x7fffeba3c650)
> at libboojs.c:731
> #6  0x00007fd4dcf2e3de in js_Invoke () from /usr/lib/libmozjs.so.0d
> #7  0x00007fd4dcf30506 in ?? () from /usr/lib/libmozjs.so.0d
> #8  0x00007fd4dcf3ed9f in ?? () from /usr/lib/libmozjs.so.0d
> #9  0x00007fd4dcefcd6e in JS_ExecuteScript () from /usr/lib/
> libmozjs.so.0d

Did you rebuild your project against the system-wide libraries? Keep
in mind the structure definitions may be different, which means the
ABIs of the two versions of the libraries will be different. You'd
need to recompile your program against the system-wide libraries to be
able to run it against them, otherwise you'll get weird crashes.
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

dave-38
On Jan 17, 10:38 pm, alx <[hidden email]> wrote:
> Did you rebuild your project against the system-wide libraries? Keep
> in mind the structure definitions may be different, which means the
> ABIs of the two versions of the libraries will be different. You'd
> need to recompile your program against the system-wide libraries to be
> able to run it against them, otherwise you'll get weird crashes.

Yeah, that's where the problem started. My libraries where built as
libjs. My system has them as libmozjs. I updated my makefile, deleted
the libraries that I had compiled myself, and I'm left with the
segfault. It's worth noting that both the version I compiled and my
system version have the same version numbers (1.7.0 2008-10-03)

_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Jason Orendorff-2
On 1/18/09 9:28 AM, dave wrote:

> On Jan 17, 10:38 pm, alx<[hidden email]>  wrote:
>> Did you rebuild your project against the system-wide libraries? Keep
>> in mind the structure definitions may be different, which means the
>> ABIs of the two versions of the libraries will be different. You'd
>> need to recompile your program against the system-wide libraries to be
>> able to run it against them, otherwise you'll get weird crashes.
>
> Yeah, that's where the problem started. My libraries where built as
> libjs. My system has them as libmozjs. I updated my makefile, deleted
> the libraries that I had compiled myself, and I'm left with the
> segfault. It's worth noting that both the version I compiled and my
> system version have the same version numbers (1.7.0 2008-10-03)

You may be compiling your code with different DEFINES than your
distribution used when building libmozjs.

If the library is built with JS_THREADSAFE and the application is built
without, or vice versa, then the ABI of this particular function will
not match.

This is admittedly kind of shabby. If you know of a cross-platform way
we can detect this kind of mismatch at load time, please file a bug and
attach the patch!

-j
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Jim Blandy-3
Jason Orendorff wrote:
> This is admittedly kind of shabby. If you know of a cross-platform way
> we can detect this kind of mismatch at load time, please file a bug and
> attach the patch!

Perhaps JS_NewRuntime could become a macro that calls some new function
js_NewRuntimeWithAPIChecks, passing it the values of all the relevant
macros.  js_NewRuntimeWithAPIChecks would check the values received from
the client against the values the library was built with.
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

dave-38
In reply to this post by Jason Orendorff-2
On Jan 18, 1:14 pm, Jason Orendorff <[hidden email]> wrote:

> You may be compiling your code with different DEFINES than your
> distribution used when building libmozjs.
>
> If the library is built with JS_THREADSAFE and the application is built
> without, or vice versa, then the ABI of this particular function will
> not match.
>
> This is admittedly kind of shabby. If you know of a cross-platform way
> we can detect this kind of mismatch at load time, please file a bug and
> attach the patch!
>
> -j

Just wanted to say thanks. This was exactly the problem. I put the
following into my autoconf file and it seems to be working:

AC_CHECK_LIB(mozjs, JS_BeginRequest,
[
  CFLAGS="${CFLAGS} -DJS_THREADSAFE"
])
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Jason Orendorff-2
On 1/20/09 11:00 PM, dave wrote:
> Just wanted to say thanks. This was exactly the problem. I put the
> following into my autoconf file and it seems to be working:
>
> AC_CHECK_LIB(mozjs, JS_BeginRequest,
> [
>    CFLAGS="${CFLAGS} -DJS_THREADSAFE"
> ])

Awww, that's an elegant workaround, but if you ever upgrade to
SpiderMonkey >= 1.8, it will break, due to this fix:

Provide stubs for JS_THREADSAFE APIs in non-JS_THREADSAFE builds
https://bugzilla.mozilla.org/show_bug.cgi?id=412985

-j
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Mike Shaver
On Thu, Jan 22, 2009 at 3:14 PM, Jason Orendorff <[hidden email]> wrote:

> On 1/20/09 11:00 PM, dave wrote:
>>
>> Just wanted to say thanks. This was exactly the problem. I put the
>> following into my autoconf file and it seems to be working:
>>
>> AC_CHECK_LIB(mozjs, JS_BeginRequest,
>> [
>>   CFLAGS="${CFLAGS} -DJS_THREADSAFE"
>> ])
>
> Awww, that's an elegant workaround, but if you ever upgrade to SpiderMonkey
>>= 1.8, it will break, due to this fix:
>
> Provide stubs for JS_THREADSAFE APIs in non-JS_THREADSAFE builds
> https://bugzilla.mozilla.org/show_bug.cgi?id=412985

True, but in that case he'll be able to just update to using the
THREADSAFE APIs everywhere, and not care which version he gets
underneath, right?

Some people might care, though, so perhaps we should define a
JS_BuiltWithThreadSafe integer symbol for them to inspect at runtime?

Mike
_______________________________________________
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: Segmentation Fault Using JS_GET_CLASS

Jim Blandy-3
In reply to this post by Jason Orendorff-2
Jason Orendorff wrote:
> This is admittedly kind of shabby. If you know of a cross-platform way
> we can detect this kind of mismatch at load time, please file a bug and
> attach the patch!

I've filed Bug 474873 -  SpiderMonkey init should detect mismatched
client/library configurations
https://bugzilla.mozilla.org/show_bug.cgi?id=474873
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine