Currently, the logging stubs in security/sandbox/chromium/base/shim/base/logging* just discard any messages that are logged. We should fix that so they actually send messages somewhere. This should allow removing the Linux sandbox's LOG_ERROR macro. This will be more important when the Linux sandbox uses more of the upstream Chromium code. Most of the original Chromium logging code should be reusable here, I think. In contrast with bug 1013988, I see no point in reintroducing NSPR dependencies here; at least on Linux platforms, NSPR logging is strictly worse than fprintf.

(In reply to Jed Davis [:jld] from comment #0) > In contrast with bug 1013988, I see no point in reintroducing NSPR > dependencies here; at least on Linux platforms, NSPR logging is strictly > worse than fprintf. Jed can you provide some more background on this? I'd like to take your needs into consideration in our logging improvement project (bug 881389).

(In reply to Eric Rahm [:erahm] from comment #2) > Jed can you provide some more background on this? I'd like to take your > needs into consideration in our logging improvement project (bug 881389). The problems with NSPR were: 1. Can't do logging that's enabled by default without obscure env vars. 2. Can't be used in async signal context. And at least one unwanted "feature": 3. Debug builds only by default. The debug-only and disabled-by-default problems are problems for other users, but there's not much of our code that's (potentially) run in async signal handlers: sandboxing, the profiler, maybe some small parts of the JS engine. Async signal safety is also a somewhat difficult requirement — we'd need to be able to supply a stack-allocated buffer, use a suitable implementation of formatted I/O (Chromium has one), and write the result with something like the write() system call (i.e., not stdio).

Move process sandboxing bugs to the new Bugzilla component. (Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)