698151 - schedulePreciseGC doesn't actually run when the stack is empty?

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Andrew McCreight [:mccr8]]

The attached test creates a cycle in memory, does schedulePreciseGC, runs the CC, then runs the GC and the CC again, then checks if the cycle is freed.  On my local build, which is based on trunk from around 10-16, this test fails.  It fails because one of the elements of the cycle is on the machine stack, at least according to JS_DumpHeapComplete, which uses JS_TraceChildren, so I think it should be accurate?  I am invoking the JS heap logger from nsXPConnect::Collect(), so I wouldn't think there'd be any JS running again.

What makes it extra magical is that if you comment out this line the test passes:
//thing.flange = {king_kong:new_dom2};

This also worked with a version of trunk from around 10-03.

Now, the big disclaimer here is that this is on top of my giant stack of patches for weak map cycle collector integration, so it is possible I messed something up with stacks, but it seems unlikely.  I'll try to come up with a test example for a more up-to-date version of trunk that does not rely on quite so many patches, but if people have suggestions for how I can investigate this they'd be appreciated.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: failing test

Comment 2

[Andrew McCreight [:mccr8]]

> is that if you comment out this line the test passes

That should read if you uncomment that line the test passes...

Comment 3

[Andrew McCreight [:mccr8]]

Bill said in IRC that machine_stack indicates that the conservative stack scanner found something in the C++ stack, not the JS stack, so I guess schedulePreciseGC isn't to blame.  I'll try investigating with a debugger to see what is happening.

Comment 4

[Andrew McCreight [:mccr8]]

This problem went away on its own, so I guess this was bogus, or something that ended up getting fixed elsewhere.