Flusspferd

Hello Aaron,

What does "it crashes" mean?

Please provide the output of the program.

Aristid

Aristid Breitkreuz wrote:

Hello Aaron,

What does "it crashes" mean?

Please provide the output of the program.

Aristid

14:23 < aaron__> i'm using codelite, it has a nice debugger
14:24 < aaron__> except it doesn't let me copy the stack trace!
14:24 < ashb> heh
14:24 < aaron__> i'll just type it out...
14:24 < aaron__> js_Interpret
14:24 < aaron__> js_Invoke
14:24 < aaron__> js_InternalInvoke
14:24 < aaron__> JS_CallFunctionValue
14:25 < aaron__> flusspferd::object::apply
14:25 < aaron__> flusspferd::object::call

Turns out that if you change void callback (function &fn) { to void callback (object &fn) { it doesn't crash and behaves correctly.

So if you change the callback to be like this:

void callback(object o){
  function fn(o);
  fn.call(global());
}

it works fine.

I can reproduce this, after updating the code: http://gist.github.com/249372

I added a testcase:

commit:116cd15fbf5ef36f0c90b930d92057d13a923b47

$ ./build/bin/test_regression_159 
Running 1 test case...
Assertion failure: obj->dslots, at ../jsops.cpp:2860
unknown location(0): fatal error in "bug_159": signal: SIGABRT (application abort requested)

*** 1 failure detected in test suite "TEST_OUTPUT" 
JS API usage error: found live context at 0x99b6428
JS API usage error: 1 context left in runtime upon JS_DestroyRuntime.
JS engine warning: leaking GC root '' at 0x99c0c98
JS engine warning: leaking GC root '' at 0x99c5448
JS engine warning: leaking GC root '' at 0x99a8868
JS engine warning: leaking GC root '' at 0xbff772f4
JS engine warning: leaking GC root '' at 0xbff76968
JS engine warning: leaking GC root '' at 0x99c2af8
JS engine warning: leaking GC root '' at 0x99c5360
JS engine warning: leaking GC root '' at 0x99a8808
JS engine warning: leaking GC root '' at 0x99c26c8
JS engine warning: leaking GC root '' at 0x99a79c0
JS engine warning: leaking GC root '' at 0x99c20f8
JS engine warning: leaking GC root '' at 0x99a7af0
JS engine warning: leaking GC root '' at 0x99aa6a8
JS engine warning: leaking GC root '' at 0x99a9fb0
JS engine warning: leaking GC root '' at 0x99a7e08
JS engine warning: leaking GC root '' at 0x99a7590
JS engine warning: leaking GC root '' at 0x99aa010
JS engine warning: leaking GC root '' at 0xbff772e8
JS engine warning: leaking GC root '' at 0x99c23f0
JS engine warning: leaking GC root '' at 0xbff76af8
JS engine warning: leaking GC root '' at 0x99c2728
JS engine warning: 21 GC roots remain after destroying the JSRuntime at 0xb785e008.
                   These roots may point to freed memory. Objects reachable
                   through them have not been finalized.

commit:44d4644ff20592de1702f536a24d56e1768572ca

... did not help. But I think we should keep it, because it is apparently "more correct".

<MisterN> i think it used to be JS_ExecuteFileHandle
<MisterN> but maybe ashb has changed that. wait a moment, i need to look up
<Wes-_> Are you explicitly rooting the intermediary script object?
<MisterN> hmm let me check!
<MisterN> JSScript *script = JS_CompileUCScript <- should this object be rooted?
<MisterN> can JSScript* even BE rooted?
<Wes-_> yes!!!
<Wes-_> you need obj =  JS_NewScriptOBject(script)
<Wes-_> JS_AddRoot(obj)
<Wes-_> well, except, you know, with cx, and good spelling
<MisterN> Wes-_: why do we need that shit?
<MisterN> Wes-_: and do we need to KEEP the obj?
<Wes-_> if you fail to root it, the garbage collector can free your functions during execute
<MisterN> after the script has run?
<Wes-_> MisterN: no, after it's run it is rooted by the global object
<MisterN> spidermonkey!!!
<MisterN> Wes-_: the docs say that if i don't fail to do JS_DestroyScript, there's no problem doing it without JS_NewScriptObject. is that wrong?
<Wes-_> MisterN: It is definitely wrong when GC Zeal is. 100% confident.
<Wes-_> And of course, if executing triggers a GC, you will have the same effect
<MisterN> Wes-_: that sounds like a serious bug in spidermonkey?
<Wes-_> I personally witnessed the collector collecting global functions in this case
<Wes-_> It's in bugzilla, IIRC I reported it two years ago
<Wes-_> but it's not a serious bug
<Wes-_> that's why JS_NewScriptObject() exists, so you can root the script
<MisterN> Wes-_: if i do JS_NewScriptObject, then i can omit the JS_DestroyScript?
<Wes-_> MisterN: No
<Wes-_> mistern: no, wait
<Wes-_> sec
<MisterN> k i'll be away very briefly
<Wes-_> MisterN: I never call JS_DestroyScript(), but I might be counting on JS_DestroyRuntime() to clean up
<Wes-_> MisterN: Yeah - my suggestion - do not call JS_DestroyScript, do use JS_NewScriptObject, and root the resultant object for the time your script runs
<Wes-_> for the first time, if it leaves functions attached to global, that's okay
<MisterN> Wes-_: and after the script runs, the functions will be available?
<Wes-_> MisterN: Yes, they will now be rooted by global
<MisterN> ok, then i'll eat now
<MisterN> Wes-_: hmm it doesn't really seem to help.
<-> ryah_away heißt jetzt ryah
<-> tolmasky_ heißt jetzt tolmasky
<Wes-> MisterN: Bummer - wasn't a GC hazard then. That change should stay in there, though, or you can have problems, especially with gc zeal
<MisterN> Wes-: hmmm
<Wes-> you might want to double-check with jorendorff, but I'd sure recommend it
<Wes-> not like an extra temporary root is going to hurt you anyhow
<MisterN> Wes-: i suspect it's somewhere in our module system
<Wes-> mistern: argh
<MisterN> Wes-: the problem only happens when the callback is in a module
<Wes-> that's really odd
<Wes-> do you have another way of loading JS code?
<MisterN> hmm
<MisterN> well i think we do, but it's not used right now
<Wes-> also, it might not hurt to go back to, say, tracemonkey from 6 months ago and see if it still breaks
<MisterN> Wes-: i'm not sure if i want this to be a bug in flusspferd or a bug in spidermonkey
<MisterN> Wes-: i'm using mozilla-central btw
<MisterN> from yesterday
<Wes-> yeah, the trick is to isolate the source of the error
<Wes-> because IIRC it's just pointer-spew, right?
<MisterN> well the backtrace does tell that it's somehow related to the callback :D
<Wes-> yeah, but how/why :)
<Wes-> funny question, does it work okay if you disable the assertion?
<MisterN> i'm too tired right now. but i'll write down to remember to do that
<Wes-> easiest way is to build w/o --enable-debug

<Wes-> easiest way is to build w/o --enable-debug
<MisterN> but manually enable --enable-gczeal?
<Wes-> does your crash happen only with gczeal?
<MisterN> not tested, i always used it so far
<Wes-> should probably test
<Wes-> crash w/ gczeal means it's probably not GC related, and vice-versa
<MisterN> crash w/o you mean?
<Wes-> yeah

So we found that this can be fixed by eliminating the function class. Obviously not something to do for 0.9.1.

So my resolution is that people who want to use 0.9.x have to replace function with object in their code if this bug hits them.

Status geändert durch Changeset commit:"7a59392fa9e283ea0b524fb4d5f89dac017a5ee4".