Resending Matej's message, reduced to the essential stack. On 2010-12-16 14:39 PDT, Matej Kurpel wrote: > On 16. 12. 2010 21:59, Marsh Ray wrote:
>> 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. [snip] > After typing kv100 as you suggested, this listing was output: > > RaiseException+0x58 > _CxxThrowException+0x46 throw....@161] > operator new+0x73 new....@61] > nsDOMEvent::nsDOMEvent+0x63 nsdomevent....@136] > NS_NewDOMEvent+0x1b nsdomevent....@1529] > nsEventDispatcher::CreateEvent+0x4b1 nseventdispatcher....@733] > nsDocument::CreateEvent+0x3b nsdocument....@6337] > nsAutoWindowStateHelper::DispatchCustomEvent+0x83 > nsautowindowstatehelper....@98] > nsAutoWindowStateHelper::nsAutoWindowStateHelper+0x16 > nsautowindowstatehelper....@56] > nsWindowWatcher::OpenWindowJSInternal+0x10e1 nswindowwatcher....@998] > nsWindowWatcher::OpenWindow+0x1e7 nswindowwatcher....@425] > nsPromptService::DoDialog+0x7c nspromptservice....@797] > nsPromptService::Alert+0x189 nspromptservice....@148] > nsPrompt::Alert+0x19 nsprompt....@199] > nsMsgDisplayMessageByString+0x6d nsmsgprompts....@124] > nsMsgSendReport::DisplayReport+0x28c nsmsgsendreport....@428] > nsMsgComposeAndSend::Fail+0x73 nsmsgsend....@3812] > nsMsgComposeAndSend::GatherMimeAttachments+0x113d nsmsgsend....@1147] > nsMsgAttachmentHandler::UrlExit+0x7ce nsmsgattachmenthandler....@1315] > FetcherURLDoneCallback+0x6d nsmsgattachmenthandler....@534] > nsURLFetcher::OnStopRequest+0x97 nsurlfetcher....@327] > nsDocumentOpenInfo::OnStopRequest+0x40 nsuriloader....@324] > nsBaseChannel::OnStopRequest+0x43 nsbasechannel....@681] > nsInputStreamPump::OnStateStop+0x55 nsinputstreampump....@579] > nsInputStreamPump::OnInputStreamReady+0x2a nsinputstreampump....@404] > xpcom_nsOutputStreamReadyEvent::Run+0x1c nsstreamutils....@113] > xpcom_nsThread::ProcessNextEvent+0xc5 nsthread....@527] > xpcom_NS_ProcessNextEvent_P+0x20 nsthreadutils....@250] > nsBaseAppShell::Run+0x2a nsbaseappshell....@177] > nsAppStartup::Run+0x1e nsappstartup....@184] > XRE_main+0x14f8 t nsapprunner....@3485] > NS_internal_main+0xbe nsmailapp....@102] > wmain+0xf3 nswindowswmain....@122] > __tmainCRTStartup+0x152 crtex...@591] > BaseThreadInitThunk+0xe > __RtlUserThreadStart+0x70 > _RtlUserThreadStart+0x1b >>> (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 c0000005 (first chance) >> Just a guess - are you catching a C++ then ignoring it, leaving some >> dangling pointer somewhere? > I am not doing anything with the source code :). I am using the latest > stock version of TB, but I am developing a PKCS#11 module to be used > with TB, and it looks like TB cannot handle return values other than > CKR_OK from C_SignInit properly (however, in C_DecryptInit it doesn't > crash and everything is working). >> - Marsh -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
