On 01/29/2013 06:14 AM, Benjamin Smedberg wrote:
On 1/28/2013 6:39 PM, Brian Smith wrote:
Hi all,
After seeing many, many bugs about difficulty of writing code that
properly handles NSS shutdown during XPCOM profile teardown, I think
the only reasonable way forward is to simply make it so that NSS
never shuts down--including in debug builds.
This will greatly simplify lots of code--not just code in
security/manager, but also code in WebRTC, DOM (DOMCrypt), Toolkit
(toolkit/identity), and Necko (netwerk/). We already have a
significant amount of code that is already running in Firefox every
day, but which doesn't handle NSS shutdown correctly.
Could you elaborate on the kinds of things that client code currently
shouldn't do? Is this related to network activity, or something else?
As far as I understand things, the network gets shut down before we
get to NSS shutdown, so there really shouldn't be any clients calling
into PSM via the network by the time we get to that point anyway.
If there are other APIs (cert management or whatnot) that are getting
called late, wouldn't it be ok to just make them fail?
Changing PSM so that NSS never shuts down is an easy thing for me to
do. But it would have the following negative implications:
1. If we don't We will need to mask out lots of memory leaks in
memleak-reporting builds, because we'll have a lot of memory
allocated that would only get freed during NSS_Shutdown.
This is indeed a concern. We have already given up on leak reporting
in release builds, but we do still track leaks from debug builds and
even back out patches that cause leaks. I would be concerned about
patches that make it impossible to track leaks.
2. Because NSS reads and writes to files in the profile directory,
the profile directory must be readable and writable up until process
exit. The current rules for XPCOM shutdown say that services must
stop doing disk I/O well before then; we would need to change the
rules. It is safe to do so?
Why is NSS doing this? We should be done with activities like
certificate management well before... can we ask NSS to sync the
important data to disk and then stop touching the disk? If NSS is
actually touching the disk at process exit, doesn't that leave us in a
possibly-inconsistent state?
It's because mozilla is still using the old NSS database. That database
is *very* badly behaved. Simply opening it R/W and closing it will case
a disk write.
The SQLite DB will only write when you update it, and NSS doesn't cache
writes to the database (If the function succeeds, the data has been
written... well at least to OS has told us the data has been written:).
Switching to SQLite would make this a non-issue.
bob
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
