Linux-Crash on AOL cert enrollment page - Trunk, M092 & N610 [@ - ssl_DefSend]

VERIFIED FIXED in mozilla0.9.4


18 years ago
10 years ago


(Reporter: ji, Assigned: bbaetz)


(4 keywords)

crash, platform-parity, regression, topcrash

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(1 attachment)



18 years ago
Build: branch 07/24 linux build
OS: RH 6.2-J

Using 07/24 linux branch build with a new profile, when I tried to get an AOL 
cert from, the browser crashes.

Steps to reproduce:
1. Launch browser with a new profile.
2. Go to
3. Click on Get the Cert
The browser crashes, a talkback window comes up, but the browser window remains.
However it seems the browser is disconnected from network. You can't go to any 
web site from that browser window.
Callstack to follow.

Comment 1

18 years ago
Below is the callstack:
Incident ID 33283866
Stack Signature + 0xb2c82 (0x404d9c82) de72ad1c
Bug ID
Trigger Time 2001-07-24 10:50:44
User Comments Get AOL cert
Build ID 2001072405
Product ID Netscape6.10
Platform ID LinuxIntel
Stack Trace + 0xb2c82 (0x404d9c82) + 0x1ce78 (0x401b5e78) + 0xc42a (0x401a542a)
nsSSLIOLayerClose() + 0xb5f7 (0x401a45f7)
nsThread::Main() + 0x1f3ee (0x401b83ee) + 0x5b85 (0x401ccb85
Keywords: crash


18 years ago
Version: 1.01 → 2.0

Comment 2

18 years ago
Verified on Linux. Mac and Win32 are OK.

Comment 3

18 years ago
Adding keywords. I'll download builds going backward until I find the one that 
does not crash.
Keywords: nsbeta1, regression

Comment 4

18 years ago
This was working with the 7/23 Linux commercial build.

Comment 5

18 years ago
My mistake. This bug goes back to at least 7/13.

Comment 6

18 years ago
May 23 works for me.  May 31 fails for me.  I have no other builds in between.

Comment 7

18 years ago
Is this a Linux and JA build only?

Comment 8

18 years ago
I'm using the normal Linux branch build on Redhat 6.0. I used to not be able to 
reach , but now that the browser 
loads it, the crash bug has become visible.

Comment 9

18 years ago
The build I used is English linux branch build and system is RH6.2 Japanese.

Comment 10

18 years ago
Getting certs with Linux from any of the sites on this page under "CMS 4.2 testing" works. The crash 
occurs only when clicking on the link at
Priority: -- → P1

Comment 11

18 years ago
cc shadow

Comment 12

18 years ago
Changing summary.
Keywords: nsdogfood, pp
Summary: Browser crashes when trying to get a cert → Linux-Crash on AOL cert enrollment page

Comment 13

18 years ago
I just finished simple test for this version of browser with cms and netscape 
root ca. 
I didn't see any problem with cms and it is not crashed with netscape root ca 
but hung. 
It displays "connecting to" but nothing's happened. 

Comment 14

18 years ago
reproduced on Linux build 0725200105.0.9.2
Assignee: ssaux → javi
Target Milestone: --- → 2.0

Comment 15

18 years ago
anyone know if uses Keep-Alive connections?

Comment 16

18 years ago
btw, is still running iCMS 4.1.  I don't know how to
tell if it's using keep_alives but I can check it if someone knows a way to
determine that.

in the CMS.cfg I see:

I'm running the 0724 build of N6.1 on Windows 2000 and aren't seeing any
problems with that site, fwiw.

Comment 17

18 years ago
You may be able to use something like that in a debug build
setenv NSPR_LOG_MODULES nsHttp:5
setenv NSPR_LOG_FILE foo.log
I just saw that in bug 90196 where the resulting log shows information about
keep alive.
Not sure whether it will work in your case.

Comment 18

18 years ago
Using the Linux RTM candidate bits (installer) at:


I was unable to produce a crash on Red Hat Linux 6.2.  However, I did experience
a "hang" when going from "" to
"".  However, if I go directly to
the URL "", I am able to
successfully enroll and obtain a user certificate.  I verified this with Beomsuk
on his machine, and he was able to produce the exact same behaviour.

Comment 19

18 years ago
target 2.1
Target Milestone: 2.0 → 2.1

Comment 20

18 years ago
Summary: this bug does not show up when you use CMS 4.2 SP2 (the current
version).  It happens when you use old versions of CMS.

Comment 21

18 years ago
adding nsenterprise to all P1, P2 PSM bugs with target milestone of 2.1
Keywords: nsenterprise

Comment 22

18 years ago
I think this might be a dup of bug 83747 because the stacks look identical. 
Although bug 83747 was logged first, this bug has actually been looked at, so
I'll leave it up to QA to mark that bug a dup of this one.

Adding Trunk, M092 & N610 [@ - ssl_DefSend] to summary and topcrash
keyword for tracking.  

The final N610 Linux build 2001072504 has been seeing this crash according to
the latest Talkback data. Here are a couple of entries:

ssaux's crash:
Incident ID 33328193
Stack Signature + 0xb0eb2 (0x404ceeb2) 86d987d7
Bug ID
Trigger Time 2001-07-25 10:43:41
User Comments Reproducing bug 92123
Build ID 2001072504
Product ID Netscape6.10
Platform ID LinuxIntel
Stack Trace + 0xb0eb2 (0x404ceeb2) + 0x1ce78 (0x401b4e78) + 0xc42a (0x401a442a)
nsSSLIOLayerClose() + 0xb5f7 (0x401a35f7)
nsThread::Main() + 0x1f3ee (0x401b73ee) + 0x4eca (0x401caeca) 

and junruh's crash:

Incident ID 33325439
Stack Signature + 0xdea32 (0x40551a32) f223bb1f
Bug ID
Trigger Time 2001-07-25 09:35:02
User Comments
Build ID 2001072504
Product ID Netscape6.10
Platform ID LinuxIntel
Stack Trace + 0xdea32 (0x40551a32) + 0x1ce78 (0x401b7e78) + 0xc42a (0x401a742a)
nsSSLIOLayerClose() + 0xb5f7 (0x401a65f7)
nsThread::Main() + 0x1f3ee (0x401ba3ee) + 0x760e (0x401d460e) 
Keywords: topcrash
Summary: Linux-Crash on AOL cert enrollment page → Linux-Crash on AOL cert enrollment page - Trunk, M092 & N610 [@ - ssl_DefSend]

Comment 23

18 years ago
Win32 07/27 branch build and Mac 07/26 branch build are hung when clicking Get
the Cert icon on page, the status bar shows
the browser is transfering data from forever. But win
and Mac builds don't crash.

Comment 24

18 years ago
For win32 and mac builds, when I see the hang, if I reload the page by clicking 
on Stop and Back icon, clicking on Get the Cert icon can get to the enrollment 
My memory from looking at talkback reports was that this crash was a SIGPIPE
(not a SIGSEGV as most crashes are).  I'm not behind the firewall now so I can't

It's useful to include the crash reason when filing talkback bugs.

Comment 26

18 years ago
Trigger Type:   Program Crash 
Trigger Reason:   SIGPIPE: Write on Pipe, with no one to read: (signal 13)

jay/shiva,  lets get trigger reason added to the quick search report.

Comment 27

18 years ago
*** Bug 83747 has been marked as a duplicate of this bug. ***

Comment 28

18 years ago
I got this a couple of times, when reading mail over imap/ssl (see bug 92517).
The first time was at shutdown, and the second time was while reading mail,
after not having touched the computer for a while. In that case, I could keep
using the product after talkback came up.

Are we writing to a closed socket?

Comment 29

18 years ago
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 30

18 years ago
I'm not seeing this crash on Linux anymore.

Marking WORLSFORME.  Please re-open if this still crashes.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Still crashes, according to talkback.  In fact, it's probably our #1 trunk
topcrash on Linux.

With recent NSPR build system changes (bug 88045), we now see the top of the
stack more clearly.  Looking at a report from the 2001-08-15 build, the top of
the stack is: ...
Resolution: WORKSFORME → ---

Comment 32

18 years ago
(Oops, I added this in the wrong bug.)

Is there a web site that produces this crash? does not anymore.  Without a reproducible
test case, this will *never* get fixed.

(I've tried the 3 sites mentioned in the talkback reports and none of them cause
my build from this morning to crash.)

The fact that the crash on went away without
changing PSM code leads me to believe we're crashing in NSS because of a bug in
a different part of the code.  Perhaps trying to write to a closed socket that
only happens on slow connections.  

Anyone in QA have a modem they could test with?

Recent user comments on this crash (some of which have URLs) are below.  Numbers
in parentheses are talkback report numbers.

     (34159147) Comments: clicked on gaim link
     (34156456) URL:
     (34156456) Comments: Adding a cert via
     (34144893) Comments: crash on file quit
     (34134388) Comments: I wasn't even in the virtual desktop where mozilla was
running. The mail/news app was up  and was checking/filtering mail  so I assume
that's what did it....
     (34130076) Comments: exit mozilla and terminate network connection at about
the same time
     (34104702) URL:
     (34104702) Comments: Pressed refresh after leaving Mozilla unused for about
2 hours.
     (34092247) URL:
     (34092190) URL:
     (34069916) Comments: 2001-08-13-08 linux 2.2
     (34069457) Comments: 2001-08-13-08 on linux 2.2tried selecting a newsgroup
to download byusing the download and sync window.on linux it hangs  then i guess
after waiting a whileit crashes
     (34030983) URL:
     (34030983) Comments: Submitting the form by clicking on "Register" button.
     (33996736) URL:
     (33996736) Comments: Just reading an article.  I didn't even click on
everything.  Odd  I don't think I've ever had a totally spontaneous crash before.
     (33994589) URL:
     (33994589) Comments: submitting e-mail on's webmail.
     (33915983) URL:
     (33915983) Comments: clicked on a link to read the next page of a story
     (33897868) Comments: 2001080910 linx 2.2idle had browser/mesger up and it
     (33844811) Comments: i think only one thread crashed or something.  so
maybe that's a dns problem.  mozilla is still alive and a little bit well

Comment 34

18 years ago
I noticed that nowhere in this bug report does anyone mention the bit about "PSM
or Netscape 6.1 detected: click here first to get a patch" appearing on the
"" webpage - is that because this
patch link is a recent addition somewhere?  

If no, why isn't it mentioned - is it inconsequential?  
If yes, has anyone tried it?

ji, could you try this again after installing the patch?

Comment 35

18 years ago
That "patch" was added on July 4, 2001.  The "patch" is actually just the GTE
CyberTrust root certificate, which our internal CA chains to.
cc'ing wtc.  dbaron observed that NSPR passes 0 (not MSG_NOSIGNAL) for the send
flags, and does not abstract signal syscalls, so callers are likely to get
SIGPIPE in socket reader abrupt termination situations.  What to do?  At the
least, I think we need to prevent SIGPIPE from being raised, at the NSPR level
if possible.


Comment 37

18 years ago
NSPR ignores SIGPIPE.  Maybe that is not happening?

It is possible that we are bitten by the fact that
pthreads on Linux are really process clones.  Maybe
we need to ignore SIGPIPE for each thread.

Comment 38

18 years ago
That is what I did in a different pthread application I wrote. In Linux, each
pthread has its own mask of signals being blocked and allowed. It is best to
unblock the signals only in those threads where you want to handle the signal.

However, all threads share the same signal handler code, which makes things
difficult if you want to handle a signal in multiple threads, as you don't have
access to thread local storage from within the signal handler...
It could be that talkback is trapping the SIGPIPE and sending crash reports even
though Mozilla would otherwise ignore it.

Comment 40

18 years ago
dbaron: Don't think so. Its being raised, and theres no current signal handler
for SIGPIPE, so we'd crash without talkback, wouldn't we?
It sounds like a non-main thread got killed by the SIGPIPE, and that (rightly)
triggered talkback.  What wtc said: do we need to make sure each new thread
ignores SIGPIPE?


Comment 42

18 years ago
brendan wrote:
> What wtc said: do we need to make sure each new thread
> ignores SIGPIPE?

According to the LinuxThreads FAQ, this is not necessary.
So what NSPR does should be sufficient.

Comment 43

18 years ago
Is it possible that Mozilla in Linux sets a signal handler for SIGCHLD only?

I traced through InstallUnixSignalHandlers, it does essentially nothing on my

Using gdb, I stopped at the first line of main, set breakpoints to functions
sigaction and sigvec. It only stopped twice, in unix_rand.c, setting handlers
for SIGCHLD only.

Did I miss another system function that sets signal handlers, or do you think
gdb was unable to behave correctly?

gdb was unable to work with a breakpoint set at sigprocmask. However, I tried to
set breakpoints on source locations where sigprocmask should be called, but it
didn't stop.

Do you have an idea, how we could test whether there is really a signal handler

Comment 44

18 years ago
/netwerk/dns/src/unix-dns.c, line 699 -- CATCH_SIGNAL_DFL(SIGPIPE);
wtc, that looks like dead code, jwz's old child process dns helper jazz from the
classic days.  Cc'ing gordon and darin, who can best say whether this file
should be cvs removed.


Comment 46

18 years ago
Wan-Teh helped me to confirm that I saw a debugger problem. During application
init the following code is executed:

    struct sigaction sigact;
    int rv;
    sigact.sa_handler = SIG_IGN;
    sigact.sa_flags = 0;
    rv = sigaction(SIGPIPE, &sigact, 0);
    PR_ASSERT(0 == rv);
Ok, is something reseting SIG_DFL for SIGPIPE later on?


Comment 48

18 years ago
dbaron: you were right. If I take ns/fullsoft/tests/crasher.c, massage it so
that it compiles, and then add the sigaction call from nspr to main(), and
change the crash test to raise(SIGPIPE), then:

a) If we initialise talkback before calling sigaction, then the program
continues after the call to raise.
b) If we call sigaction before initialising talkback, then talkback catches it,
and we appear to crash (I had to hack lots of stuff to get it to run at all, so
I'm not surprised that the dialog didn't show up).

stracing the build shows that talkback calls sigaction for SIGPIPE.

And of course NSPR is initialised before it starts registering components, so we
get case b).

This would also explain why I stopeed seeing this - I stopped using the branch
builds to use self-built trunk stuff (without talkback) after 6.1 was released.
talkback people - we need a way to convince talkback not to register a handler
for SIGPIPE. Alternately we can reset the signal handler for SIGPIPE ourselves
in the QFA component. We don't have to worry about portability in setting the
signal handler because linux is the only unix system to use talkback. I can come
up with the obvious patch for that if thats felt to be the best way to go.

Why did this wait until June to hit us? This should have been happening forever,
shouldn't it?

Comment 49

18 years ago
bbaetz: good detective work!  We should report this bug to
the talkback vendor and ask them for a fix or workaround.
(The workaround is probably the obvious patch.)

Comment 50

18 years ago
shiva, can you check on this?

Comment 51

18 years ago
The workarround is the obvious patch, and when I get in to work I'll generate
one (of course, I can't actually test that it works, but I'll add a
raise(SIGPIPE), and check that talkback doesn't come up)

The question of why this didn't hit us earlier still remains, though. Did
something in PSM change so that they try writing to a closed socket? This should
have hit non-PSM use, in theory.
It does hit non-PSM use.  Out of the last 100 or so stack signature
crashes that I went through, I'd say about 40-60 were this crash, 14 were
SIGPIPEs in, and 7 were an IMAP-related SIGPIPE.

Comment 53

18 years ago
OK. Lets disable the signal, then. This will then be identical to the
non-talkback builds. Patch once I get somewhere I can easily build commercial.

Comment 54

18 years ago
Taking, patch to commercial tree attached, looking for r, sr

I've compiled the file I've modified - I can't link it, or test it, though,
because I don't have the config stuff for that.
Assignee: javi → bbaetz
Component: Client Library → Talkback
Product: PSM → Browser
Target Milestone: 2.1 → mozilla0.9.4
Version: 2.0 → other
Are we going to completely ignore SIGPIPE ?  or Is there a specific case
do we want to ignore ?

Comment 57

18 years ago
Yes, we need to completely ignore sigpipe. That code was taken from the NSPR
init code - we're just duplicating that behaviour.

Comment 58

18 years ago
ccing shannon and jdunn.

Comment 60

18 years ago
So I've been told that we support talkback on HPUX as well. I'll have to copy
the NSPR code for that as well (which is slightly different). I'll need testing
that the file compiles, to check that I've included the correct headers.

Comment 61

18 years ago
wtc says that the HPUX specific code is not needed, since mozilla doesn't use
that type of threading (its incompatible with X, apparently). So my original
patch can go in as is.

Can I get an sr from someone please? darin?

Comment 62

18 years ago
Your patch is fine for all Unix flavors, including
HP-UX.  Make sure the indentation is right.  (Hard
for me to tell from a patch file.)  r=wtc.

Comment 63

18 years ago
fyi I believe we also use talkback on solaris.

Comment 64

18 years ago


18 years ago
Last Resolved: 18 years ago18 years ago
QA Contact: ckritzer → chofmann
Resolution: --- → FIXED

Comment 65

18 years ago
Fix checked into the comm tree yesterday. QA assigning to default talkback QA. 
I guess to verify, just look at the talkback logs.

Comment 66

18 years ago
I'm not finding this exact stack trace in talkback for today.  I'm marking this
verified, reopen if it turns up again.

Comment 67

18 years ago
*** Bug 89518 has been marked as a duplicate of this bug. ***

Comment 68

18 years ago
*** Bug 96269 has been marked as a duplicate of this bug. ***


10 years ago
Component: Talkback Client → Talkback Client
Product: Core → Core Graveyard
Crash Signature: [@ - ssl_DefSend]
You need to log in before you can comment on or make changes to this bug.