200119 - crash when I shutdown (StopCRLUpdateTimer) [@ nsHashtable::Reset ]

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Henrik Gemal]

I seem to crash when I shutdown mozilla

TB18687205X

Comment 1

[Chris Lyon]

build id?

Comment 2

[Henrik Gemal]

2003033108

Comment 3

[Henrik Gemal]

also crash when I shutdown after XPI install:
TB18690017G

not sure if the crash is the same...

Comment 4

[Matthias Versen [:Matti]]

Henrik: Still a problem ?

If yes: we need a new Tb ID 

Comment 5

[Henrik Gemal]

TB20651765Y

still crash everytime

I'm using Proxomitron as Proxy

Comment 6

[Matthias Versen [:Matti]]

Incident ID 18687205
Stack Signature 	0x002801fc 373b2b99
Product ID 	MozillaTrunk
Build ID 	2003033105
Trigger Time 	2003-04-01 07:18:06
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	
URL visited 	
User Comments 	shutting down mozilla
Trigger Reason 	Access violation
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x002801fc
nsHashtable::Reset [c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp, line 337]
nsHashtable::Reset [c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp, line 322]
nsNSSComponent::StopCRLUpdateTimer
[c:/builds/seamonkey/mozilla/security/manager/ssl/src/nsNSSComponent.cpp, line 888]
0x80000000
nsObserverService::NotifyObservers
[c:/builds/seamonkey/mozilla/xpcom/ds/nsObserverService.cpp, line 212]
nsProfile::ShutDownCurrentProfile
[c:/builds/seamonkey/mozilla/profile/src/nsProfile.cpp, line 1331]
DoOnShutdown [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 777]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1666]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c)

Gemal: And you also crash with a more recent build ?

-> XPCOM (or NSS ?)

Comment 7

[Doug Turner (:dougt)]

NSS first.

Comment 8

[Matthias Versen [:Matti]]

Everyone seems to think that mstoltz is the NSCP TOP developer (because he get's
all the PSM/NSS Bugs)

-> PSM (looks more like PSM than NSS if I watch CVS log for that file)

Comment 9

[Henrik Gemal]

I still crash and submit talkback's everytime...

TB20953069E

Comment 10

[Henrik Gemal]

Now I've been crashing at shutdown for the last 4 month!
HELP!

