I wrote the following in bug 1270308 comment 14, and thought it might be worth mentioning/discussing here. Not a new observation, of course, but perhaps worth thinking about. I should re-emphasize the effort that goes into making clean shutdown work without intermittent is a LOT of work for a lot of people. That said, any radical change here is also a lot of work, at least to change over, but it could save time in the long run, and might incrementally improve security.
Randell (In reply to Andrew McCreight [:mccr8] from comment #13) > (In reply to Jan-Ivar Bruaroey [:jib] from comment #12) > > Aren't there other ways we could find runtime leaks? > > Unfortunately, there are none that I know of. In order to check for leaks, > you have to know whether every live allocation should be alive or not. > Waiting for shutdown and declaring that nothing should be alive is the > easiest way to do this. Right, though there are a couple of ways to do that. One is what we're (mostly) doing, which is to unwind everything and free, then see what's left. The other way (which we do with a few bits) is to mark allocations or classes are being ok to exist at exit (some of Mutexes for example IIRC). Big advantage there is cleanup/unwind code has risks of it's own and can introduce race conditions. Downside of this is that the analysis of leaks is trickier; you end up needing basically a GC scanner to see of allocations are tied to a "ok to leak" root. That said... overall I think that's a better/safer/overall-lower-effort (at least ongoing) than the complexity of the unwind code, just to avoid leaks. Also: real leaks we care about are either large single allocations, or allocations that can increase in number the more times you do something. (Which includes leaks-occasionally-due-race). One-off leaks (leak of a single pre-process instance of something) are at most an annoyance unless large or eating CPU. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
