Re: Core dump with debugging turned on?

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

Re: Core dump with debugging turned on?

Kent Williams


OK so 9 months ago I ran into this.  --enable-debug causes my
Spidermonkey-embedded programs to crash.

It has something to do with DEBUG being defined (or not defined, can't
remember which).

Did anyone figure out how to fix this?

Is this fixed in some version of the Spidermonkey source?

I'm building with the JS tree from the firefox 38.0esr source.


On 02/20/2015 04:28 PM, Jason Orendorff wrote:

> On Fri, Feb 20, 2015 at 4:23 PM, Kent Williams<[hidden email]>
> wrote:
>
>>   The main thing though is that I'd like debug symbols, i.e. compile with
>> -g. Will I get that if I just use
>>
>> --enable-debug-symbols
>>
>> WITHOUT --enable-debug?
>>
>   Yes. Regardless of whether you use --enable-debug or not, you probably
> also want --disable-optimize in order to get a decent debugging experience.
>
> (This is an oversimplification, but in short --enable-debug-symbols means
> send -g to the C++ compiler, and --disable-optimize means send -O0.)
>
> -j
> _______________________________________________
> 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: Core dump with debugging turned on?

Terrence Cole-3
Can you get a stacktrace where the crash is occurring?

On Tue, Nov 17, 2015 at 12:24 PM, Kent Williams <[hidden email]>
wrote:

>
>
> OK so 9 months ago I ran into this.  --enable-debug causes my
> Spidermonkey-embedded programs to crash.
>
> It has something to do with DEBUG being defined (or not defined, can't
> remember which).
>
> Did anyone figure out how to fix this?
>
> Is this fixed in some version of the Spidermonkey source?
>
> I'm building with the JS tree from the firefox 38.0esr source.
>
>
> On 02/20/2015 04:28 PM, Jason Orendorff wrote:
>
>> On Fri, Feb 20, 2015 at 4:23 PM, Kent Williams<[hidden email]>
>> wrote:
>>
>>   The main thing though is that I'd like debug symbols, i.e. compile with
>>> -g. Will I get that if I just use
>>>
>>> --enable-debug-symbols
>>>
>>> WITHOUT --enable-debug?
>>>
>>>   Yes. Regardless of whether you use --enable-debug or not, you probably
>> also want --disable-optimize in order to get a decent debugging
>> experience.
>>
>> (This is an oversimplification, but in short --enable-debug-symbols means
>> send -g to the C++ compiler, and --disable-optimize means send -O0.)
>>
>> -j
>> _______________________________________________
>> 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: Core dump with debugging turned on?

Kent Williams
It's here:
     ~Rooted() {
         MOZ_ASSERT(*stack == reinterpret_cast<Rooted<void*>*>(this));
--->    *stack = prev;
     }

And the crash is because stack == 0.


#0  0x00000000004282f9 in JS::Rooted<JSScript*>::~Rooted
(this=0x7fffffffcd50, __in_chrg=<optimized out>) at
/onderon-home/kwilliams/develop/pagewiz/build/js-build/dist/include/js/RootingAPI.h:782
#1  0x0000000000428209 in JS::CompileOptions::~CompileOptions
(this=0x7fffffffccc0, __in_chrg=<optimized out>) at
/onderon-home/kwilliams/develop/pagewiz/build/js-build/dist/include/jsapi.h:3460
#2  0x00000000004e23bf in CreateFunctionPrototype (cx=0x1ed9450,
key=JSProto_Function) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsfun.cpp:838
#3  0x000000000084c5ad in js::GlobalObject::resolveConstructor
(cx=0x1ed9450, global=..., key=JSProto_Function) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:153
#4  0x000000000084c33c in js::GlobalObject::ensureConstructor
(cx=0x1ed9450, global=..., key=JSProto_Function) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:95
#5  0x00000000006ff469 in CreateObjectConstructor (cx=0x1ed9450,
key=JSProto_Object) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/builtin/Object.cpp:1117
#6  0x000000000084c668 in js::GlobalObject::resolveConstructor
(cx=0x1ed9450, global=..., key=JSProto_Object) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:161
#7  0x000000000084c33c in js::GlobalObject::ensureConstructor
(cx=0x1ed9450, global=..., key=JSProto_Object) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:95
#8  0x000000000047b18a in js::GlobalObject::getOrCreateObjectPrototype
(this=0x7ffff5822060, cx=0x1ed9450) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.h:326
#9  0x000000000068bee1 in CreateArrayPrototype (cx=0x1ed9450,
key=JSProto_Array) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsarray.cpp:3248
#10 0x000000000084d6c9 in InitBareBuiltinCtor (cx=0x1ed9450, global=...,
protoKey=JSProto_Array) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:349
#11 0x000000000084d9c0 in js::GlobalObject::initSelfHostingBuiltins
(cx=0x1ed9450, global=..., builtins=0x1e60a20 <intrinsic_functions>) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:386
#12 0x0000000000910e7b in JSRuntime::createSelfHostingGlobal
(cx=0x1ed9450) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/SelfHosting.cpp:1041
#13 0x0000000000910fef in JSRuntime::initSelfHosting (this=0x1eb5410,
cx=0x1ed9450) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/SelfHosting.cpp:1065
#14 0x0000000000452a75 in js::NewContext (rt=0x1eb5410,
stackChunkSize=8192) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:126
#15 0x000000000043ee4a in JS_NewContext (rt=0x1eb5410,
stackChunkSize=8192) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:569
#16 0x0000000000427b43 in main (argc=1, argv=0x7fffffffdf58) at
/onderon-home/kwilliams/develop/pagewiz/pagewiz/jsmemtest.cpp:17


On 11/17/2015 02:39 PM, Terrence Cole wrote:

> Can you get a stacktrace where the crash is occurring?
>
> On Tue, Nov 17, 2015 at 12:24 PM, Kent Williams <[hidden email]>
> wrote:
>
>>
>> OK so 9 months ago I ran into this.  --enable-debug causes my
>> Spidermonkey-embedded programs to crash.
>>
>> It has something to do with DEBUG being defined (or not defined, can't
>> remember which).
>>
>> Did anyone figure out how to fix this?
>>
>> Is this fixed in some version of the Spidermonkey source?
>>
>> I'm building with the JS tree from the firefox 38.0esr source.
>>
>>
>> On 02/20/2015 04:28 PM, Jason Orendorff wrote:
>>
>>> On Fri, Feb 20, 2015 at 4:23 PM, Kent Williams<[hidden email]>
>>> wrote:
>>>
>>>    The main thing though is that I'd like debug symbols, i.e. compile with
>>>> -g. Will I get that if I just use
>>>>
>>>> --enable-debug-symbols
>>>>
>>>> WITHOUT --enable-debug?
>>>>
>>>>    Yes. Regardless of whether you use --enable-debug or not, you probably
>>> also want --disable-optimize in order to get a decent debugging
>>> experience.
>>>
>>> (This is an oversimplification, but in short --enable-debug-symbols means
>>> send -g to the C++ compiler, and --disable-optimize means send -O0.)
>>>
>>> -j
>>> _______________________________________________
>>> 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

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Boris Zbarsky
In reply to this post by Kent Williams
On 11/17/15 3:24 PM, Kent Williams wrote:
> OK so 9 months ago I ran into this.  --enable-debug causes my
> Spidermonkey-embedded programs to crash.

Are those programs compiled with DEBUG defined?  You just need to make
sure that DEBUG is defined when including SpiderMonkey headers if and
only if the SpiderMonkey object files are built with DEBUG defined.

-Boris
_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
OK so if I define DEBUG before I include the headers it just crashes
somewhere else:

