Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 21. 12. 2010 15:35, Marsh Ray wrote: On 12/21/2010 06:44 AM, Matej Kurpel wrote: How can I check if I am doing something bad to the heap, please? Sadly, I am not so skilled C++ programmer (well, rather a noobish one) and I mostly don't know about the inside stuff you were talking about here... It's OK, everybody has to debug this problem occasionally. Also, the code for C_SignInit is nearly the same as for C_DecryptInit which works fine. Plus, when I only return non-CKR_OK error code from C_SignInit (and do nothing else in it), it still crashes. 1. Go over all your code again and make sure nothing is writing past the end of the memory you get from new/malloc, or someone else gives to you. Search in your code for 'memcopy' and friends, a bad parameter to those functions can easily cause this. Search for C-style (casts) of pointers and reinterpret_cast. I did. I have avoided memcpy (or any mem-related functions) just in case anyway. 2. Make sure you don't pass a pointer to some object which remembers it and then delete/free the pointer while that object is still using it. Try simply commenting out everywhere you manually free memory. It will be a memory leak, but you might be able to figure out which one(s) cause the crash that way. I don't free memory manually. The module is just a set of short C functions so the variables are freed up automatically anyway. 3. See if you can reproduce the problem on Linux. Run it with Valgrind and/or Electric Fence These are similar to PageHeap, often times open source apps will already have a build configuration for that on Linux. Can't test it on Linux since I am using the MS-only functions (like sprintf_s). And my implementation of sockets use Winsock. Well, that's the interoperability of C++ I guess... I don't have the time and nerves to fiddle around with it in Linux anyway. 4. Test it with Microsoft's PageHeap tool. There's lots of documentation on it and probably some forums that can help you with that. If that doesn't find it right away, try re-building with the Release Microsoft C Runtime library as discussed. I have tried the PageHeap tool as you suggested. I have managed to enable PageHeap for thunderbird.exe but then I was unable to figure out what the output from that tool is? Does it write a log file for me somewhere? Or how do I check the output of PageHeap? From what I have read on Microsoft's PageHeap web page, they suggest trying Application Verifier as an GUI alternative to PageHeap. I tried it as well but when thunderbird.exe was added as an applicatin to verify, I couldn't start it (it said The application was unable to start correctly (0xc142). Click OK to close the application). I tried both the x86 and x64 versions of Application Verifier, with same results. I guess I am out of options here. I would like to solve this problem very much. If I can be of more help - if you need more info (or output from some more debugging programs), just ask. You can do it. - Marsh If I only was able to load the source code of Thunderbird in Visual Studio, that would be great. I could debug it line-by-line as usual. Why does it have to be so hard? :( M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-27 01:44 PDT, Matej Kurpel wrote: If I only was able to load the source code of Thunderbird in Visual Studio, that would be great. I could debug it line-by-line as usual. You can. Download and unpack the sources from ftp://ftp.mozilla.org/pub/thunderbird/releases/latest-3.1/source/thunderbird-3.1.7.source.tar.bz2 (or substitute the release you're running, as needed). You don't need to build it yourself. Use the symbol server (You've already done this step, IIRC). Just tell your debugger where you put the sources locally. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 27. 12. 2010 18:15, Nelson B Bolyard wrote:
On 2010-12-27 01:44 PDT, Matej Kurpel wrote:
If I only was able to load the source code of Thunderbird in Visual
Studio, that would be great. I could debug it line-by-line as usual.
You can. Download and unpack the sources from
ftp://ftp.mozilla.org/pub/thunderbird/releases/latest-3.1/source/thunderbird-3.1.7.source.tar.bz2
(or substitute the release you're running, as needed).
You don't need to build it yourself.
Use the symbol server (You've already done this step, IIRC).
Just tell your debugger where you put the sources locally.
Wow - I was able to Attach To Process... in VS2008 and then I caused
the crash deliberately.
It showed me the source code and call stack, which is great. But
evaluating most of the variables returned CXX0069: Error: variable
needs stack frame. No idea what that means. The source code is far too
complex for me to understand anyway :(
I am sending you the call stack as VS displayed it to me. It crashed on
a line in nsGlobalWindow.cpp saying:
nsWindowSH::InvalidateGlobalScopePolluter(cx, currentInner-mJSObject);
saying Uncaught exception occurred.
Call stack:
thunderbird.exe!nsGlobalWindow::SetNewDocument(nsIDocument *
aDocument=0x00a02c00, nsISupports * aState=0x, int
aClearScopeHint=0x0001, int aIsInternalCall=0x000b) Line 1760 +
0x3 bytesC++
thunderbird.exe!nsGlobalWindow::SetNewDocument(nsIDocument *
aDocument=0x00a02c00, nsISupports * aState=0x, int
aClearScopeHint=0x0001) Line 1569C++
thunderbird.exe!DocumentViewerImpl::InitInternal(nsIWidget *
aParentWidget=0x04e498c0, nsISupports * aState=0x, const
nsIntRect aBounds={...}, int aDoCreation=0x0001, int
aInPrintPreview=0x, int aNeedMakeCX=0x0001) Line 960C++
thunderbird.exe!DocumentViewerImpl::Init(nsIWidget *
aParentWidget=0x00a79580, const nsIntRect aBounds={...}) Line 699C++
thunderbird.exe!nsDocShell::SetupNewViewer(nsIContentViewer *
aNewViewer=0x04e8c3c0) Line 7304 + 0x1b bytesC++
thunderbird.exe!nsDocShell::Embed(nsIContentViewer *
aContentViewer=0x04e8c3c0, const char * aCommand=0x01ab0481, nsISupports
* aExtraInfo=0x) Line 5472C++
thunderbird.exe!nsDocShell::CreateContentViewer(const char *
aContentType=0x03c37d68, nsIRequest * request=0x050c6740,
nsIStreamListener * * aContentHandler=0x050c6740) Line 7090 + 0x15
bytesC++
thunderbird.exe!nsDSURIContentListener::DoContent(const char *
aContentType=0x03c37d68, int aIsContentPreferred=0x, nsIRequest
* request=0x050c6740, nsIStreamListener * * aContentHandler=0x04effb5c,
int * aAbortProcess=0x0045ac48) Line 150C++
thunderbird.exe!nsDocumentOpenInfo::TryContentListener(nsIURIContentListener
* aListener=0x06eb4e80, nsIChannel * aChannel=0x04effb5c) Line 734C++
thunderbird.exe!nsDocumentOpenInfo::DispatchContent(nsIRequest *
request=0x050c6740, nsISupports * aCtxt=0x) Line 434 + 0x15
bytesC++
thunderbird.exe!nsDocumentOpenInfo::OnStartRequest(nsIRequest *
request=0x050c6740, nsISupports * aCtxt=0x) Line 287C++
thunderbird.exe!nsJARChannel::OnStartRequest(nsIRequest *
req=0x05bac330, nsISupports * ctx=0x) Line 867 + 0x16 bytesC++
thunderbird.exe!nsInputStreamPump::OnStateStart() Line 445C++
thunderbird.exe!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x04e7cb68) Line 407C++
xpcom_core.dll!nsOutputStreamReadyEvent::Run() Line 113C++
xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=0x0001,
int * result=0x0045aef0) Line 527 + 0x6 bytesC++
xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread *
thread=0x0001, int mayWait=0x0001) Line 250 + 0xd bytesC++
xpcom_core.dll!nsThread::Shutdown() Line 468 + 0xa bytesC++
thunderbird.exe!nsSound::PurgeLastSound() Line 140C++
thunderbird.exe!nsSound::~nsSound() Line 135C++
thunderbird.exe!nsSound::`scalar deleting destructor'() + 0x8
bytesC++
thunderbird.exe!nsIndexedToHTML::Release() Line 62 + 0x18
bytesC++
thunderbird.exe!XPCJSRuntime::GCCallback(JSContext *
cx=0x04f1d400, JSGCStatus status=JSGC_END) Line 760 + 0x2a bytesC++
thunderbird.exe!DOMGCCallback(JSContext * cx=0x04f1d400,
JSGCStatus status=JSGC_END) Line 3827 + 0x14 bytesC++
thunderbird.exe!XPCCycleCollectGCCallback(JSContext *
cx=0x04f1d400, JSGCStatus status=JSGC_END) Line 412 + 0x10 bytesC++
js3250.dll!js_GC(JSContext * cx=0x04f1d400, JSGCInvocationKind
gckind=GC_NORMAL) Line 3822 + 0x5 bytesC++
js3250.dll!JS_GC(JSContext * cx=0x04f1d400) Line 2439 + 0x8
bytesC++
thunderbird.exe!nsXPConnect::Collect() Line 479C++
xpcom_core.dll!nsCycleCollector::Collect(unsigned int
aTryCollections=0x0001) Line 2434 + 0x5 bytesC++
xpcom_core.dll!nsCycleCollector_collect()
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-27 10:39 PDT, Matej Kurpel wrote: Wow - I was able to Attach To Process... in VS2008 and then I caused the crash deliberately. Bravo. It showed me the source code and call stack, which is great. But evaluating most of the variables returned CXX0069: Error: variable needs stack frame. No idea what that means. The code at which you were looking was compiled with Frame Pointer Optimization (FPO), which causes the compiler to NOT use one of the registers for its usual purpose, acting as a pointer to the function's local variables, and instead use it as a general purpose registers. The debugger you're using is confused by that. I don't know how you can work around it. Assuming that you ARE using the symbols from Mozilla's symbols server, perhaps you need to use a newer version of the Visual Studio debugger. Perhaps you need to tell your VS Debugger to expect FPO somehow (e.g. a settable option). You might ask about this debugging issue in mozilla.dev.builds. I think if anyone would know how to work around FPO, they would. In any case, the code you're examining is not NSS code nor PSM code. The people in this group are not the experts in that code. You need help from the Thunderbird developers. I am sending you the call stack as VS displayed it to me. It crashed on a line in nsGlobalWindow.cpp saying: nsWindowSH::InvalidateGlobalScopePolluter(cx, currentInner-mJSObject); saying Uncaught exception occurred. Call stack: The stack you supplied shows a NULL value for aState being passed several levels down the stack. That's suspicious, but not necessarily a bug. I'd suggest you find the caller that first passes that NULL value, and look at the code that does that. Perhaps you will find some clues about the problem there. Anything more I could do? Yes, file a bug report in bugzilla.mozilla.org, product Thunderbird. Include all the stack info and other info you provided in the email to which I am responding. If you have Thunderbird crash IDs (look like GUIDs) that might have been previously reported by your TBird to Mozilla, include those. But don't expect a quick response. You may add my email address to the CC list on your new bug report. That won't hasten a solution, but it will satisfy my curiosity. :) Regards, -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 19. 12. 2010 9:27, Nelson Bolyard wrote: On 2010-12-16 19:21 PDT, Marsh Ray wrote: On 12/16/2010 04:39 PM, Matej Kurpel wrote: ChildEBP RetAddr Args to Child 0015f130 5fa0c52b e06d7363 0001 0003 KERNELBASE!RaiseException+0x58 (FPO: [Non-Fpo]) 0015f168 5fa14f13 0015f178 5fa7aa24 5fa5c11c MOZCRT19!_CxxThrowException+0x46 (FPO: [Non-Fpo]) (CONV: stdcall) [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161] So Mozilla builds its own CRT without FPO, cool. Yes, Mozilla builds its own CRT, which is a modified version of the MSVC CRT, whose sources come only with the pay (not free) versions of MSVC. They do this in order to replace MSVC's normal heap code (malloc) with their own JEmalloc. Mozilla's source repository doesn't include ANY of the MSVC source code, but only includes a ed script that patches that source without including any of it. Sadly, this means that people with the free MSVC cannot build MOZCRT19, because they lack the sources to be patched. IMO, this is a flaw for an open source project, but ... :( 0015f180 003b474b 0028 0015f290 5f9ad1d9 MOZCRT19!operator new+0x73 (FPO: [1,3,0]) (CONV: cdecl) The above func must be statically linked from the Mic CRT into the Moz CRT. So it's still FPO. Weird. Right. IIRC, it's built from the plain old MSVC new.cpp source. It calls malloc and throws an exception if malloc returns NULL. [e:\buildbot\win32_build_31\build\objdir-tb\mozilla\memory\jemalloc\crtsrc\new@61] Looking at http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ I don't see the source or crtsrc\new.cpp. Must be copied in from Microsoft source code a build time. Right. In any case, 'operator new' is throwing a C++ exception. Ordinarily that would be due to a bad parameter (e.g., -1) or lack of memory. Right. Any NULL return from malloc causes this. In this case is it maybe asking for 0x0028 = 40 bytes? I wouldn't bet much money that JEmalloc never modifies its input arguments. That's always allowed in c (as you know) which always passes arguments by value. 0015f198 003b47db 09385800 003d3b55 thunderbird!nsDOMEvent::nsDOMEvent+0x63 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\content\events\src\nsdomevent@136] http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsDOMEvent.cpp Line 132 is in the middle of a comment, so clearly I'm n ot looking at the right source. Below it is a 'new nsEvent'. The sources from which Thunderbird are built come from Mozilla's comm-central repository. I think that line 136 could be either a reference to the line on which the new call itself occurs, or the following line. The versions of the nsdomevent source in which the new call occurs on line 135 are dated 2009-04-02 14:34 -0500 ... 2009-06-30 10:56 +0300 and line 136 from 2009-09-11 16:13 -0700 ... 2009-11-30 13:31 -0500 all of which are over a year old now. See http://hg.mozilla.org/mozilla-central/log/90b17476216d/content/events/src/nsDOMEvent.cpp and http://hg.mozilla.org/mozilla-central/log/d9267e3d8f8c/content/events/src/nsDOMEvent.cpp and http://hg.mozilla.org/mozilla-central/annotate/9e7a2c507c41/content/events/src/nsDOMEvent.cpp#l136 But 'nsEvent' looks like it would take more than 40 bytes. yes. So, skipping down a bit, it looks like something has already gone wrong before this exception is thrown. The app is attempting to show an alert box, which fails because of an out-of-memory condition. Agreed. further back on the stack, we see: nsMsgSendReport::DisplayReport+0x28c nsmsgsendreport@428] nsMsgComposeAndSend::Fail+0x73nsmsgsend@3812] nsMsgComposeAndSend::GatherMimeAttachments+0x113d nsmsgsend@1147] That suggests that the attempt to generate and attach all the attachments failed, and I'd guess that is likely due to Matej's intentional introduction of a failure into C_SignInit. So, C_SignInit failed, and then the attempt to report that failure in an alert pop-up dialog fails due to heap allocation failure, perhaps due to heap exhaustion, or heap corruption. The details are probably not important. Well, I think the big question is: why does the heap allocation fail? You need to track down where the first error occurs. My first wild guess is that Matej's PKCS#11 module is doing something bad to the heap. My second one is that NSS or PSM is trying to free to the MOZCRT17 heap something that was allocated from another heap. How can I check if I am doing something bad to the heap, please? Sadly, I am not so skilled C++ programmer (well, rather a noobish one) and I mostly don't know about the inside stuff you were talking about here... Also, the code for C_SignInit is nearly the same as for C_DecryptInit which works fine. Plus, when I only return non-CKR_OK error code from C_SignInit (and do nothing else in it), it still crashes. I would like to solve this problem very much. If I can be of more help - if you need
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 12/21/2010 06:44 AM, Matej Kurpel wrote: How can I check if I am doing something bad to the heap, please? Sadly, I am not so skilled C++ programmer (well, rather a noobish one) and I mostly don't know about the inside stuff you were talking about here... It's OK, everybody has to debug this problem occasionally. Also, the code for C_SignInit is nearly the same as for C_DecryptInit which works fine. Plus, when I only return non-CKR_OK error code from C_SignInit (and do nothing else in it), it still crashes. 1. Go over all your code again and make sure nothing is writing past the end of the memory you get from new/malloc, or someone else gives to you. Search in your code for 'memcopy' and friends, a bad parameter to those functions can easily cause this. Search for C-style (casts) of pointers and reinterpret_cast. 2. Make sure you don't pass a pointer to some object which remembers it and then delete/free the pointer while that object is still using it. Try simply commenting out everywhere you manually free memory. It will be a memory leak, but you might be able to figure out which one(s) cause the crash that way. 3. See if you can reproduce the problem on Linux. Run it with Valgrind and/or Electric Fence These are similar to PageHeap, often times open source apps will already have a build configuration for that on Linux. 4. Test it with Microsoft's PageHeap tool. There's lots of documentation on it and probably some forums that can help you with that. If that doesn't find it right away, try re-building with the Release Microsoft C Runtime library as discussed. I would like to solve this problem very much. If I can be of more help - if you need more info (or output from some more debugging programs), just ask. You can do it. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-16 19:21 PDT, Marsh Ray wrote: On 12/16/2010 04:39 PM, Matej Kurpel wrote: ChildEBP RetAddr Args to Child 0015f130 5fa0c52b e06d7363 0001 0003 KERNELBASE!RaiseException+0x58 (FPO: [Non-Fpo]) 0015f168 5fa14f13 0015f178 5fa7aa24 5fa5c11c MOZCRT19!_CxxThrowException+0x46 (FPO: [Non-Fpo]) (CONV: stdcall) [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161] So Mozilla builds its own CRT without FPO, cool. Yes, Mozilla builds its own CRT, which is a modified version of the MSVC CRT, whose sources come only with the pay (not free) versions of MSVC. They do this in order to replace MSVC's normal heap code (malloc) with their own JEmalloc. Mozilla's source repository doesn't include ANY of the MSVC source code, but only includes a ed script that patches that source without including any of it. Sadly, this means that people with the free MSVC cannot build MOZCRT19, because they lack the sources to be patched. IMO, this is a flaw for an open source project, but ... :( 0015f180 003b474b 0028 0015f290 5f9ad1d9 MOZCRT19!operator new+0x73 (FPO: [1,3,0]) (CONV: cdecl) The above func must be statically linked from the Mic CRT into the Moz CRT. So it's still FPO. Weird. Right. IIRC, it's built from the plain old MSVC new.cpp source. It calls malloc and throws an exception if malloc returns NULL. [e:\buildbot\win32_build_31\build\objdir-tb\mozilla\memory\jemalloc\crtsrc\new@61] Looking at http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ I don't see the source or crtsrc\new.cpp. Must be copied in from Microsoft source code a build time. Right. In any case, 'operator new' is throwing a C++ exception. Ordinarily that would be due to a bad parameter (e.g., -1) or lack of memory. Right. Any NULL return from malloc causes this. In this case is it maybe asking for 0x0028 = 40 bytes? I wouldn't bet much money that JEmalloc never modifies its input arguments. That's always allowed in c (as you know) which always passes arguments by value. 0015f198 003b47db 09385800 003d3b55 thunderbird!nsDOMEvent::nsDOMEvent+0x63 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\content\events\src\nsdomevent@136] http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsDOMEvent.cpp Line 132 is in the middle of a comment, so clearly I'm n ot looking at the right source. Below it is a 'new nsEvent'. The sources from which Thunderbird are built come from Mozilla's comm-central repository. I think that line 136 could be either a reference to the line on which the new call itself occurs, or the following line. The versions of the nsdomevent source in which the new call occurs on line 135 are dated 2009-04-02 14:34 -0500 ... 2009-06-30 10:56 +0300 and line 136 from 2009-09-11 16:13 -0700 ... 2009-11-30 13:31 -0500 all of which are over a year old now. See http://hg.mozilla.org/mozilla-central/log/90b17476216d/content/events/src/nsDOMEvent.cpp and http://hg.mozilla.org/mozilla-central/log/d9267e3d8f8c/content/events/src/nsDOMEvent.cpp and http://hg.mozilla.org/mozilla-central/annotate/9e7a2c507c41/content/events/src/nsDOMEvent.cpp#l136 But 'nsEvent' looks like it would take more than 40 bytes. yes. So, skipping down a bit, it looks like something has already gone wrong before this exception is thrown. The app is attempting to show an alert box, which fails because of an out-of-memory condition. Agreed. further back on the stack, we see: nsMsgSendReport::DisplayReport+0x28c nsmsgsendreport@428] nsMsgComposeAndSend::Fail+0x73nsmsgsend@3812] nsMsgComposeAndSend::GatherMimeAttachments+0x113d nsmsgsend@1147] That suggests that the attempt to generate and attach all the attachments failed, and I'd guess that is likely due to Matej's intentional introduction of a failure into C_SignInit. So, C_SignInit failed, and then the attempt to report that failure in an alert pop-up dialog fails due to heap allocation failure, perhaps due to heap exhaustion, or heap corruption. The details are probably not important. Well, I think the big question is: why does the heap allocation fail? You need to track down where the first error occurs. My first wild guess is that Matej's PKCS#11 module is doing something bad to the heap. My second one is that NSS or PSM is trying to free to the MOZCRT17 heap something that was allocated from another heap. -- /Nelson Bolyard bnbsp;/b 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 12/19/2010 02:27 AM, Nelson Bolyard wrote: Yes, Mozilla builds its own CRT, which is a modified version of the MSVC CRT, whose sources come only with the pay (not free) versions of MSVC. They do this in order to replace MSVC's normal heap code (malloc) with their own JEmalloc. Mozilla's source repository doesn't include ANY of the MSVC source code, but only includes a ed script that patches that source without including any of it. Sadly, this means that people with the free MSVC cannot build MOZCRT19, because they lack the sources to be patched. IMO, this is a flaw for an open source project, but ... :( Can you build it against the compiler's CRT if you want to? Well, I think the big question is: why does the heap allocation fail? You need to track down where the first error occurs. My first wild guess is that Matej's PKCS#11 module is doing something bad to the heap. Like if Matej's module were linked to some other CRT and an interface passed memory that way. Historically, having multiple CRTs in the same process has been a recipe for disaster on Windows. It's gotten better as Microsoft has switched to using the default global OS heap for everything. Microsoft actually has a pretty decent set of heap debugging tools: http://www.google.com/search?q=pageheap I think this tool was made by their OS development team rather than their Visual dotnet 2000 enterprise team architect edition team. It's much better, much closer to valgrind. But the trick to using it is to get everything using the default OS heap, which means actually using the Release not the Debug Microsoft CRT. Thus JEmalloc would have to be redirected for testing as well, but just to the GlobalAlloc. My second one is that NSS or PSM is trying to free to the MOZCRT17 heap something that was allocated from another heap. Or perhaps vice versa, but wouldn't that likely have thrown at the point of the bad free or delete? - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-19 00:56 PDT, Marsh Ray wrote: On 12/19/2010 02:27 AM, Nelson Bolyard wrote: Yes, Mozilla builds its own CRT, which is a modified version of the MSVC CRT, whose sources come only with the pay (not free) versions of MSVC. They do this in order to replace MSVC's normal heap code (malloc) with their own JEmalloc. Mozilla's source repository doesn't include ANY of the MSVC source code, but only includes a ed script that patches that source without including any of it. Sadly, this means that people with the free MSVC cannot build MOZCRT19, because they lack the sources to be patched. IMO, this is a flaw for an open source project, but ... :( Can you build it against the compiler's CRT if you want to? Not that I'm aware. But I've never tried. Well, I think the big question is: why does the heap allocation fail? You need to track down where the first error occurs. My first wild guess is that Matej's PKCS#11 module is doing something bad to the heap. Like if Matej's module were linked to some other CRT and an interface passed memory that way. Historically, having multiple CRTs in the same process has been a recipe for disaster on Windows. I was thinking of allocating a buffer of size N and then writing past the end of it. That's the most common problem, IMO. My second one is that NSS or PSM is trying to free to the MOZCRT17 heap something that was allocated from another heap. Or perhaps vice versa, but wouldn't that likely have thrown at the point of the bad free or delete? Not clear. The debug CRT would catch such thing at free/delete time, but not clear that any other CRT would do so. Actually, in retrospect, I think it's doubtful that this second guess is the problem, because the PKCS#11 API doesn't ever pass allocated memory from one side of the API to the other, for the receiving side to deallocate. Generally, the process using the module allocates all memory, and frees what it allocated. It asks the PKCS#11 module to take data from, or put data into, the memory it supplies, but the module should never free memory passed in to it, and never outputs the addresses of memory that it has allocated. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-11 11:57 PDT, Matej Kurpel wrote: Ah, that's because I tried CKR_FUNCTION_NOT_SUPPORTED then and copied the wrong pkcs log. But that's not really the point since it crashes everytime, no matter which CKR_ return code I use (apart from CKR_OK) from the ones allowed by the pkcs11 specification. So, you're a developer, developing code to run on windows. I suspect you must have a windows compiler/debugger, such as a free MSVC version. The next step is to use it to get a stack trace of the crash. Even if you don't have full sources, you can still use Mozilla's symbol server to provide the symbols for your stack. Point your debugger's symbols client at http://symbols.mozilla.org/firefox -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 16. 12. 2010 14:02, Nelson Bolyard wrote: On 2010-12-11 11:57 PDT, Matej Kurpel wrote: Ah, that's because I tried CKR_FUNCTION_NOT_SUPPORTED then and copied the wrong pkcs log. But that's not really the point since it crashes everytime, no matter which CKR_ return code I use (apart from CKR_OK) from the ones allowed by the pkcs11 specification. So, you're a developer, developing code to run on windows. I suspect you must have a windows compiler/debugger, such as a free MSVC version. The next step is to use it to get a stack trace of the crash. Even if you don't have full sources, you can still use Mozilla's symbol server to provide the symbols for your stack. Point your debugger's symbols client athttp://symbols.mozilla.org/firefox I have installed the debug package for Windows where WinDbg resides (I didn't have it installed previously). I have set up the symbols url as shown on the web page (with /thunderbird and not /firefox at the end since with /firefox it said it couldn't load the symbols when debugging TB). Then I attached the debugger to a new Thunderbird session. I caused the crash and saw this in the Command window: (164c.1560): C++ EH exception - code e06d7363 (first chance) (164c.1560): C++ EH exception - code e06d7363 (!!! second chance !!!) KERNELBASE!RaiseException+0x58: 7675b727 c9 leave 0:000:x86 g WARNING: Continuing a non-continuable exception (164c.1560): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. thunderbird!XPCWrappedNative::FinishInit+0x34: 01199547 f60102 testbyte ptr [ecx],2 ds:002b:00090109=?? When pressing F5, the access violation always repeated. And in the Calls window (I guess this is the stack trace you were writing about): # ChildEBP RetAddr Args to Child 00 0027e3f8 01199e98 0027e92c 019f721c 6b882629 thunderbird!XPCWrappedNative::FinishInit(class XPCCallContext * ccx = 0x0119b8ac)+0x34 (FPO: [1,0,0]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 1191] 01 0027e410 0119b8ac 0027e92c 05f5f0c0 thunderbird!XPCWrappedNative::Init(class XPCCallContext * ccx = 0x0027e92c, struct JSObject * parent = 0x05f5f0c0, int isGlobal = 0n0, class XPCNativeScriptableCreateInfo * sci = 0x0027e4a4)+0xeb (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 1141] 02 0027e4c8 0119da26 0027e92c 08d93ce4 05f5b640 thunderbird!XPCWrappedNative::GetNewOrUsed(class XPCCallContext * ccx = 0x0027e92c, class nsISupports * Object = 0x08d93ce4, class XPCWrappedNativeScope * Scope = 0x05f5b640, class XPCNativeInterface * Interface = 0x0a7efee0, class nsWrapperCache * cache = 0x, int isGlobal = 0n0, class XPCWrappedNative ** resultWrapper = 0x0027e54c)+0x60c (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 571] 03 0027e550 0119e4fd 0027e5c8 0027e794 thunderbird!XPCConvert::NativeInterface2JSObject(class XPCLazyCallContext * lccx = 0x0027e5c8, int * d = 0x0027e794, class nsIXPConnectJSObjectHolder ** dest = 0x, class nsISupports * src = 0x08d93ce4, struct nsID * iid = 0x0027e858, class XPCNativeInterface ** Interface = 0x, class nsWrapperCache * cache = 0x, struct JSObject * scope = 0x08d9ddc0, int allowNativeWrapper = 0n1, int isGlobal = 0n0, unsigned int * pErr = 0x0027e77c)+0x199 (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcconvert.cpp @ 1199] 04 0027e594 0119849b 0027e5c8 0027e794 0027e6c4 thunderbird!XPCConvert::NativeData2JS(class XPCLazyCallContext * lccx = 0x0027e5c8, int * d = 0x0027e794, void * s = 0x0027e6c4, class nsXPTType * type = 0x0027e79f, struct nsID * iid = 0x0027e858, struct JSObject * scope = 0x08d9ddc0, unsigned int * pErr = 0x0027e77c)+0x314 (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcconvert.cpp @ 471] 05 0027e684 0119abbf 0027e92c 0027e794 0027e6c4 thunderbird!XPCConvert::NativeData2JS(class XPCCallContext * ccx = 0x0027e92c, int * d = 0x0027e794, void * s = 0x0027e6c4, class nsXPTType * type = 0x0027e79f, struct nsID * iid = 0x0027e858, struct JSObject * scope = 0x08d9ddc0, unsigned int * pErr = 0x0027e77c)+0x4c (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcprivate.h @ 2985] 06 0027e900 011a122b 0027e92c 00a83c00 thunderbird!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x0027e92c, XPCWrappedNative::CallMode mode = CALL_METHOD (0n0))+0xcec (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 2810] 07 0027e9c4 6ba05afd 00a83c00 08d9ddc0 0001 thunderbird!XPC_WN_CallMethod(struct
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 12/16/2010 01:02 PM, Matej Kurpel wrote: (164c.1560): C++ EH exception - code e06d7363 (first chance) Nelson may know more specifics, but if I were you I would configure the debugger to break when C++ exceptions are thrown. (Debug menu - Event filters) When it break here, type kv100 to get the stack trace. (164c.1560): C++ EH exception - code e06d7363 (!!! second chance !!!) KERNELBASE!RaiseException+0x58: 7675b727 c9 leave 0:000:x86 g WARNING: Continuing a non-continuable exception (164c.1560): Access violation - code c005 (first chance) Just a guess - are you catching a C++ then ignoring it, leaving some dangling pointer somewhere? - Marsh # ChildEBP RetAddr Args to Child 00 0027e3f8 01199e98 0027e92c 019f721c 6b882629 thunderbird!XPCWrappedNative::FinishInit(class XPCCallContext * ccx = 0x0119b8ac)+0x34 (FPO: [1,0,0]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 1191] 01 0027e410 0119b8ac 0027e92c 05f5f0c0 thunderbird!XPCWrappedNative::Init(class XPCCallContext * ccx = 0x0027e92c, struct JSObject * parent = 0x05f5f0c0, int isGlobal = 0n0, class XPCNativeScriptableCreateInfo * sci = 0x0027e4a4)+0xeb (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 1141] 02 0027e4c8 0119da26 0027e92c 08d93ce4 05f5b640 thunderbird!XPCWrappedNative::GetNewOrUsed(class XPCCallContext * ccx = 0x0027e92c, class nsISupports * Object = 0x08d93ce4, class XPCWrappedNativeScope * Scope = 0x05f5b640, class XPCNativeInterface * Interface = 0x0a7efee0, class nsWrapperCache * cache = 0x, int isGlobal = 0n0, class XPCWrappedNative ** resultWrapper = 0x0027e54c)+0x60c (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 571] 03 0027e550 0119e4fd 0027e5c8 0027e794 thunderbird!XPCConvert::NativeInterface2JSObject(class XPCLazyCallContext * lccx = 0x0027e5c8, int * d = 0x0027e794, class nsIXPConnectJSObjectHolder ** dest = 0x, class nsISupports * src = 0x08d93ce4, struct nsID * iid = 0x0027e858, class XPCNativeInterface ** Interface = 0x, class nsWrapperCache * cache = 0x, struct JSObject * scope = 0x08d9ddc0, int allowNativeWrapper = 0n1, int isGlobal = 0n0, unsigned int * pErr = 0x0027e77c)+0x199 (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcconvert.cpp @ 1199] 04 0027e594 0119849b 0027e5c8 0027e794 0027e6c4 thunderbird!XPCConvert::NativeData2JS(class XPCLazyCallContext * lccx = 0x0027e5c8, int * d = 0x0027e794, void * s = 0x0027e6c4, class nsXPTType * type = 0x0027e79f, struct nsID * iid = 0x0027e858, struct JSObject * scope = 0x08d9ddc0, unsigned int * pErr = 0x0027e77c)+0x314 (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcconvert.cpp @ 471] 05 0027e684 0119abbf 0027e92c 0027e794 0027e6c4 thunderbird!XPCConvert::NativeData2JS(class XPCCallContext * ccx = 0x0027e92c, int * d = 0x0027e794, void * s = 0x0027e6c4, class nsXPTType * type = 0x0027e79f, struct nsID * iid = 0x0027e858, struct JSObject * scope = 0x08d9ddc0, unsigned int * pErr = 0x0027e77c)+0x4c (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcprivate.h @ 2985] 06 0027e900 011a122b 0027e92c 00a83c00 thunderbird!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x0027e92c, XPCWrappedNative::CallMode mode = CALL_METHOD (0n0))+0xcec (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 2810] 07 0027e9c4 6ba05afd 00a83c00 08d9ddc0 0001 thunderbird!XPC_WN_CallMethod(struct JSContext * cx = 0x00a83c00, struct JSObject * obj = 0x08d9ddc0, unsigned int argc = 1, int * argv = 0x00a6351c, int * vp = 0x0027ea3c)+0xfa (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp @ 1740] 08 0027ea68 6ba0af9e 00a83c00 0001 00a63514 js3250!js_Invoke(struct JSContext * cx = 0x00a83c00, unsigned int argc = 1, int * vp = 0x00a63514, unsigned int flags = 2)+0x48d (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\jsinterp.cpp @ 1360] 09 0027ebf4 6ba05b08 00a83c00 0027ef08 js3250!js_Interpret(struct JSContext * cx = 0x00a83c00)+0x456e (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\jsops.cpp @ 2241] 0a 0027ec88 011d5f59 00a83c00 0003 00a63480 js3250!js_Invoke(struct JSContext * cx = 0x00a83c00, unsigned int argc = 3, int * vp = 0x00a63480, unsigned int flags = 0)+0x498 (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\js\src\jsinterp.cpp @ 1368] 0b 0027eebc 011d2812 046f4850 060c1ac0 0003 thunderbird!nsXPCWrappedJSClass::CallMethod(class nsXPCWrappedJS * wrapper = 0x060c1ac0, unsigned short methodIndex = 3, struct XPTMethodDescriptor * info = 0x04680460, struct nsXPTCMiniVariant * nativeParams =
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 16. 12. 2010 21:59, Marsh Ray wrote: On 12/16/2010 01:02 PM, Matej Kurpel wrote: (164c.1560): C++ EH exception - code e06d7363 (first chance) Nelson may know more specifics, but if I were you I would configure the debugger to break when C++ exceptions are thrown. (Debug menu - Event filters) When it break here, type kv100 to get the stack trace. The full listing of Command window is as follows: Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe Symbol search path is: SRV*c:\symcache\*http://msdl.microsoft.com/download/symbols;SRV*c:\symcache\*http://symbols.mozilla.org/firefox;SRV*c:\symcache\*http://symbols.mozilla.org/thunderbird Executable search path is: ModLoad: `0016 `00d7c000 thunderbird.exe ModLoad: `77ab `77c5b000 ntdll.dll ModLoad: `77c9 `77e1 ntdll32.dll ModLoad: `756d `7570f000 C:\Windows\SYSTEM32\wow64.dll ModLoad: `7567 `756cc000 C:\Windows\SYSTEM32\wow64win.dll ModLoad: `7566 `75668000 C:\Windows\SYSTEM32\wow64cpu.dll (1120.11b0): Break instruction exception - code 8003 (first chance) ntdll!LdrpDoDebuggerBreak+0x30: `77b61340 cc int 3 0:000 g ModLoad: `7789 `779af000 WOW64_IMAGE_SECTION ModLoad: `7662 `7672 WOW64_IMAGE_SECTION ModLoad: `7789 `779af000 NOT_AN_IMAGE ModLoad: `779b `77aaa000 NOT_AN_IMAGE ModLoad: `7662 `7672 C:\Windows\syswow64\kernel32.dll ModLoad: `7675 `76796000 C:\Windows\syswow64\KERNELBASE.dll ModLoad: `5fa9 `5fb61000 C:\Program Files (x86)\Mozilla Thunderbird\js3250.dll ModLoad: `6bf6 `6bf8a000 C:\Program Files (x86)\Mozilla Thunderbird\nspr4.dll ModLoad: `762c `7636 C:\Windows\syswow64\ADVAPI32.dll ModLoad: `7621 `762bc000 C:\Windows\syswow64\msvcrt.dll ModLoad: `7776 `9000 C:\Windows\SysWOW64\sechost.dll ModLoad: `7586 `7595 C:\Windows\syswow64\RPCRT4.dll ModLoad: `7580 `7586 C:\Windows\syswow64\SspiCli.dll ModLoad: `757f `757fc000 C:\Windows\syswow64\CRYPTBASE.dll ModLoad: `734f `734f7000 C:\Windows\SysWOW64\WSOCK32.dll ModLoad: `75b8 `75bb5000 C:\Windows\syswow64\WS2_32.dll ModLoad: `7648 `76486000 C:\Windows\syswow64\NSI.dll ModLoad: `719d `71a02000 C:\Windows\SysWOW64\WINMM.dll ModLoad: `7652 `7662 C:\Windows\syswow64\USER32.dll ModLoad: `7780 `7789 C:\Windows\syswow64\GDI32.dll ModLoad: `7637 `7637a000 C:\Windows\syswow64\LPK.dll ModLoad: `763d `7646d000 C:\Windows\syswow64\USP10.dll ModLoad: `5f9e `5fa9 C:\Program Files (x86)\Mozilla Thunderbird\MOZCRT19.dll ModLoad: `5f97 `5f9d5000 C:\Program Files (x86)\Mozilla Thunderbird\xpcom_core.dll ModLoad: `6d47 `6d477000 C:\Program Files (x86)\Mozilla Thunderbird\plc4.dll ModLoad: `6c85 `6c857000 C:\Program Files (x86)\Mozilla Thunderbird\plds4.dll ModLoad: `767a `773e9000 C:\Windows\syswow64\SHELL32.dll ModLoad: `7600 `76057000 C:\Windows\syswow64\SHLWAPI.dll ModLoad: `7745 `775ac000 C:\Windows\syswow64\ole32.dll ModLoad: `7561 `75619000 C:\Windows\SysWOW64\VERSION.dll ModLoad: `6b4b `6b4c8000 C:\Program Files (x86)\Mozilla Thunderbird\smime3.dll ModLoad: `5f8d `5f96d000 C:\Program Files (x86)\Mozilla Thunderbird\nss3.dll ModLoad: `6b49 `6b4a4000 C:\Program Files (x86)\Mozilla Thunderbird\nssutil3.dll ModLoad: `6b34 `6b361000 C:\Program Files (x86)\Mozilla Thunderbird\ssl3.dll ModLoad: `1000 `10027000 C:\Program Files (x86)\Mozilla Thunderbird\NSLDAP32V60.dll ModLoad: `0002 `00027000 C:\Program Files (x86)\Mozilla Thunderbird\NSLDAPPR32V60.dll ModLoad: `5f85 `5f8cb000 C:\Program Files (x86)\Mozilla Thunderbird\sqlite3.dll ModLoad: `7778 `777fb000 C:\Windows\syswow64\COMDLG32.dll ModLoad: `73b2 `73cbe000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_420fe3fa2b8113bd\COMCTL32.dll ModLoad: `776d `7775f000 C:\Windows\syswow64\OLEAUT32.dll ModLoad: `73ac `73b11000 C:\Windows\SysWOW64\WINSPOOL.DRV
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 12/16/2010 04:39 PM, Matej Kurpel wrote: ChildEBP RetAddr Args to Child 0015f130 5fa0c52b e06d7363 0001 0003 KERNELBASE!RaiseException+0x58 (FPO: [Non-Fpo]) 0015f168 5fa14f13 0015f178 5fa7aa24 5fa5c11c MOZCRT19!_CxxThrowException+0x46 (FPO: [Non-Fpo]) (CONV: stdcall) [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161] So Mozilla builds its own CRT without FPO, cool. 0015f180 003b474b 0028 0015f290 5f9ad1d9 MOZCRT19!operator new+0x73 (FPO: [1,3,0]) (CONV: cdecl) The above func must be statically linked from the Mic CRT into the Moz CRT. So it's still FPO. Weird. [e:\buildbot\win32_build_31\build\objdir-tb\mozilla\memory\jemalloc\crtsrc\new.cpp @ 61] Looking at http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ I don't see the source or crtsrc\new.cpp. Must be copied in from Microsoft source code a build time. In any case, 'operator new' is throwing a C++ exception. Ordinarily that would be due to a bad parameter (e.g., -1) or lack of memory. In this case is it maybe asking for 0x0028 = 40 bytes? 0015f198 003b47db 09385800 003d3b55 thunderbird!nsDOMEvent::nsDOMEvent+0x63 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\content\events\src\nsdomevent.cpp @ 136] http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsDOMEvent.cpp Line 132 is in the middle of a comment, so clearly I'm n ot looking at the right source. Below it is a 'new nsEvent'. But 'nsEvent' looks like it would take more than 40 bytes. 0015f1a4 003d3b55 0015f2b4 09385800 thunderbird!NS_NewDOMEvent+0x1b (FPO: [3,0,0]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\content\events\src\nsdomevent.cpp @ 1529] 0015f1c4 00346b83 09385800 0015f290 thunderbird!nsEventDispatcher::CreateEvent+0x4b1 (FPO: [Non-Fpo]) (CONV: cdecl) [e:\buildbot\win32_build_31\build\mozilla\content\events\src\nseventdispatcher.cpp @ 733] 0015f1dc 006481f1 093854a4 0015f290 0015f2b4 thunderbird!nsDocument::CreateEvent+0x3b (FPO: [3,0,4]) (CONV: stdcall) [e:\buildbot\win32_build_31\build\mozilla\content\base\src\nsdocument.cpp @ 6337] 0015f2b8 0064829a 00b1edac 0015f5a0 5f972629 thunderbird!nsAutoWindowStateHelper::DispatchCustomEvent+0x83 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nsautowindowstatehelper.cpp @ 98] 0015f2cc 006382c8 02942940 5f972629 8000 thunderbird!nsAutoWindowStateHelper::nsAutoWindowStateHelper+0x16 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nsautowindowstatehelper.cpp @ 56] 0015f500 006386a1 02942940 00b1e844 00970bd0 thunderbird!nsWindowWatcher::OpenWindowJSInternal+0x10e1 (FPO: [Non-Fpo]) (CONV: thiscall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nswindowwatcher.cpp @ 998] 0015f560 00645220 0393a460 02942940 00b1e844 thunderbird!nsWindowWatcher::OpenWindow+0x1e7 (FPO: [Non-Fpo]) (CONV: stdcall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nswindowwatcher.cpp @ 425] 0015f594 0064544c 0a5b4380 0a5c7300 thunderbird!nsPromptService::DoDialog+0x7c (FPO: [Non-Fpo]) (CONV: stdcall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nspromptservice.cpp @ 797] 0015f688 00647388 04b67660 02942940 0a5c66a0 thunderbird!nsPromptService::Alert+0x189 (FPO: [Non-Fpo]) (CONV: stdcall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nspromptservice.cpp @ 148] 0015f69c 008515c7 0a5c23a0 0a5c66a0 0a125268 thunderbird!nsPrompt::Alert+0x19 (FPO: [3,0,0]) (CONV: stdcall) [e:\buildbot\win32_build_31\build\mozilla\embedding\components\windowwatcher\src\nsprompt.cpp @ 199] So, skipping down a bit, it looks like something has already gone wrong before this exception is thrown. The app is attempting to show an alert box, which fails because of an out-of-memory condition. The details are probably not important. You need to track down where the first error occurs. Is there a logging subsystem that can tell you what the alert was? - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
Matej,
Your message contains an obvious self-contradiction. Observe:
On 2010-12-10 09:57 PDT, Matej Kurpel wrote:
CK_RV CK_ENTRY C_SignInit(CK_SESSION_HANDLE hSession, CK_MECHANISM_PTR
pMechanism, CK_OBJECT_HANDLE hKey)
{
return CKR_FUNCTION_CANCELED;
}
89: C_SignInit
[in] hSession = 0x2
pMechanism-type=CKM_RSA_PKCS
[in] hKey = 0x2
Returned: 84 CKR_FUNCTION_NOT_SUPPORTED
Are you perhaps not testing with your own latest builds, or something?
--
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 11. 12. 2010 19:05, Nelson B Bolyard wrote:
Matej,
Your message contains an obvious self-contradiction. Observe:
On 2010-12-10 09:57 PDT, Matej Kurpel wrote:
CK_RV CK_ENTRY C_SignInit(CK_SESSION_HANDLE hSession, CK_MECHANISM_PTR
pMechanism, CK_OBJECT_HANDLE hKey)
{
return CKR_FUNCTION_CANCELED;
}
89: C_SignInit
[in] hSession = 0x2
pMechanism-type=CKM_RSA_PKCS
[in] hKey = 0x2
Returned: 84 CKR_FUNCTION_NOT_SUPPORTED
Are you perhaps not testing with your own latest builds, or something?
Ah, that's because I tried CKR_FUNCTION_NOT_SUPPORTED then and copied
the wrong pkcs log. But that's not really the point since it crashes
everytime, no matter which CKR_ return code I use (apart from CKR_OK)
from the ones allowed by the pkcs11 specification.
M. Kurpel
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Thunderbird crashing when C_SignInit returns other than CKR_OK
Hello,
I am implementing a PKCS#11 module. I would like to implement
authentication on my device (using a pin-pad) everytime a signature is
requested from it. The idea is that on C_SignInit, I ask the user for
the PIN and if the PIN is incorrect (or user has cancelled for whatever
reason), it should return CKR_FUNCTION_CANCELED.
Now I am facing a problem with Thunderbird. I choose to compose a new
message and let it be signed (of course, I provide an invalid PIN to my
device deliberately). The first time Thunderbird just pops up an error
message that it was unable to sign - and that is fine. However, when I
try to send the message again (and it is going to get signed again),
Thunderbird crashes/acts in a weird way. Sometimes it wants to send a
bug report to Mozilla, but most of the time it ends up with a C++
runtime error and an empty little window behind the error message
(screenshot 2). Sometimes it hangs on Creating mail message... (with
the progress bar moving) and a little empty window behind it (screenshot 1).
Screenshot 1: http://img6.glowfoto.com/images/2010/12/10-0954327898L.png
Screenshot 2: http://img4.glowfoto.com/images/2010/12/10-1150202661L.png
I have eliminated bugs on my side by returning CKR_FUNCTION_CANCELED
straight from my DLL module as follows:
CK_RV CK_ENTRY C_SignInit(CK_SESSION_HANDLE hSession, CK_MECHANISM_PTR
pMechanism, CK_OBJECT_HANDLE hKey)
{
return CKR_FUNCTION_CANCELED;
}
In my pkcs11spy-log everything looks normal (as when it's working):
88: C_OpenSession
[in] slotID = 0x0
[in] flags = 0x4
pApplication=065F4000
Notify=6004A378
[out] *phSession = 0x2
Returned: 0 CKR_OK
89: C_SignInit
[in] hSession = 0x2
pMechanism-type=CKM_RSA_PKCS
[in] hKey = 0x2
Returned: 84 CKR_FUNCTION_NOT_SUPPORTED
90: C_CloseSession
[in] hSession = 0x2
Returned: 0 CKR_OK
Before this, I tried to do the same in C_Sign (not C_SignInit) but it
crashed as well. I thought that I did it wrong and it should be right in
C_SignInit but it seems I was wrong again.
Looks like a bug in Thunderbird to me, but if anyone has any ideas on
how to circumvent it (or maybe I am doing a mistake somewhere), please
let me know. Thanks in advance.
M. Kurpel
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
