kmag sent me a log that caused an assertion in my cycle collector log parser. The error is on the second line here:

0x14fc80e2ea60 [rc=1] CallbackTimeoutHandler
0x14fc80e2ea60 [rc=1] TimeoutHandler

0x14fc9a14d800 mGlobal
0x14fc8a4a9c40 mFunction

The object 0x14fc80e2ea60 is getting reported twice, first as a CallbackTimeoutHandler, then as a TimeoutHandler.

This is a regression from bug 1558776, part 2. The problem is the traverse method for CallbackTimeoutHandler calls cb.DescribeRefCountedNode(), then calls the Traverse method for TimeoutHandler, which calls DescribeRefCountedNode a second time.

I think this is only a real problem if logging is on. (mVisitedRefCounted will end up being slightly wrong, but that's only for telemetry.)

I'm not sure what a good fix for this is. This is also an issue for ScriptTimeoutHandler.

It looks like you can actually delete the call to NS_CYCLE_COLLECTION_CLASSNAME(TimeoutHandler)::TraverseNative(s, cb), because it doesn't do anything, but the code will end up being fragile, because then if somebody innocently goes in and adds something to TimeoutHandler, the CC won't see it.

(In reply to Andrew McCreight [:mccr8] from comment #0)

It looks like you can actually delete the call to NS_CYCLE_COLLECTION_CLASSNAME(TimeoutHandler)::TraverseNative(s, cb), because it doesn't do anything, but the code will end up being fragile, because then if somebody innocently goes in and adds something to TimeoutHandler, the CC won't see it.

Yes, TimeoutHandler doesn't do anything for CC, don't call NS_CYCLE_COLLECTION_CLASSNAME(TimeoutHandler)::TraverseNative(s, cb) is okay, and I don't have better soluton other than this. Thanks.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f36f2d4c0162c648d985db316605acdaf0fc16a8

https://hg.mozilla.org/mozilla-central/rev/ac01b45d14a1