0x0000000000455f24 in JS::AutoCheckRequestDepth::AutoCheckRequestDepth
(this=0x7fffffffdbb0, cx=0x1ed9450) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
1140        MOZ_ASSERT(cx->runtime()->requestDepth ||
cx->runtime()->isHeapBusy());
where
#0  0x0000000000455f24 in
JS::AutoCheckRequestDepth::AutoCheckRequestDepth (this=0x7fffffffdbb0,
cx=0x1ed9450) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
#1  0x00000000004429e3 in JS_NewGlobalObject (cx=0x1ed9450,
clasp=0x1ea25e0 <global_class>, principals=0x0,
hookOption=JS::DontFireOnNewGlobalHook, options=...) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:1807
#2  0x0000000000427b38 in main (argc=1, argv=0x7fffffffdf58) at
/onderon-home/kwilliams/develop/pagewiz/pagewiz/jsmemtest.cpp:24


On 11/17/2015 03:20 PM, Boris Zbarsky wrote:

> On 11/17/15 3:24 PM, Kent Williams wrote:
>> OK so 9 months ago I ran into this. --enable-debug causes my
>> Spidermonkey-embedded programs to crash.
>
> Are those programs compiled with DEBUG defined?  You just need to make
> sure that DEBUG is defined when including SpiderMonkey headers if and
> only if the SpiderMonkey object files are built with DEBUG defined.
>
> -Boris
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
Here's the program I used:

#include <iostream>
#define DEBUG
#include <js/CharacterEncoding.h>
#include <jswrapper.h>
#include <js/Conversions.h>
#include <jsapi.h>

JSClass global_class = {
     "global", JSCLASS_GLOBAL_FLAGS,
     JS_PropertyStub,
};

int main(int argc, char **argv) {
     JS_Init();
     JSRuntime *runtime = JS_NewRuntime((unsigned int)(128L * 1024L *
1024L));
     if(!runtime) {
         exit(1);
     }

     JSContext *context = JS_NewContext(runtime, 8192);
     if(!context) {
         exit(1);
     }
     JS::PersistentRooted<JSObject *> global;
     // JS::RootedObject global(context);
     global = JS_NewGlobalObject(context,
                                          &global_class,
                                          nullptr,
  JS::DontFireOnNewGlobalHook);
     if(!global) {
         exit(1);
     }
     JSCompartment *compartment = JS_EnterCompartment( context, global );
     JS_InitStandardClasses(context, global );
     JS_ClearPendingException(context);
     JS::CompileOptions jsCompileOptions(context);
     jsCompileOptions.setUTF8(true);
     JS::Rooted< JSScript * > code(context);

     const char *script = "'hello' + 'world, it is '+new Date()";
     if(JS_CompileScript(context, global, script, strlen(script),
                               jsCompileOptions, &code)) {
         JS::RootedValue result(context);
         if(JS_ExecuteScript(context, global, code, &result) &&
!result.isUndefined()) {
             JS::RootedString resultS(context, result.toString());
             std::cerr << "result: " << JS_EncodeStringToUTF8(context,
resultS) << std::endl;
         } else
             std::cerr << "execute script failed" << std::endl;
     } else {
         std::cerr << "can't compile script:" << std::endl
                      << script << std::endl;
         exit(1);
     }
     JS_LeaveCompartment(context,compartment);
     global = 0;
     JS_DestroyContext(context);
     exit(0);
}

On 11/17/2015 03:55 PM, Kent Williams wrote:

> OK so if I define DEBUG before I include the headers it just crashes
> somewhere else:
>
> 0x0000000000455f24 in JS::AutoCheckRequestDepth::AutoCheckRequestDepth
> (this=0x7fffffffdbb0, cx=0x1ed9450) at
> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
> 1140        MOZ_ASSERT(cx->runtime()->requestDepth ||
> cx->runtime()->isHeapBusy());
> where
> #0  0x0000000000455f24 in
> JS::AutoCheckRequestDepth::AutoCheckRequestDepth (this=0x7fffffffdbb0,
> cx=0x1ed9450) at
> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
> #1  0x00000000004429e3 in JS_NewGlobalObject (cx=0x1ed9450,
> clasp=0x1ea25e0 <global_class>, principals=0x0,
> hookOption=JS::DontFireOnNewGlobalHook, options=...) at
> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:1807
> #2  0x0000000000427b38 in main (argc=1, argv=0x7fffffffdf58) at
> /onderon-home/kwilliams/develop/pagewiz/pagewiz/jsmemtest.cpp:24
>
>
> On 11/17/2015 03:20 PM, Boris Zbarsky wrote:
>> On 11/17/15 3:24 PM, Kent Williams wrote:
>>> OK so 9 months ago I ran into this. --enable-debug causes my
>>> Spidermonkey-embedded programs to crash.
>>
>> Are those programs compiled with DEBUG defined?  You just need to
>> make sure that DEBUG is defined when including SpiderMonkey headers
>> if and only if the SpiderMonkey object files are built with DEBUG
>> defined.
>>
>> -Boris
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 11/17/15 4:55 PM, Kent Williams wrote:
> OK so if I define DEBUG before I include the headers it just crashes
> somewhere else:

That's not a crash; that's an assertion failure.

> #0  0x0000000000455f24 in
> JS::AutoCheckRequestDepth::AutoCheckRequestDepth (this=0x7fffffffdbb0,
> cx=0x1ed9450) at
> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
> #1  0x00000000004429e3 in JS_NewGlobalObject (cx=0x1ed9450,
> clasp=0x1ea25e0 <global_class>, principals=0x0,
> hookOption=JS::DontFireOnNewGlobalHook, options=...) at
> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:1807

OK, so doing JS_NewGlobalObject while not inside a request.  You should
be in a request.

-Boris
_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
So adding JS_BeginRequest(context); before the JS_NewGlobalObject just
means a crash in a different assert failure.

Here:
GlobalObject*
GlobalObject::createInternal(JSContext* cx, const Class* clasp)
{
     MOZ_ASSERT(clasp->flags & JSCLASS_IS_GLOBAL);
--> MOZ_ASSERT(clasp->trace == JS_GlobalObjectTraceHook);

At that point clasp->trace == 0

I'm beginning to wonder if people outside Mozilla are even meant to turn
on debugging in Spidermonkey

And why are there all these failing assertion checks, when the
interpreter works fine if you don't turn on debugging?  If these are
real problems, why don't they show themselves when you're using the
interpreter?

#0  0x000000000084d276 in js::GlobalObject::createInternal
(cx=0x1ed9450, clasp=0x1ea25e0 <global_class>) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:235
#1  0x000000000084d647 in js::GlobalObject::new_ (cx=0x1ed9450,
clasp=0x1ea25e0 <global_class>, principals=0x0,
hookOption=JS::DontFireOnNewGlobalHook, options=...) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/vm/GlobalObject.cpp:291
#2  0x00000000004429b0 in JS_NewGlobalObject (cx=0x1ed9450,
clasp=0x1ea25e0 <global_class>, principals=0x0,
hookOption=JS::DontFireOnNewGlobalHook, options=...) at
/onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:1809
#3  0x0000000000427b0e in main (argc=1, argv=0x7fffffffdf58) at
/onderon-home/kwilliams/develop/pagewiz/pagewiz/jsmemtest.cpp:30

On 11/17/2015 04:18 PM, Boris Zbarsky wrote:

> On 11/17/15 4:55 PM, Kent Williams wrote:
>> OK so if I define DEBUG before I include the headers it just crashes
>> somewhere else:
>
> That's not a crash; that's an assertion failure.
>
>> #0  0x0000000000455f24 in
>> JS::AutoCheckRequestDepth::AutoCheckRequestDepth (this=0x7fffffffdbb0,
>> cx=0x1ed9450) at
>> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jscntxt.cpp:1140
>> #1  0x00000000004429e3 in JS_NewGlobalObject (cx=0x1ed9450,
>> clasp=0x1ea25e0 <global_class>, principals=0x0,
>> hookOption=JS::DontFireOnNewGlobalHook, options=...) at
>> /onderon-home/kwilliams/develop/pagewiz/build/js/js/src/jsapi.cpp:1807
>
> OK, so doing JS_NewGlobalObject while not inside a request.  You
> should be in a request.
>
> -Boris
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 11/17/15 5:50 PM, Kent Williams wrote:
> So adding JS_BeginRequest(context); before the JS_NewGlobalObject just
> means a crash in a different assert failure.

