User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.65 Safari/534.24 Steps to reproduce: tried again Actual results: its crashed again Expected results: should have worked
Can you give us the crash ID ? (see http://support.mozillamessaging.com/bg/kb/Mozilla-Crash-Reporter)
This is OOM.
bp-9e5c74b7-a016-467b-9e87-acdb92110920 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:78 1 mozalloc.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:54 2 mozalloc.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:102 3 xul.dll nsLocalFile::Clone xpcom/io/nsLocalFileWin.cpp:842 4 xul.dll nsDirectoryService::Get xpcom/io/nsDirectoryService.cpp:431 5 xul.dll nsPrefBranch::GetComplexValue modules/libpref/src/nsPrefBranch.cpp:310 6 xul.dll nsMsgIncomingServer::GetFileValue mailnews/base/util/nsMsgIncomingServer.cpp:474 7 xul.dll nsMsgIncomingServer::GetLocalPath mailnews/base/util/nsMsgIncomingServer.cpp:936 8 xul.dll nsMsgDBFolder::parseURI mailnews/base/util/nsMsgDBFolder.cpp:3194 9 xul.dll nsMsgDBFolder::GetFilePath mailnews/base/util/nsMsgDBFolder.cpp:4668 10 xul.dll nsMsgDBFolder::GetFolderCacheKey mailnews/base/util/nsMsgDBFolder.cpp:1282 11 xul.dll nsMsgDBFolder::ReadDBFolderInfo mailnews/base/util/nsMsgDBFolder.cpp:650 12 xul.dll nsMsgDBFolder::SetFlag mailnews/base/util/nsMsgDBFolder.cpp:4217 13 xul.dll nsMsgIdentity::setFolderPref mailnews/base/util/nsMsgIdentity.cpp:421 14 xul.dll nsMsgIdentity::getFolderPref mailnews/base/util/nsMsgIdentity.cpp:328 15 xul.dll nsMsgIdentity::GetFccFolder mailnews/base/util/nsMsgIdentity.cpp:190 16 xul.dll GetFolderURIFromUserPrefs mailnews/compose/src/nsMsgCompUtils.cpp:1994 17 xul.dll nsMsgComposeAndSend::InitCompositionFields mailnews/compose/src/nsMsgSend.cpp:2923 18 xul.dll nsMsgComposeAndSend::Init mailnews/compose/src/nsMsgSend.cpp:3405 19 xul.dll nsMsgComposeAndSend::CreateAndSendMessage mailnews/compose/src/nsMsgSend.cpp:4285
Note that the two crash reports: https://crash-stats.mozilla.com/report/index/1318c415-194c-4ef1-a5e5-008e22110920 and https://crash-stats.mozilla.com/report/index/9e5c74b7-a016-467b-9e87-acdb92110920 occur when importing from different sources: the first one is from Outlook Express, while the second is from Outlook. These may be the same problem in some core module, or two different bugs in the respective import modules. Anyway, it would be helpful fo get the message that causes the crash. (Personally I could try to asist in tracking this problem in Outlook.) Unfortunately, I cannot suggest any other method but to create a new folder in Outlook, that would be named alphabetically prior to the crashing one, and try to move there some messages until you find the problem mail. If you will succeed, then please save that mail as .MSG file, and attach it here. I think that some similar approach could be used to find the offending message in OE.
There are also people importing and crashing with mozalloc_abort(char const* const) | mozalloc_handle_oom() | moz_xmalloc with nsLocalFile::nsLocalFileConstructor or something similar in the stack, ref: bug 613439, bug 609039 for example bp-3b20798b-9945-4467-b723-7951a2110828 (allan) bp-ad9a2b4b-49f2-4514-957c-4c2092110905 bp-44a6f5f7-cf77-4f10-a401-4cb492110906 bp-c54ee284-a8fa-480e-9844-dde542110829
another exemple on Thunderbird 7 and Win7: https://crash-stats.mozilla.com/report/index/d4d329df-242c-4f10-9ce8-262332111018 I don't know why its crash report is not linked to this bug report...
*Note: this crash is #1 outlook issue in getsatisfaction* as far as I can tell (In reply to caméléon from comment #6) > another exemple on Thunderbird 7 and Win7: > https://crash-stats.mozilla.com/report/index/d4d329df-242c-4f10-9ce8- > 262332111018 > I don't know why its crash report is not linked to this bug report... This is Hugues' crash reported at http://getsatisfaction.com/mozilla_messaging/topics/crash_when_import_mail_from_outllok#reply_6925948 and has a different signature mozalloc_abort(char const* const) | mozalloc_handle_oom() | moz_xmalloc | nsLocalFile::nsLocalFileConstructor(nsISupports*, nsID const&, void**)
Created attachment 572809 [details] [bug] MSG that triggers the crash; it cannot be imported from Outlook I identified which message caused ThunderBird to crash during import of messages from Outlook. When I deleted this message, all imports went well.
Could you please attach the message as MS Outlook .MSG file (or a .ZIP containing the message file).
(In reply to Jorg K from comment #9) > Could you please attach the message as MS Outlook .MSG file (or a .ZIP > containing the message file). This appears to be a correct .MSG file, but its MIME type chosen improperly (text/plain). When downloaded using some descent download manager, it opens in Outlook correctly, and does cause crash. I am going to try to debug this shortly.
Created attachment 573094 [details] [diff] [review] Fix improper unescape guard; fix double release of an interface Hugues, thank you very much for your sample. I found the cause of this error. This patch should fix this.
I don't have access to Outlook 2007, and I didn't crash with Outlook 2010, after dragging the .msf file into Outlook. So I'm at a bit of a loss as to how to verify this fix. Any ideas? Also, you shouldn't just comment out the tmp file lines. They should simply be removed. Or, I think it might make more sense to simply null out tmp_file, after releasing it, i.e., (*tmp_file)->Release(); *tmp_file = 0; that would prevent the caller from being able to release it, I think.
sorry, that should read "dragging the .msg file into Outlook 2010" Perhaps a pst file from Outlook 2007 with the msg(s) would cause the crash w/ Outlook 2010?
I use Outlook 2010 now, and importing the message from it does cause the crash. (Well, I don't know why, but first time I tried, my TB didn't crash, too, but after restarting both Outlook and TB, the crash on my system is guaranteed.) I'll post updated patch when I'll be at development PC. I think that the second option is more correct and clear.
My 8.0 shipping build does crash in import, but my trunk debug build doesn't. I'll see if a trunk release build crashes...
Comment on attachment 573094 [details] [diff] [review] Fix improper unescape guard; fix double release of an interface minusing while a new patch addressing comments is prepared. The Check() change looks OK to me, even if I can't recreate the crash in a version I build...
Created attachment 574000 [details] [diff] [review] Addressing David's comments
Comment on attachment 574000 [details] [diff] [review] Addressing David's comments thx, Mike.