I keep submitting crash reports so it must be a top crash...:(

TB21752103Y

Comment 11

[Henrik Gemal]

it seems to have something to do with enabling the CRL update.
Whenever I have the Certificate Revoke list enabled I crash after browsing
around on https sites.

Comment 12

[Larry Riffle]

Same here with 1.4 on MacOSX , both 1.4 and 1.5a on RH 8.0. Only happens
with CRL autoupdate enabled and software security device logged in. Then
it happens every "quit" but CRL autoupdate only works once.

Talkback is enabled.

Perhaps related to http://bugzilla.mozilla.org/show_bug.cgi?id=198371 ?

Comment 13

[Larry Riffle]

1.5b, no change. Still crashes every shutdown with security device logged in and
crl autoupdate enabled.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Adding NSS folks to CC list.  

Comment 15

[Julien Pierre]

The crash is not in NSS, but PSM, according to the posted stack in comment #6. I
couldn't access the talkback server tonight to look at the other incidents.

Comment 16

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 17

[John G. Myers]

The CRL timer code looks dodgy.  It looks like shutdown could happen while the
timer is firing, causing the update thread to lock a lock that was freed by the
shutdown thread.

Comment 18

[Asa Dotzler [:asa]]

*** Bug 201230 has been marked as a duplicate of this bug. ***

Comment 19

[R.K.Aa.]

*** Bug 242328 has been marked as a duplicate of this bug. ***

Comment 20

[matt]

I have submitted 242328 which is a dup of this bug and did some testing :
If i uncheck "Enable Automatic Update for this CRL" in Edit / Preferences /
Privacy & Security / Validation / Manage CRLs / Settings the crash does not
happen anymore.

Hope this helps a little.

PS : In my experience, contrary to what is said in comment #11, the crash
happens whether or not you browse https sites or not when the auto update is
enabled.

Comment 21

[Brant Gurganus]

*** Bug 249177 has been marked as a duplicate of this bug. ***

Comment 22

[Timo J. Rinne]

Firefox 0.9.1 crash (Windows 2000) on exit when auto updated crl checking is on
and https-page with certificate affiliated to this crl is visited.  In my
opinion this is very bad sign of instability since it's in security features,
even though it occurs only on exit.

Comment 23

[Nicholas Allen]

*** Bug 251746 has been marked as a duplicate of this bug. ***

Comment 24

[James Rome]

Ahhh. I did update the CRL also.

Comment 25

[Adam Hauner]

*** Bug 253350 has been marked as a duplicate of this bug. ***

Comment 26

[Kevin Brosnan]

*** Bug 273605 has been marked as a duplicate of this bug. ***

Comment 27

[timeless]

*** Bug 261062 has been marked as a duplicate of this bug. ***

Comment 28

[Hao Chen]

*** Bug 289837 has been marked as a duplicate of this bug. ***

Comment 29

[Oliver Klee]

*** Bug 301546 has been marked as a duplicate of this bug. ***

Comment 30

[Philip Heede]

I submitted the latest bug report to marked as a dupe pointing back to this
ancient report. This is an extremely old bug and yet no progress seems
forthcoming. Is anyone actively looking at the problem- this bug report is not
even marked ASSIGNED?

I have solved the problem locally by disabling CRL auto-updating as described in
the earlier commens, but it seems like something that should be fixed promptly..

Comment 31

[Henrik Gemal]

people have other tasks/little time

but if you're a c++ coder you're more than welcome to try to where/why it
crashes and submit a patch.

Comment 32

[Philip Heede]

I realize there are many tasks and too few people to perform them. 
Unfortunately, I'm not a C++ programmer (Java or .NET/C# though) or I would 
have loved to look at the bug myself.

My question was directed to the fact that the bug is verified and is 
classified as 'critical' and yet seems not to have received any real attention 
since march 2004 (comment #17). If we are content to leave the bug for now, 
shouldn't it be reclassified to a lower priority?

Comment 33

[timeless]

*** Bug 299253 has been marked as a duplicate of this bug. ***

Comment 34

[Josh Birnbaum]

*** Bug 307186 has been marked as a duplicate of this bug. ***

Comment 35

[Guillaume ROMAGNY]

I've been crashing at shutdown for at least the last 12 months ! Win2000 SP4(5)
with Firefox 0.8-1.0.6

I confirm behaviour in comment #20 and comment #22

I am a Thawte + CAcert user, it is really *annoying*

The linux version with X11 emulator under W2K is fine but not in my field of
interest.

crash short list (2 last months)

TB9235831W, TB9226332W, TB9219120M, TB9215502X, TB9195940K, TB9191779Z,
TB9188974G, TB9165282W, TB9161987M, TB9127629Q, TB9120003E, TB9096718K,
TB9088098E, TB9066816G, TB9059890Q, TB9048507Z, TB9048113W, TB9023519K,
TB9015509M, TB9014218K, TB9009760G, TB9005945H, TB9003289X, TB8986740H,
TB8967545Y, TB8953333Q, TB8941189W, TB8915950K, TB8905466H, TB8883899E,
TB8879257X, TB8878256E, TB8873573K, TB8856706E, TB8843859K, TB8839111Q,
TB8834382X, TB8830604Y, TB8827832E, TB8827457W, TB8820963E, TB8820907X,
TB8820815H, TB8809542X, TB8784361G, TB8784010M, TB8782845Q, TB8781567W,
TB8717824E, TB8717278Z, TB8690024Y, TB8689721H, TB8689571G, TB8689092Y,
TB8688111X, TB8680259H, TB8677712Q, TB8654833W, TB8652708H, TB8647012X,
TB8644353Y, TB8643055E, TB8640792G, TB8622034E, TB8598884Y, TB8597882K,
TB8597386Q, TB8596694K, TB8587150X, TB8587080W, TB8586533Q, TB8585845M,
TB8584814G, TB8583866H, TB8583805E, TB8583759Z, TB8583581X, TB8583476E,
TB8582669G, TB8579858Q, TB8576133W, TB8574543Y, TB8573678K, TB8572431Y,
TB8561041Y, TB8560747G, TB8560208M, TB8552728G, TB8552289M, TB8535921M,
TB8532981G, TB8531521W, TB8522511Y, TB8519345W, TB8503753Z, TB8500933E,
TB8499538E, TB8496484E, TB8495539H, TB8495095Q, TB8493590X, TB8485094E,
TB8483936M, TB8470636Q, TB8468064M, TB8465143Z, TB8439475Y, TB8435314K,
TB8405022Y, TB8404791Z, TB8404719E, TB8389926E, TB8387919X, TB8385416W,
TB8376406Y, TB8375648W, TB8372257Z, TB8371489Z, TB8363646M, TB8363497H,
TB8363487K, TB8363361E, TB8363252G, TB8363227K, TB8363083E, TB8363007Z,
TB8362924W, TB8362636W, TB8362500M, TB8355492K, TB8348579X, TB8348323E,
TB8315428W, TB8314919Q, TB8312681K, TB8311804H, TB8310409G, TB8309940Y,
TB8309546K, TB8293587Q, TB8275481K, TB8274424M, TB8255640Y, TB8241399Y, TB8234389Y

Comment 36

[Guillaume ROMAGNY]

Occurs also with lastest beta of Deeper Park

Comment 37

[Guillaume ROMAGNY]

related question : does the CRL auto-update stopped affect OCSP responder
requests ? (my guess : no) if not, CAcert offers OCSP so it's a less important
problem.

Comment 38

[Guillaume ROMAGNY]

after reactivating all the CRL, I can no longer reproduce the bug ???

Comment 39

[Guillaume ROMAGNY]

Arg ! it's back... annoying

Comment 40

[Kai Engert (:KaiE:)]

Looking at the code, I see one possibility for a crash:

If a call to StopCRLUpdateTimer happens at about the same time as singleton
nsNSSComponent gets destroyed.

The call to StopCRLUpdateTimer is triggered by an event,
PROFILE_BEFORE_CHANGE_TOPIC. If that event were synchronous and happened before
destroying nsNSSComponent, we should not see the crash. As I have no idea if
that is true, let's try to make our code safer.

Both function StopCRLUpdateTimer and the destructor of nsNSSComponent have
similar cleanup code. 

Looking at the stack trace in comment 6, I conclude variable
crlsScheduledForDownload had a valid pointed at the time we called Enumerate(),
but the variable was no longer valid when it executed the following line, trying
to execute Reset(), but triggering the crash. This could happen if one thread
processed the mentioned event, and the other the destructor.

Therefore I propose we protect the cleanup code with a lock.
Luckily we already have an appropriate lock and just need to protect some
additional actions.

I will attach a patch shortly, that can not cause any harm, but possibly fix the
crash. We should land it and give it a try.

Comment 41

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 42

[Darin Fisher]

Comment on attachment 196606 [details] [diff] [review]
Patch v1

>+    nsHashtable *ht_to_cleanup = nsnull;
...
>+    ht_to_cleanup = crlsScheduledForDownload;

nit: Move declaration of ht_to_cleanup down to here, where it is
assigned a value.


>+    nsHashtable *ht_to_cleanup = nsnull;
...
>+    ht_to_cleanup = crlsScheduledForDownload;

Same here.


r=darin

Comment 43

[David :Bienvenu]

can we drive this forward? I'm happy to sr it if that helps.

Comment 44

[David :Bienvenu]

*** Bug 258847 has been marked as a duplicate of this bug. ***

Comment 45

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Updated patch as requested, has r=darin

Comment 46

[David :Bienvenu]

Comment on attachment 197821 [details] [diff] [review]
Patch v2

this looks like it would help - but I'm worried about the lock itself. By the
same logic, couldn't the destructor destroy mCrlTimerLock before
StopCRLUpdateTimer tries to use it?

Moving up the clearing of mUpdateTimerInitialized in the destrcutor to right
after we release the lock and before we destroy it also might help here.

Comment 47

[Kai Engert (:KaiE:)]

You are right, we should improve it more.

I agree updating the mUpdateTimerInitialized variable should be protected by the
lock, too.

And actually, since the crash is happening so often for some users, it seems to
 be likely, that we indeed have a race between the destructor and the cleanup
code, triggered by profile manager events.

I noticed that mCrlTimerLock has a confusing lifetime, I am changing it to live
as long as nsNSSComponent.

In addition, crlDownloadTimerOn signals, whether the timer is currently running. 
If that is detected in the destructor, we cancel the timer. However, at that
time, the timer event might have already come in, and the receiving function
might wait on our timer lock. When the destroctur frees the lock, the timer
processing function might continue, even though destruction is already finished.

Because of that, I'm changing the time processing function (Notify) to re-test a
variable after having obtained the lock. If it discovers that the timer is no
longer initialized, it will stop.

To make sure the nsNSSComponent lives as long as the timer processing function
is finished, we will acquire the timer lock again, just before returning from
the destructor.

Yet another change, the Init code can run multiple times, in a profile changing
application. However, the Init code does not yet use the lock, I am changing
that, too.

And the code to cleanup the timer is now the same as in StopCRLUpdateTimer, so
let's just make of the the function by calling it.

Comment 48

[Kai Engert (:KaiE:)]

Attachment: Patch v3

David, what do you think?

Comment 49

[David :Bienvenu]

I've applied the patch and am looking at the code as a whole...

one thing that would help readability is to fix the naming convention for some
of the member vars, e.g., crlDownloadTimerOn should be mCrlDownloadTimerOn,
crlsScheduledForDownload, etc...

Comment 50

[David :Bienvenu]

Comment on attachment 198812 [details] [diff] [review]
Patch v3

looks ok, thx. We should get some baking on the trunk for this...

Comment 51

[Kai Engert (:KaiE:)]

Comment on attachment 198812 [details] [diff] [review]
Patch v3

Hi Darin, as the patch has changed a lot, could you please have another look?
Thanks.

Comment 52

[Darin Fisher]

Comment on attachment 198812 [details] [diff] [review]
Patch v3

>Index: security/manager/ssl/src/nsNSSComponent.cpp

>+  // Should other code currently be processing a timer event,
>+  // make sure this lives long enough.
>+
>+  PR_Lock(mCrlTimerLock);
>+  PR_Unlock(mCrlTimerLock);
>+
>+  if (mCrlTimerLock) {
>+    PR_DestroyLock(mCrlTimerLock);
>+    mCrlTimerLock = nsnull;
>+   }

This looks problematic to me.  How do you know that the thread
"processing a timer event" is not about to acquire mCrlTimerLock
when this code runs?  I think this code may still crash.

The usual solution to this sort of problem is to use a reference
counter to determine when to destroy the mutex.  For example, you
could write a function like this:

  void ReleaseCrlTimerLock() {
    if (PR_AtomicDecrement(&mCrlTimerLockRefCnt) == 0) {
      PR_DestroyLock(mCrlTimerLock);
      mCrlTimerLock = nsnull;
    }
  }

Then, have each thread call ReleaseCrlTimerLock when they are done
with mCrlTimerLock.  You'd of course have to make each thread take
an "owning reference" to mCrlTimerLock by atomically incrementing
mCrlTimerLockRefCnt at the right time.

It might be nice to write a small class that represents a reference
counted mutex.

Comment 53

[Kai Engert (:KaiE:)]

Darin, you are right, however:

> You'd of course have to make each thread take
> an "owning reference" to mCrlTimerLock by atomically incrementing
> mCrlTimerLockRefCnt at the right time.

This is tricky. I don't know the right time. I suggest another approach.

To reiterate:
- nsNSSComponent is a singleton.
- it needs a timer, and timer processing code.
- the nsNSSComponent might get destroyed while the timer is still running.

My new suggestion:
- create a new helper class, nsCRLTimerProcessor
- have nsNSSComponent create an instance of nsCRLTimerProcessor
- nsCRLTimerProcessor contains a backpointer to nsNSSComponent, to trigger actual processing
- nsCRLTimerProcessor owns a mutex to protect itself
- nsCRLTimerProcessor is reference counted
- when nsNSSComponent gets destroyed, it notifies nsCRLTimerProcessor, which sets its backpointer to nsnull, so no further processing will happen, and dereferences nsCRLTimerProcessor
- whenever the timer is started, nsCRLTimerProcessor is increased, and when the timer fires, nsCRLTimerProcessor is decreased
- when nsCRLTimerProcessor realizes its no longer referenced, it destroys itself

Comment 54

[Kai Engert (:KaiE:)]

Attachment: patch to allow for easier TESTING

While trying to reproduce the bug, with the CRL I was using, I noticed our code would schedule the CRL download in the future, or not at all.

To allow for better testing, this patch changes our code to run the crl download timer every second.

Comment 55

[Kai Engert (:KaiE:)]

Attachment: Patch to enhance thread safety - POSTPONED

Motivated by Darin's comment I worked on this patch.
The idea behind the patch is outlined in my comment 53.

However. During testing this patch, I realized the real cause for our bug might be a simple double free...!

For now I will mark this patch as obsolete, because it might not be required.
Maybe the cleanup is a good idea, but we might want to delay landing this code for a while.

The CRL download timer is rarely used actually. Because of that, I have the feeling it's unlikely a race is causing the crash that is experienced so frequently.

So my suggestion is: Let's postpone this patch for a while. If we want to land it, let's do it in a second, future step.

I will attach another patch.

Comment 56

[Kai Engert (:KaiE:)]

Attachment: Patch v4

When used in combination with the TESTING patch, after downloading a CRL and activating automatic update, this patch fixes the crash for me.

The crash I see is in the PLD-Hashtable-Cleanup code.

Our code inserts "new nsStringKey" items into nsHashtable.
Before deleting the hashtable, we enumerate the items and clean the keys.
But nsHashtable seems to have code to delete the keys, too.
So I'm removing our cleanup, IMHO it's not required.

Is my understanding correct?


I noticed two other problems, which might not be related, but I think is a good idea to fix.

nsNSSComponent implements nsITimerCallback, but does not specify that in the NS_IMPL_ISUPPORTS macro.

And the constructor to nsHashtable ovbiously wanted to request threadsafety by setting the boolean parameter to PR_TRUE, but this does not match the constructor, which takes two arguments and has the threadsafety boolean as its second argument.

Comment 57

[Darin Fisher]

> Our code inserts "new nsStringKey" items into nsHashtable.
> Before deleting the hashtable, we enumerate the items and clean the keys.
> But nsHashtable seems to have code to delete the keys, too.
> So I'm removing our cleanup, IMHO it's not required.
> 
> Is my understanding correct?

Have you verified that the nsStringKey objects are deleted?  Can you point me at the nsHashtable code that deletes the keys?  Are you saying that PLDHashTableOps::clearEntry will be called when the PLDHashTable instance is finalized?

Comment 58

[Kai Engert (:KaiE:)]

Attachment: Debug Patch to demonstrate everything gets cleared correctly.

Darin, during my first testing, I had added some printf statements and saw that PLDHashTableOps::clearEntry got called during the call to Reset out hashtable, without using our clear function.

But your words made me feel unsure, and I analyzed more. (Meanwhile I the hashtable code much better, so it was absolutely worth it.)

I'm attaching this debugging version of the patch, which does not use nsStringKey, but uses a derived class, that dumps debugging statements to the console.

When I run this code, and count the number of construction and destruction calls, they are balanced.

While studying the code I learned that during nsHashTable::Put, a clone of the key will be made. Because of that, I'm deleting our key after inserting it. Actually, there is no need to create the key on the heap, on the stack will do, too.

Comment 59

[Kai Engert (:KaiE:)]

Attachment: Patch v5

This updated version of patch v4 does no longer leak the key.

Comment 60

[Kai Engert (:KaiE:)]

> Can you point me at the nsHashtable code that deletes the keys?

I added asm("int $3") to the testing code, here is the stack trace that cleans up our single hash table entry on calling nsHashtable::Reset

#0  0xb74f3069 in ~my_string_key (this=0x9a36c10) at /home/kaie/moz/170/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:136
#1  0xb7826e83 in clearHashEntry (table=0x9cbb1a8, entry=0x9cda93c) at /home/kaie/moz/170/mozilla/xpcom/ds/nsHashtable.cpp:80
#2  0xb781fd4f in PL_DHashTableRawRemove (table=0x9cbb1a8, entry=0x9cda93c) at /home/kaie/moz/170/mozilla/xpcom/ds/pldhash.c:590
#3  0xb781fe26 in PL_DHashTableEnumerate (table=0x9cbb1a8, etor=0xb7827806 <hashEnumerateRemove>, arg=0x0)
    at /home/kaie/moz/170/mozilla/xpcom/ds/pldhash.c:622
#4  0xb78278e8 in nsHashtable::Reset (this=0x9cbb1a0, destroyFunc=0, aClosure=0x0)
    at /home/kaie/moz/170/mozilla/xpcom/ds/nsHashtable.cpp:336
#5  0xb7827888 in nsHashtable::Reset (this=0x9cbb1a0) at /home/kaie/moz/170/mozilla/xpcom/ds/nsHashtable.cpp:321
#6  0xb74f6430 in nsNSSComponent::StopCRLUpdateTimer (this=0x9cba940)
    at /home/kaie/moz/170/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:915
#7  0xb74f81bf in nsNSSComponent::Observe (this=0x9cba940, aSubject=0x9725f80, aTopic=0xb5cd780f "profile-before-change",
    someData=0xb5cd78f8) at /home/kaie/moz/170/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:1648
#8  0xb782c453 in nsObserverService::NotifyObservers (this=0x96cf080, aSubject=0x9725f80,
    aTopic=0xb5cd780f "profile-before-change", someData=0xb5cd78f8)
    at /home/kaie/moz/170/mozilla/xpcom/ds/nsObserverService.cpp:208
#9  0xb5cbe7d4 in nsProfile::ShutDownCurrentProfile (this=0x9725f80, shutDownType=1)
    at /home/kaie/moz/170/mozilla/profile/src/nsProfile.cpp:1358
#10 0x08061b49 in DoOnShutdown () at /home/kaie/moz/170/mozilla/xpfe/bootstrap/nsAppRunner.cpp:806
#11 0x080649d5 in main (argc=3, argv=0xbfae2634) at /home/kaie/moz/170/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1785

Comment 61

[Kai Engert (:KaiE:)]

Checked in to trunk, hopefully the bug is fixed.

Please test the next nightly build (starting tomorrow).
If you still see the crash, please reopen the bug.
(We shall then work on landing the thread safety enhancement)

Comment 62

[ffbugs]

I had been experiencing the same symptoms for a while. But deleting my sole CRL seems to fix it.

At this time of writing, enabling CRL will still crash-on-exit on at least 1.0.7, 1.5rc2 and rc3 and 1.5 Final, on WinXP-SP1.

The following Talkbacks have been submitted by me while trying to troubleshoot the crash. There is a strong possibility that these are all related to this current bug:

TB12618533Z, TB12618377G, TB12617941Q, TB12617822X, TB12617577X, TB12617469X, TB12617330G, TB12617201M, TB12617064W, TB12617063Y, TB12603519Q, TB12603451G, TB12581424M, TB12572158Z, TB12538263E, TB12514656K, TB12424831G, TB12410073W

Fingers crossed.

Comment 63

[timeless]

[e-mail]: does it crash on firefox-trunk nightlies?

Comment 64

[ffbugs]

To timeless: never tried nightlies. Though FF has not crashed since removing the CRL, after extensive testing. I'm now 95% sure that my crashes were related to this bug.

Comment 65

[Wan-Teh Chang]

[e-mail]: the fix for this bug is not in any of
the Firefox releases you listed in comment 62.  The bug fix
is only in the Firefox trunk.  Please help us verify the
bug fix by testing a recent Firefox trunk nightly build
(specifically, 2005-11-09 or later).

Comment 66

[ffbugs]

To comment #63 and #65: I have just downloaded and installed the latest nightly as of 5th December 2005, and reinstlaled the "offending" CRL from http://www1.hongkongpost.gov.hk/CA1_crl_archive/crl_2005_12/200512010115.crl and enabled auto-update of the CRL.

The bug does seem to be fixed. I have not been able to reproduce the crash on this version. I will keep testing it for a few days - no news is good news.

Comment 67

[Adam Guthrie]

*** Bug 357993 has been marked as a duplicate of this bug. ***

Comment 68

[Stephanie Daugherty [:sdaugherty]]

Removing myself from CC.

Comment 69

[jweare]

remove myself from CC

Comment 72

[Kai Engert (:KaiE:)]

Comment on attachment 201852 [details] [diff] [review]
Patch v5

Nominating this patch for the old 1.8.0 branch, see bug 374492.

Comment 73

[Daniel Veditz [:dveditz]]

Comment on attachment 201852 [details] [diff] [review]
Patch v5

Too late for 1.8.0.12