Then you should fix it.

> GlobalObject::createInternal(JSContext* cx, const Class* clasp)
> {
>      MOZ_ASSERT(clasp->flags & JSCLASS_IS_GLOBAL);
> --> MOZ_ASSERT(clasp->trace == JS_GlobalObjectTraceHook);

Right, so you need to have that trace hook on your global's JSClass.  If
you don't, things won't work right.

> At that point clasp->trace == 0

Which means your global is not tracing things correctly and you should
expect all sorts of bad behavior when things that are still referenced
are collected out from under the engine.

> I'm beginning to wonder if people outside Mozilla are even meant to turn
> on debugging in Spidermonkey

Yes!  The point of the asserts is to assert invariants the engine relies
on.  If you're failing the asserts, you should expect various things to
go wrong at runtime in an opt build.

> And why are there all these failing assertion checks, when the
> interpreter works fine if you don't turn on debugging?

I very much doubt it actually works fine in practice, though it might
accidentally work ok for a particular workload (e.g. a workload that
never does a GC won't have issues with the global's trace hook being wrong).

> If these are
> real problems, why don't they show themselves when you're using the
> interpreter?

Are you very sure they don't?

-Boris
_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
There's this, but I suspect it will need modifications to work with JS38
http://trac.wildfiregames.com/attachment/wiki/JSRootingGuide/main.cpp

On 11/17/2015 6:00 PM, Boris Zbarsky wrote:

> On 11/17/15 5:50 PM, Kent Williams wrote:
>> So adding JS_BeginRequest(context); before the JS_NewGlobalObject just
>> means a crash in a different assert failure.
>
> Then you should fix it.
>
>> GlobalObject::createInternal(JSContext* cx, const Class* clasp)
>> {
>>      MOZ_ASSERT(clasp->flags & JSCLASS_IS_GLOBAL);
>> --> MOZ_ASSERT(clasp->trace == JS_GlobalObjectTraceHook);
>
> Right, so you need to have that trace hook on your global's JSClass.  
> If you don't, things won't work right.
>
>> At that point clasp->trace == 0
>
> Which means your global is not tracing things correctly and you should
> expect all sorts of bad behavior when things that are still referenced
> are collected out from under the engine.
>
>> I'm beginning to wonder if people outside Mozilla are even meant to turn
>> on debugging in Spidermonkey
>
> Yes!  The point of the asserts is to assert invariants the engine
> relies on.  If you're failing the asserts, you should expect various
> things to go wrong at runtime in an opt build.
>
>> And why are there all these failing assertion checks, when the
>> interpreter works fine if you don't turn on debugging?
>
> I very much doubt it actually works fine in practice, though it might
> accidentally work ok for a particular workload (e.g. a workload that
> never does a GC won't have issues with the global's trace hook being
> wrong).
>
>> If these are
>> real problems, why don't they show themselves when you're using the
>> interpreter?
>
> Are you very sure they don't?
>
> -Boris
> _______________________________________________
> 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: Core dump with debugging turned on?

Kent Williams
In reply to this post by Boris Zbarsky
I started over with the code here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine

First -- the whole JS_BeginRequest thing -- what exactly is it meant to
bracket? Does every call to the JS API need to be bracketed by
JS_BeginRequest/JS_EndRequest?  This seems to be the case for everything
done in the example code.

Second Apparently all JS::Rooted need to go out of scope before calling
JS_DestroyContext.  Sounds reasonable, NOT HOW EXAMPLE CODE WORKS.  The
example above was enshrined on the website without anyone ever trying to
use it with --enable-debug.

My changes have the comment KW ADD

// This is an example for SpiderMonkey 31.
// For SpiderMonkey 24 or 38, see each comment.

// following code might be needed in some case
// #define __STDC_LIMIT_MACROS
// #include <stdint.h>
#define DEBUG
#include "jsapi.h"

/* The class of the global object. */
// static JSClass global_class = {
//     "global",
//     JSCLASS_GLOBAL_FLAGS,
//     // [SpiderMonkey 38] Following Stubs are removed. Remove those lines.
//     // JS_PropertyStub,
//     // JS_DeletePropertyStub,
//     // JS_PropertyStub,
//     // JS_StrictPropertyStub,
//     // JS_EnumerateStub,
//     // JS_ResolveStub,
//     // JS_ConvertStub
// };
// KW ADD -- need JS_GlobalObjectTraceHook
JSClass global_class = {
     "global", JSCLASS_GLOBAL_FLAGS,
     0,                                      // JSPropertyOp addProperty;
     0,                                      // JSDeletePropertyOp
delProperty;
     0,                                      // JSPropertyOp getProperty;
     0,                                      // JSStrictPropertyOp
setProperty;
     0,                                      // JSEnumerateOp enumerate;
     0,                                      // JSResolveOp resolve;
     0,                                      // JSConvertOp convert;
     0,                                      // FinalizeOpType finalize;
     0,                                      // JSNative call;
     0,                                      // JSHasInstanceOp hasInstance;
     0,                                      // JSNative construct;
     JS_GlobalObjectTraceHook,      // JSTraceOp           trace
};

int main(int argc, const char *argv[])
{
     // [SpiderMonkey 24] JS_Init does not exist. Remove this line.
     JS_Init();

     // [SpiderMonkey 38] useHelperThreads parameter is removed.
     JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024);
     // JSRuntime *rt = JS_NewRuntime(8L * 1024 * 1024,
JS_USE_HELPER_THREADS);
     if (!rt)
         return 1;

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

      // KW ADD -- everything that happens needs to be inside a request.
      JS_BeginRequest(cx);

     // [SpiderMonkey 24] hookOption parameter does not exist.
     // JS::RootedObject global(cx, JS_NewGlobalObject(cx,
&global_class, nullptr));
      // KW ADD -- move global down into brace so it will go out of
     // scope before DestroyContext

      // KW ADD -- move rval inside scope, so
      // it will be destroyed before cleanup at end
     {
          JS::RootedValue rval(cx);
          JS::RootedObject global(cx, JS_NewGlobalObject(cx,
&global_class, nullptr, JS::FireOnNewGlobalHook));
          if (!global)
              return 1;

       JSAutoCompartment ac(cx, global);
       JS_InitStandardClasses(cx, global);

       const char *script = "'hello'+'world, it is '+new Date()";
       const char *filename = "noname";
       int lineno = 1;
       // [SpiderMonkey 24] The type of rval parameter is 'jsval *'.
       // bool ok = JS_EvaluateScript(cx, global, script,
strlen(script), filename, lineno, rval.address());
       // [SpiderMonkey 38] JS_EvaluateScript is replaced with JS::Evaluate.
       JS::CompileOptions opts(cx);
       opts.setFileAndLine(filename, lineno);
       bool ok = JS::Evaluate(cx, global, opts, script, strlen(script),
&rval);
       // bool ok = JS_EvaluateScript(cx, global, script,
