Crash when deleting dumb context from JSD_DebuggerOff()

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

Crash when deleting dumb context from JSD_DebuggerOff()

dassburger (Bugzilla)
Hello!

We develop some program which uses SpiderMonkey as an interpreter for
embedded language. The platform also supports debugging embedded
scripts.

I have a JS runtime which has some script loaded in it. Then by some
request from outside I turn on debugging with JSD_DebuggerOnForUser().
After some debugging actions comes another request which results in a
call to JSD_DebuggerOff(). Here, the script is still loaded, but waits
for some user action, for example, for a button click on a form. While
executing the call to JSD_DebuggerOff() occasionaly it results in
Access Violation somewhere in SpiderMonkey's garbage collector. The
first trouble in hunting this bug is that the crash occurs occasionaly.
Most time it's perfectly Ok. I thought about some multithreading
problem (because SpiderMonkey and JSD are compiled NOT thread-safe),
but the problem remains even if all calls to JavaScript-specific stuff
occurs from the same thread.

So, the question is is it allowed to call JSD_DebuggerOff() while
runtime still has contexts and scripts loaded.

To be specific, there is no scripts _executing_ at the moment of crash.
They are compiled and loaded into runtime, but all of them are waiting
for user actions. The request to turn of debugging comes from user, but
it is not processed by JS, but by other parts of our programs.

(Sorry, my English is not good, so the explanation can seem unclear.)

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

Re: Crash when deleting dumb context from JSD_DebuggerOff()

James Ross
Dassburger wrote:
> So, the question is is it allowed to call JSD_DebuggerOff() while
> runtime still has contexts and scripts loaded.

Yes; if Venkman is not set to start JSD at startup, then it will turn
JSD on and off as you open and close Venkman, which works fine.

You can turn debugging for a particular SpiderMonkey runtime on and off
as you please, however, JSD can only see scripts that are loaded *after*
it is turned on, as far as I can remember. (So, if you turn it off and
on it 'forgets' all the currently loaded scripts.)

You mentioned threading and that SpiderMonkey and JSD are not compiled
with thread-safety - if you even *think* about using threads without
compiling the appropriate thread-safety you *will* crash randomly and
often. You should definitely compile with thread-safety or only ever use
one thread with these components (even then, you could accidentally call
one or other from the wrong thread unless you're exceptionally careful).

Once that issue is dealt with, any crashes are misuse of the APIs or
bugs - you *will* need to collect stack traces from a debug build for
any more to be worked out. Note that, if your app has multiple threads,
get the stacks for all of the threads at the time of the crash - even if
you don't think you're using SpiderMonkey or JSD across threads.

I would suspect that something in SpiderMonkey that JSD is using has
gone away unexpectedly or otherwise without JSD's knowledge, possibly
because of GC, and that causes JSD to die when being turning off. Need
stacks with line numbers and such to begin figuring out *what* object it
might be, though.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger