Closed Bug 296292 Opened 19 years ago Closed 19 years ago

Crash when sending S/MIME encoded mail [@ nsMsgComposeSecure::MimeFinishMultipartSigned]

Categories

(NSS :: Libraries, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jmccabe, Assigned: wtc)

Details

(Keywords: crash)

Crash Data

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050601 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050601 Firefox/1.0+

Sporadic crash after junk mail classification:

(gdb) where
#0  0x409c9671 in kill () from /lib/i686/libc.so.6
#1  0x406d5afd in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x406d5e9b in raise () from /lib/i686/libpthread.so.0
#3  0x080816c2 in nsProfileLock::FatalSignalHandler(int) ()
#4  0x406d867e in __pthread_sighandler () from /lib/i686/libpthread.so.0
#5  <signal handler called>
#6  0x088ae368 in nsUInt32Array::GetAt(unsigned) const ()
#7  0x088c6cc6 in nsMsgDBView::CopyMessages(nsIMsgWindow*, unsigned*, int, int,
nsIMsgFolder*) ()
#8  0x088c6e38 in nsMsgDBView::ApplyCommandToIndicesWithFolder(int, unsigned*,
int, nsIMsgFolder*) ()
#9  0x088c8082 in nsMsgDBView::PerformActionsOnJunkMsgs() ()
#10 0x088c7f41 in nsMsgDBView::OnMessageClassified(char const*, unsigned) ()
#11 0x08899825 in nsBayesianFilter::observeMessage(Tokenizer&, char const*,
unsigned, unsigned, nsIJunkMailClassificationListener*) ()
#12 0x0889a5b1 in MessageObserver::analyzeTokens(Tokenizer&) ()
#13 0x088986a9 in TokenStreamListener::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) ()
#14 0x0888fa92 in nsStreamConverter::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) ()
#15 0x080eace8 in nsStreamListenerTee::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) ()
#16 0x080d3124 in nsOnStopRequestEvent0::HandleEvent() ()
#17 0x080d2ce6 in nsStreamListenerEvent0::HandlePLEvent(PLEvent*) ()
#18 0x4065cf94 in PL_HandleEvent ()
   from /usr/local/thunderbird/libxpcom_core.so
#19 0x4065cec0 in PL_ProcessPendingEvents ()
   from /usr/local/thunderbird/libxpcom_core.so
#20 0x4065e86a in nsEventQueueImpl::ProcessPendingEvents() ()
   from /usr/local/thunderbird/libxpcom_core.so

etc

Seems to happen just after it's finished the classification run on the messages.
Maybe during corpus update?

Reproducible: Sometimes

Steps to Reproduce:
Hmm. Maybe not. More crashing is happening but with an entirely different stack
trace. Could be some entirely unrelated memory corruption is causing generally
unstable behavior:

#0  0x409c9671 in kill () from /lib/i686/libc.so.6
#1  0x406d5afd in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x406d5e9b in raise () from /lib/i686/libpthread.so.0
#3  0x080816c2 in nsProfileLock::FatalSignalHandler(int) ()
#4  0x406d867e in __pthread_sighandler () from /lib/i686/libpthread.so.0
#5  <signal handler called>
#6  0x086f1bd4 in nsMsgComposeSecure::MimeFinishMultipartSigned(int,
nsIMsgSendReport*) ()
#7  0x086f17c7 in nsMsgComposeSecure::FinishCryptoEncapsulation(int,
nsIMsgSendReport*) ()
#8  0x087828bb in nsMsgComposeAndSend::GatherMimeAttachments() ()
#9  0x08787d7c in nsMsgComposeAndSend::HackAttachments(nsMsgAttachmentData
const*, nsMsgAttachedFile const*) ()
#10 0x08788c12 in nsMsgComposeAndSend::Init(nsIMsgIdentity*, char const*,
nsMsgCompFields*, nsFileSpec*, int, int, int, nsIMsgDBHdr*, char const*, char
const*, unsigned, nsMsgAttachmentData const*, nsMsgAttachedFile const*, char
const*) ()
#11 0x0878a7bd in nsMsgComposeAndSend::CreateAndSendMessage(nsIEditor*,
nsIMsgIdentity*, char const*, nsIMsgCompFields*, int, int, int, nsIMsgDBHdr*,
char const*, char const*, unsigned, nsMsgAttachmentData const*,
nsMsgAttachedFile const*, void*, nsIDOMWindowInternal*, nsIMsgProgress*,
nsIMsgSendListener*, char const*) ()
#12 0x087a5f97 in nsMsgCompose::_SendMsg(int, nsIMsgIdentity*, char const*, int) ()
#13 0x087a6a82 in nsMsgCompose::SendMsg(int, nsIMsgIdentity*, char const*,
nsIMsgWindow*, nsIMsgProgress*) ()
#14 0x40674d29 in XPTC_InvokeByIndex ()
   from /usr/local/thunderbird/libxpcom_core.so
#15 0x080a4cde in XPCWrappedNative::CallMethod(XPCCallContext&,
XPCWrappedNative::CallMode) ()
#16 0x080a9bb8 in XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*,
long*) ()
#17 0x400503c8 in js_Invoke () from /usr/local/thunderbird/libmozjs.so
#18 0x4005802e in js_Interpret () from /usr/local/thunderbird/libmozjs.so
#19 0x40050425 in js_Invoke () from /usr/local/thunderbird/libmozjs.so
#20 0x080a1314 in nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned
short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) ()
#21 0x0809e6f9 in nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo
const*, nsXPTCMiniVariant*) ()
#22 0x40674ed8 in PrepareAndDispatch ()
   from /usr/local/thunderbird/libxpcom_core.so
#23 0x40674d29 in XPTC_InvokeByIndex ()
   from /usr/local/thunderbird/libxpcom_core.so
#24 0x080a4cde in XPCWrappedNative::CallMethod(XPCCallContext&,
XPCWrappedNative::CallMode) ()
#25 0x080a9bb8 in XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*,
long*) ()

etc.
Hmm. Seems the second stack is an entirely different crash from the first, and
is consistently reproducbile. I get it every time I try to send S/MIME signed mail.
Summary changed to reflect new nature of crash.
Summary: Crash after junk mail classification → Crash when sending S/MIME encoded mail
This is a trunk build?
Yep. Trunk build.

I suspect this is related to the big NSS PKCS#11 checkins a few days ago. I've
since noticed that if I go to Edit | Preferences | Privacy| Security | View
Certificates my own certs as well as collected third party certs are not
visible. Makes sense that this would break S/MIME signing.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
for my own record, i'm ignoring the original crash report and pushing this bug
to nss.
Status: RESOLVED → UNCONFIRMED
Component: General → Libraries
Keywords: crash
Product: Thunderbird → NSS
Resolution: EXPIRED → ---
Summary: Crash when sending S/MIME encoded mail → Crash when sending S/MIME encoded mail [@ nsMsgComposeSecure::MimeFinishMultipartSigned]
Assignee: mscott → wtchang
QA Contact: jason.m.reid
The behavior appears to be gone, so I suspect this got fixed incidentally by
some NSS checkin.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Joe: this could be a bug that you can no longer reproduce.

There is no NSS function in the two stack traces, so it's
not clear if the crashes were caused by NSS.

In comment 5, you mentioned "the big NSS PKCS#11 checkins
a few days ago".  Were you referring to Nelson's SSL PKCS #11
bypass work?  That code is still in the tip of NSS and
hasn't made it into any Mozilla build yet.

Up to you if you want to reopen it Wan Teh.

The NSS checkin I was referring to was pointed at just be looking at checkins
that might affect NSS in the week leading up to this behavior. I honestly don't
recall what the checkin was though.

When this was happening I was unable to view my own certificates, I was unable
to view other people's certificates, and sending S/MIME encoded mail caused a
crash. Since none of these behaviors exist any longer, and there's no NSS info
in the stacks I was able to produce, I would recommend just letting this bug go
away.
Crash Signature: [@ nsMsgComposeSecure::MimeFinishMultipartSigned]
You need to log in before you can comment on or make changes to this bug.