strlen(script), filename, lineno, &rval);
       if (!ok)
         return 1;

     JSString *str = rval.toString();
     printf("%s\n", JS_EncodeString(cx, str));
     }
      // KW ADD
      JS_EndRequest(cx);
     JS_DestroyContext(cx);
     JS_DestroyRuntime(rt);
     JS_ShutDown();
     return 0;
}





On 11/17/2015 06:00 PM, Boris Zbarsky wrote:

> On 11/17/15 5:50 PM, Kent Williams wrote:
>> So adding JS_BeginRequest(context); before the JS_NewGlobalObject just
>> means a crash in a different assert failure.
>
> Then you should fix it.
>
>> GlobalObject::createInternal(JSContext* cx, const Class* clasp)
>> {
>>      MOZ_ASSERT(clasp->flags & JSCLASS_IS_GLOBAL);
>> --> MOZ_ASSERT(clasp->trace == JS_GlobalObjectTraceHook);
>
> Right, so you need to have that trace hook on your global's JSClass.  
> If you don't, things won't work right.
>
>> At that point clasp->trace == 0
>
> Which means your global is not tracing things correctly and you should
> expect all sorts of bad behavior when things that are still referenced
> are collected out from under the engine.
>
>> I'm beginning to wonder if people outside Mozilla are even meant to turn
>> on debugging in Spidermonkey
>
> Yes!  The point of the asserts is to assert invariants the engine
> relies on.  If you're failing the asserts, you should expect various
> things to go wrong at runtime in an opt build.
>
>> And why are there all these failing assertion checks, when the
>> interpreter works fine if you don't turn on debugging?
>
> I very much doubt it actually works fine in practice, though it might
> accidentally work ok for a particular workload (e.g. a workload that
> never does a GC won't have issues with the global's trace hook being
> wrong).
>
>> If these are
>> real problems, why don't they show themselves when you're using the
>> interpreter?
>
> Are you very sure they don't?
>
> -Boris
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
//Oh and another thing:  You can't create a global object with
JS::DontFireOnNewGlobalHook if you want to run with --enable-debug.

And I can't find any documentation on JS::CompartmentOptions. If you
click on the type name on this page:

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

You get a 404 error.
_______________________________________________
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: Core dump with debugging turned on?

Till Schneidereit-2
In reply to this post by Kent Williams
On Wed, Nov 18, 2015 at 4:23 PM, Kent Williams <[hidden email]>
wrote:

> Second Apparently all JS::Rooted need to go out of scope before calling
> JS_DestroyContext.  Sounds reasonable, NOT HOW EXAMPLE CODE WORKS.  The
> example above was enshrined on the website without anyone ever trying to
> use it with --enable-debug.
>

Note that said website is a wiki, so remodeling the shrine is easy.

Feel free to ask questions in the #jsapi channel on irc.mozilla.org, too.
In many cases, a polite question there is a quick way to get answers.
_______________________________________________
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: Core dump with debugging turned on?

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 11/18/15 10:23 AM, Kent Williams wrote:

 > I started over with the code here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine 


Yeah, that looks fairly out of date (and is explicitly marked as needing
technical review).  The state of the docs is very sad.  :(

It doesn't help that this is trying to be documentation for multiple
spidermonkey versions at once and those versions might have quite
different behavior.  For example, the docs have a JS_ConvertStub in the
JSClass, but on tip there is no convert thing at all.  There are various
other things in JSClass instead.  I've tried to add the
JS_GlobalObjectTracehook bit while preserving the multi-versionness, but
I have low confidence in it being right for all the versions.

> First -- the whole JS_BeginRequest thing -- what exactly is it meant to
> bracket? Does every call to the JS API need to be bracketed by
> JS_BeginRequest/JS_EndRequest?  This seems to be the case for everything
> done in the example code.

I believe the idea is that every call that might end up doing a gc needs
to be inside a request.  So yes, pretty much every jsapi call.

JSAutoRequest exists and is a good thing.  Looks like it's been around
since forever, too.  Added that to the docs in question.

> Second Apparently all JS::Rooted need to go out of scope before calling
> JS_DestroyContext.  Sounds reasonable, NOT HOW EXAMPLE CODE WORKS.

Clearly a bug.  I've fixed that.  Note that it's a wiki, by the way, so
anyone can fix it....

> The example above was enshrined on the website without anyone ever trying to
> use it with --enable-debug.

It's not clear to me that anyone tried this code in any way at all.

-Boris


_______________________________________________
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: Core dump with debugging turned on?

Boris Zbarsky
In reply to this post by Kent Williams
On 11/18/15 10:47 AM, Kent Williams wrote:
> //Oh and another thing:  You can't create a global object with
> JS::DontFireOnNewGlobalHook if you want to run with --enable-debug.

Hmm.  Why not?  As long as you fire it yourself later, of course...
Certainly debug builds of Firefox do this, and it works fine.

> And I can't find any documentation on JS::CompartmentOptions.

There might not be any yet, indeed.

-Boris
_______________________________________________
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: Core dump with debugging turned on?

Kent Williams
The reason you can't use JS::DontFireOnNewGlobalHook because there's an
assertion that fails if you do ;-)


On 11/18/2015 10:00 AM, Boris Zbarsky wrote:

> On 11/18/15 10:47 AM, Kent Williams wrote:
>> //Oh and another thing:  You can't create a global object with
>> JS::DontFireOnNewGlobalHook if you want to run with --enable-debug.
>
> Hmm.  Why not?  As long as you fire it yourself later, of course...
> Certainly debug builds of Firefox do this, and it works fine.
>
>> And I can't find any documentation on JS::CompartmentOptions.
>
> There might not be any yet, indeed.
>
> -Boris
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

--

*Kent Williams*| C++ Developer
*CourseLeaf from Leepfrog Technologies *

/“The Process of Academic Change”
/319-337-3877 | courseleaf.com <http://www.courseleaf.com/>

/This message contains confidential information and is intended only for
the individual named. If you are not the intended recipient of this
transmission or a person responsible for delivering it to the intended
recipient, any disclosure, copying, distribution, or other use of any of
the information in this transmission is strictly prohibited. Please
notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system./

_______________________________________________
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: Core dump with debugging turned on?

Bobby Holley-2
The assertion is telling you that you need to fire the hook before loading
any script into that compartment.

Taking a step back: All the people who develop SpiderMonkey and Gecko use
debug builds. We encode heavy assertions into the codebase to catch
dangerous misbehavior whose eventual negative effects might be much harder
to diagnose where they occur (far from the source of the problem).

If you hit an assertion, it is 99.9% likely that you are doing something
wrong, rather than that "debug builds are an unsupported configuration for
what you're trying to do". If "it works for release builds", that's
probably just because you haven't noticed the true effects of your bug yet.

bholley

On Wed, Nov 18, 2015 at 8:14 AM, Kent Williams <[hidden email]>
wrote:

> The reason you can't use JS::DontFireOnNewGlobalHook because there's an
> assertion that fails if you do ;-)
>
>
>
> On 11/18/2015 10:00 AM, Boris Zbarsky wrote:
>
>> On 11/18/15 10:47 AM, Kent Williams wrote:
>>
>>> //Oh and another thing:  You can't create a global object with
>>> JS::DontFireOnNewGlobalHook if you want to run with --enable-debug.
>>>
>>
>> Hmm.  Why not?  As long as you fire it yourself later, of course...
>> Certainly debug builds of Firefox do this, and it works fine.
>>
>> And I can't find any documentation on JS::CompartmentOptions.
>>>
>>
>> There might not be any yet, indeed.
>>
>> -Boris
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
>
> --
>
> *Kent Williams*| C++ Developer
> *CourseLeaf from Leepfrog Technologies *
>
> /“The Process of Academic Change”
> /319-337-3877 | courseleaf.com <http://www.courseleaf.com/>
>
> /This message contains confidential information and is intended only for
> the individual named. If you are not the intended recipient of this
> transmission or a person responsible for delivering it to the intended
> recipient, any disclosure, copying, distribution, or other use of any of
> the information in this transmission is strictly prohibited. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system./
>
> _______________________________________________
> 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: Core dump with debugging turned on?

Jason Orendorff-2
On Wed, Nov 18, 2015 at 11:27 AM, Bobby Holley <[hidden email]>
wrote:

> If you hit an assertion, it is 99.9% likely that you are doing something
> wrong, rather than that "debug builds are an unsupported configuration for
> what you're trying to do".


Yeah, to put this in slightly different language, the JS API is

* not super well documented;
* easy to misuse by accident; and
* super crashy if you misuse it

On top of that, sometimes the rules change. So we added these assertions to
catch API misuse when you're still in development, without the cost of
checking in release builds.

My advice: *never* use release SpiderMonkey builds in development. Using a
debug build for the first time is a pain, because of course you'll find a
dozen places in your app where you haven't followed the letter of the law.
It is worth fixing those places. For example, that assertion about your
global class not having JS_GlobalObjectTraceHook? The symptom in a release
build would be nondeterministic crashes. Worth fixing!

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