Closed Bug 480781 Opened 17 years ago Closed 17 years ago

Eudora 8.0b5 crashes very frequently [@ nsCharTraits<unsigned short>::length - fakeCString]

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: davofanmail, Unassigned)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(1 file)

testcase
454 bytes, message/rfc822
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) Build Identifier: Eudora 8.0.0b5 The new Eudora (beta 5) is very nice (installed it over pre-existing b4) but it crashes 100% of the time on a suspend/resume cycle. For some reason, doesn't seem to crash on hibernate/resume cycle. Reproducible: Always
Assignee: nobody → mozilla-bugs
Product: Thunderbird → Penelope
QA Contact: general → general
Actually, I overstated -- this doesn't happen 100% of the time. I'm trying to figure out what the conditions are that trigger the crashes.
OK, it seems that what causes the crashing is any time I lose my network connection. It is 100% reproducible (at least on my machine), with no add-ons enabled (including Eudora), or with all of them enabled.
OK, have been able, apparently, to work around this one. The work-around involves removing all your email accounts, re-establishing them, removing all the Local Folders files, rebuilding the folder structure, and then replacing all the folders and files with backed-up copies. I was able to get much more detail on the symptom after crashing Eudora >100 times: - if Eudora were put in offline mode, it would do fine and stay up. - the moment it was put in online mode, the CPU utilization and I/O traffic would go way up, and within 20 CPU seconds and 25,000 I/Os it would fail every time. Evidently there was something messy in my folder organization or prefs.js file that all previous versions could handle no prob -- but blew up in Beta 5.
Summary: Eudora crashes on every suspend/resume cycle → Eudora 8.0b5 crashes very frequently
Whoops, spoke to soon. Eudora had been running fine for a few hours...I changed *nothing* and now it won't stay up for more than 10 seconds unless I push it into offline mode. If it's online, Eudora crashes almost instantly.
Maybe this has been resolved. I reinstalled Eudora B5 and removed (archived) some of the larger mail folders. This made it stop crashing when online. I then let it run for 6 hours. Then, I re-introduced the large mailboxes gradually, adding them back every few minutes. Now Eudora seems to be working normally.
This too sounds like its due to background indexing. There was probably a particular message that was giving indexing a problem and made it crash. This wouldn't be a bug specific to Eudora, but would affect Thunderbird as well, so I'm switching it over to that. If you run in to any more bugs in the future, it's helpful if you also try the same scenario out on the matching version of Thunderbird (for Eudora 8 beta 5, then matching TB version is 3.0 beta 1), which is listed in Eudora's release notes or you can see at the end of the long Mozilla version string in the Help->About dialog. That way you can report the bug to the appropriate place. Thanks for testing out the betas!
Assignee: mozilla-bugs → nobody
Component: General → Search
Product: Penelope → MailNews Core
QA Contact: general → search
Target Milestone: --- → Thunderbird 3
Version: unspecified → Trunk
David, no crash report when you crashed? http://kb.mozillazine.org/Breakpad#Location_of_crash_reports
Keywords: crash
The problem appears to have disappeared, now that the background indexing has done its thing. In any case, there's about 100 "submitted" and none pending. Here's an example GUID of one of the submitted ones: bp-5b21a3e3-47ac-42d6-bf2e-a93612090301
As not all the crash reports are the same, here's the complete list for your enjoyment. Note, many others were not successfully submitted because I was off-network for many of the crashes: bp-01d3f206-4439-4c71-94a8-1e39b2090301 bp-0783638e-3b6c-4b7f-b2aa-2fa4d2090301 bp-09d16ab3-eef3-43ea-92cf-6550e2090301 bp-12d033c0-e7e1-410b-acca-f04272090301 bp-27ba89bc-0e78-4688-b625-fc6a52090301 bp-2a5eccc5-04f1-4b7f-8301-266522090301 bp-2e762212-3e7a-4115-ad47-f43542090301 bp-2ed393d8-cec4-4b89-baa9-91e9b2090302 bp-30a4f473-d857-4853-8123-f9d762090304 bp-3426bce7-b109-4c46-a429-da1112090302 bp-3744e345-ec3c-4ca7-9e38-03c012090301 bp-3cc653ef-fef7-492c-acc8-e423f2090301 bp-46431480-b3fc-4bde-b56b-d03832090302 bp-496519da-7fa6-41e0-ac51-3cac12090301 bp-4de68c12-2f77-421c-959a-14e6d2090301 bp-50f49000-a47c-4c0b-bf22-8c3c52090301 bp-530ef939-3fb9-419a-984b-12c0f2090304 bp-5686bfcb-1a79-4cec-a255-44bd52090301 bp-5b21a3e3-47ac-42d6-bf2e-a93612090301 bp-5c4c1a46-29b9-4644-81ba-898912090302 bp-5d8e4b75-bafc-4c6f-a9de-053e02090301 bp-600c00a0-b089-44bb-aa39-807082090302 bp-64252ca4-c182-44e8-973a-3a17e2090228 bp-6c4f101c-0796-4666-a8d8-633cd2090228 bp-707dc85a-8092-45f7-bace-275c32090228 bp-7a1c4acf-0359-4914-b9ca-c51702090301 bp-83908819-d3a6-42d9-830a-029ab2090124 bp-8558559f-9151-43d7-b756-5328a2081212 bp-87703ec8-e4cd-4bdf-9f6a-bac7c2090301 bp-8b253ccd-d91f-4ae1-84ab-590832090301 bp-8ee15373-b0fc-4cb7-9dc2-89e842090301 bp-8f9b7a23-db68-4762-9efe-932062090302 bp-95b649bc-90cf-400c-9c81-8d9432081215 bp-9f767fcb-8d6a-459a-a9f4-dd2932090301 bp-a36923af-c5c8-4c4f-8aa4-5a2c82090304 bp-ae31f252-7c4e-4c7a-be7b-51e3d2090301 bp-b443aad6-5a2d-4874-bc6b-b44e22090301 bp-b8b35ec0-af48-48c8-8244-b03d02090301 bp-bb8e61d0-c835-40d3-bbf1-c0da72081228 bp-bc845422-e0a9-4cf4-a1b6-5ae762090301 bp-c31a6f07-b64b-47e8-af3a-d3a6d2090302 bp-c52a161d-39ab-412a-a76f-c46a22090223 bp-c6de90e8-5b0e-48be-9ce7-409432090228 bp-d3ec9fde-2896-4132-9b9e-90cd72081214 bp-d447393d-efcb-4148-b89f-d31592090302 bp-dec62b5d-350d-4a50-ab7e-706122090301 bp-e2542e81-a68f-4a99-838f-4fbab2090301 bp-ec417c2b-8bfd-4182-a662-9eb692090129 bp-f18a51da-4ebe-4514-a654-4e0f52090301 bp-f21c8f0f-2d35-46d3-8626-645b42090302 bp-fc6f7716-71e9-48d7-9305-8aae72090301
David, is this indexing for windows search? but if it's gloda indexing, maybe bug 456404 IMAP crash in build with new gloda indexer: nsCOMPtr<nsIImapMockChannel>::~nsCOMPtr()
No, I don't use windows indexing or any other product. This is evidently T'Bird's internal indexing that runs in the background. I don't know what triggers it to run, but it ran almost incessently for 10 M I/Os...the only time it stopped was when I put the tool in offline mode.
so, we don't seem to have symbols for eudora... jeff: who's the eudora build engineer? :)
eudora should have symbols. David, can you start eudora in offline mode, install this extension http://code.google.com/p/socorro/downloads/detail?name=crashme.xpi&can=2&q= then force a crash with "tools>crash me now" and provide the crash id thunderbird's only indexing areas are gloda (options>advanced>general>enable gloda), and windows' indexing (prompted at install). have to wonder how/if your bug 482828, sporadic zero-length MSF files, relates to this issues. makes sense that if you go offline the crash doesn't happen, because all imap activity would cease.
Severity: normal → critical
standard8 tested b5 with crashme and it doesn't produce a usable crash with symbols
Providing additional info: - yes, I had gloda turned on (didn't realize that there was an option to turn it off - no, the symptom is not occurring any more - have installed CrashMeNow - crashfile, FWIW, is bp-8ed234f5-f51d-4fe7-961d-c7ccf2090312
(In reply to comment #12) > so, we don't seem to have symbols for eudora... jeff: who's the eudora build > engineer? :) Starting a while back, eudora builds should be sending their symbols to crash-stats, it's possible crash-stats hasn't been fully taught about using them, however. Jeff Beckley should know more about this.
FWIW, regarding the note in comment #13 regarding IMAP activity... I'm only using Eudora for email, and all the accounts are POP, and I don't check email automatically on startup. As this symptom (including the CPU and disk usage that went with it) have gone away, I don't know that I can provide much useful to you on this. If there were a way to trigger re-indexing of everything, I'm happy to do some testing.
re comment #13 on bug 482828, they may be related as the problem seems to occur a few seconds *after* a message is moved from the Inbox to a mail file. Perhaps the move-message activity triggers a re-index of the msf file right after it's appended to by the message move.
(In reply to comment #15) > Providing additional info: > - yes, I had gloda turned on (didn't realize that there was an option to > turn it off > - no, the symptom is not occurring any more (my, you are adventurous turning on indexing) your problem then is likely gloda indexing. blowing away the gloda index and reenabling indexing will likely bring the problem back. won't get fixed until thunderbird beta 3. possibilities, but by no means definitely one of these, include bug 479008 gloda event-driven indexing should not interfere with the source of events bug 465353 compose sluggish during indexing of gloda bug 465009 [believed fixed by bug 466438] Long pauses (windows hourglass 100% cpu) switching folders while indexing gloda bug 470445 Message indexing maxes out machine cpu [gloda] > - have installed CrashMeNow > - crashfile, FWIW, is bp-8ed234f5-f51d-4fe7-961d-c7ccf2090312 thanks for testing that. this crash definitely indicates crash-stats isn't using/finding eudora symbols
Target Milestone: Thunderbird 3 → ---
Sorry to keep the noise level up here, but I was reading up on gloda and wanted to make sure there was no confusion. I have never installed gloda. I only installed whatever came with Eudora...and what was turned on by default (Tools>Options>Tools>Advanced>Enable Message Indexer). Because I'm nuts, I'll try the "delete the gloda index and re-enable" dance, just to see if I can reproduce.
So we have test results. Procedure: un-check "enable message indexer" kill Eudora rename global-messages-db.sqlite restart Eudora
whoops, continuing last post check "enable message indexer" watch indexer crunch for 4M I/Os, an hour of CPU time Eudora eventually crashes...and when it does, it crashes incessantly after 10 seconds of up time. "solved" crash problem by stopping Eudora (that was easy!) and moving one mail file out of "view" of the indexer. Everything runs fine. The file that causes the crash is a 576 MB file of outbound messages. There are several very similar files that don't cause any problem, but this is by far the largest. Maybe gloda indexer just barfs on large files? What's the best way to investigate further?
(In reply to comment #22) > The file that causes the crash is a 576 MB file of outbound messages. There > are several very similar files that don't cause any problem, but this is by far > the largest. Maybe gloda indexer just barfs on large files? > > What's the best way to investigate further? Thank you for your investigations thus far! You would probably want to use Thunderbird nightly builds (+ penelope?). But for now, I'd advise just turning indexing off. There are a number of known issues/potential issues that we should fix before putting you through any more pain :)
do we know why his indexing was on by default?
actually, I don't *know* that it was on by default. I may have turned it on manually months ago, and inherited the setting during the upgrade process. what I can tell you is that this symptom never occurred in the early Eudora betas, it only hit me when I came to B5 (T'bird PRE1)
Eudora/Penelope don't turn on gloda. It probably only hit David at E8b5 because that's when gloda
[argh, wasn't done typing yet] first showed up as a UI pref (TB3b1).
GOOD NEWS, folks. This bug has nothing to do with indexing per se. Through extensive trial-and-error, I have found a message that will crash the mail client -- simply trying to read it causes immediate termination. Here's an example crash ID bp-78ddbd70-9632-4e40-be10-916112090408 By removing this mail message from my folders, indexing now runs fine. Interesting thing about the mail is that it has no foreign character sets...and I used to be able to read it in Eudora. In fact, I originally replied to it. But there's something in the message that causes instant death to both Eudora and TBird on my windows XP system. 100% repeatable. I have it in its own folder which I'm happy to zip up and mail to any engineer that wants to analyze -- just contact me at davofanmail at a domain name of comcast.net
fallout from bug 473924? (In reply to comment #28) > GOOD NEWS, folks. > > This bug has nothing to do with indexing per se. Through extensive > trial-and-error, I have found a message that will crash the mail client -- > simply trying to read it causes immediate termination. Here's an example crash > ID bp-78ddbd70-9632-4e40-be10-916112090408 0 eudora.exe nsCharTraits<unsigned short>::length nsVCardObj.cpp:1317 1 eudora.exe fakeCString nsVCardObj.cpp:1324 2 eudora.exe nsMsgVCardService::FakeCString nsMsgVCardService.cpp:70 3 eudora.exe OutputBasicVcard mimevcrd.cpp:418 4 eudora.exe GenerateVCardData mimevcrd.cpp:356 5 eudora.exe WriteOutVCard mimevcrd.cpp:323 6 eudora.exe MimeInlineTextVCard_parse_eof mimevcrd.cpp:274 7 eudora.exe MimeMultipart_close_child mimemult.cpp:616 8 eudora.exe MimeMultipart_parse_line mimemult.cpp:185 9 eudora.exe convert_and_send_buffer mimebuf.cpp:184 10 eudora.exe mime_LineBuffer mimebuf.cpp:272 11 eudora.exe MimeObject_parse_buffer mimeobj.cpp:287 12 eudora.exe MimeMessage_parse_line mimemsg.cpp:240 13 eudora.exe convert_and_send_buffer mimebuf.cpp:184 14 eudora.exe mime_LineBuffer mimebuf.cpp:272 15 eudora.exe MimeObject_parse_buffer mimeobj.cpp:287 16 eudora.exe mime_display_stream_write mimemoz2.cpp:946 17 eudora.exe nsStreamConverter::OnDataAvailable nsStreamConverter.cpp:938 18 eudora.exe nsDocumentOpenInfo::OnDataAvailable uriloader/base/nsURILoader.cpp:306 19 eudora.exe nsMailboxProtocol::ReadMessageResponse nsMailboxProtocol.cpp:593 20 eudora.exe nsMailboxProtocol::ProcessProtocolState nsMailboxProtocol.cpp:690 21 eudora.exe nsMsgProtocol::OnDataAvailable nsMsgProtocol.cpp:347 22 eudora.exe nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:508
Status: UNCONFIRMED → NEW
Component: Search → Backend
Ever confirmed: true
QA Contact: search → backend
Summary: Eudora 8.0b5 crashes very frequently → Eudora 8.0b5 crashes very frequently [@ nsCharTraits<unsigned short>::length - fakeCString]
I'm interested in getting a reduced testcase out of David's one.
Keywords: testcase-wanted
David, feel free to e-mail it to me. Does it crash TB 3.0b3pre?
I've sent the test case to Gary and David directly. Given the number of complete index rebuilds it took to isolate this weird message, you could call this one a 200,000,000 I/O, 15,000,000,000,000 CPU OPS special. Makes the national debt look small. I've been running Eudora b5...don't know which TBird build that translates to.
I'm not sure what TB build Eudora 8.0 b5 corresponds to either, but I could read each of the 3 messages in the test case w/o a problem.
er, with my tb 3.0 b3pre build, that is.
(In reply to comment #33) > I'm not sure what TB build Eudora 8.0 b5 corresponds to either, but I could > read each of the 3 messages in the test case w/o a problem. Bug 473924 maybe? Its a security bug but the code it patched seems to be around the place of the crash stack.
well, yeah, I'm hoping that Eudora build simply doesn't have that fix. The fix was landed on the trunk 2009-02-13
Eudora8b5 uses TB3b1 code, so the fix would not be in it. Bienvenu, can you get the crash to happen with those 3 messages with TB beta 1 or 2? Taber, would you be willing to attach the 3 problem messages to this bug?
Given that, I'm sure this is a dup of bug 473924 - Jeff, I can point you at the fix for that bug and if David gets you a test case, you can verify that the fix works for Eudora as well.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Hi. I don't have a problem with your using my "poison" folder as a test case, but I can't authorize your putting the mails as is out on the web some place where Google can see it. I don't mind for myself, but the other people in the email thread deserve to have their privacy maintained. As a footnote here: when this "poison" mails were originally read and responded to, I was running Eudora B4...so this was a regression that showed up in B5. At this point, it's water way under the bridge, but you might want to double-check the theory about the bug's origin. Thanks
I've got a minimal testcase stripped out of any sensitive information, and crashes in Eudora 8 beta 5 WinXP. Will be continuing to test.
Flags: in-testsuite?
Keywords: testcase-wanted → testcase
Attached file testcase —
Crashes in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre Note the composition of the vcard: ===== begin:vcard fn:foobar email;inte rnet:foo end:vcard ===== The email section was split into two lines (this was present in David's original testcase).
Verifying that the patch in bug 473924 fixes this. The following regression window of the patch shows that the patch does indeed fix the bug. Crashes: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090213 Shredder/3.0b2pre Doesn't crash: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090214 Shredder/3.0b2pre
Status: RESOLVED → VERIFIED
The crash report I got from Eudora 8 Beta 5 is at http://crash-stats.mozilla.com/report/index/a4948ca8-0131-44f8-a58a-21a1e2090408?p=1 Setting bug as FIXED by the patch in bug 473924.
Resolution: DUPLICATE → FIXED
Crash Signature: [@ nsCharTraits<unsigned short>::length - fakeCString]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: