Logging of "quality events"

Benjamin Smedberg benjamin at smedbergs.us
Thu Sep 19 13:45:26 UTC 2013

> > suggestions for other types of error log events that should be 
> include in this system
> Understanding which tab (and associated web page) might be at the 
> heart of my problems, or if is a problem of well distributed load 
> across many tabs and window would be very insightful.
Multi-process Firefox will help, but won't totally solve the problem. 
I'm hopeful that rust/servo will be able to compartment things by task 
in a way that makes this even more possible. In the meantime, I want to 
focus this discussion on the short-term stability efforts, which 
certainly don't require assigning blame to particular web pages.

>> This makes me think of
>> https://bugzilla.mozilla.org/show_bug.cgi?id=662814.
> Having grappled with low level event logging in both the above bug and
> in Valgrind (the -d option), I'd say it's remarkably difficult to
> construct something which is guaranteed deadlock-free if you want it
> to be usable in marginal situations, for example when jemalloc is not
> initialised or is compromised (though heap corruption).
> In both cases I inclined strongly to making the logger as self-contained
> as possible, even to the point of either avoiding dynamic memory
> allocation, or having its own private allocator.  Relying on layers of
> other libraries in such cases tends to be a fast-track to deadlocks
> and/or segfaults, IME.
I'm seriously considering whether I want the main part of the logger to 
be in-process at all. Having a logger as a separate process and 
communicating events to it via sockets/pipes might be a better long-term 

> From the perspective of add-on developer I would applause for a more 
> detailed output with errors reported to the console.
> A "stack" report (limited to max = 10 or so) with each error report 
> would be great.
> (Maybe a question to extension like 'console2' also)
> Günter
I don't think this is relevant to the proposal. The debugging tools are 
great, but we don't need that level of information to provide either 
stability metrics or support. I'd like to keep this simple.


I forgot to specify a followup list in the original posting: to avoid 
continued cross-list spam, please send followups to dev-platform.

More information about the firefox-dev mailing list