We're trying to trace a context without a global object. That context is created when the service something gets the service @dbaron.org/leak-monitor-service;1. The cycle collector should just deal. This should be blocking M9, we want people to use that extension to help us track down leaks.

This makes us not add contexts with null globalobjects to mClearedGlobalObjects so that when we look up global objects corresponding to contexts in TraceXPConnectRoots we only get a non-null globalobject if the context is in mClearedGlobalObjects.

Anybody using cycle collector with trunk is overriding extension compatibility; it isn't even close to working for finding leaks anymore.

Er, anybody using *leak monitor* with trunk since cycle collector landed is ...

This might be triggered by more than just Leak Monitor though. Also, wouldn't it make it harder to fix Leak Monitor so it works with the beta?

It might. I'm just surprised people are using current leak monitor.

Blocking, but agree with dbaron and don't think it should hold up beta unless there's a solid expectation that this indicates another potential crash in the cycle collector: peterv, is that what you're saying?

s/Blocking/I think this should block final,/ above

Yeah, discussed with peterv. Marking as blocking. Let's get this landed. Also, sounds like we need to get leak monitor working in general. Is there a bug for that?

I think this is showing up as js_GetGCThingFlags crashes on breakpad: http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&signature=js_GetGCThingFlags&query=js_GetGCThingFlags&range_value=1

FWIW, I wasn't using Leak Monitor when I started experiencing this crash, but it was enabled, since I have compatibility checking turned off. There may be other folks in the same boat who aren't actually using the extension but still have it enabled.