User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090124 Shredder/3.0b2pre Updated to latest nightly, Get Mail - it crashes. Further investigation showed it consistently crashed - on both my accounts after the progress indicated retrieving the last message. On an account with no mail "Get Mail" worked fine, so it might be in the process of indexing the incoming mail, or junk filtering it, or something like that. Going back to previous nightly worked, so this is a newly introduced bug. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Crash report numbers bp-2b71ebc0-a2dd-4552-8196-b31932090124 bp-92c6a669-1376-496d-a086-5c1e32090124 bp-d528c404-aaaf-48bc-b7b5-fa9562090124 bp-f5ca6b0c-afd6-4177-919b-af5b22090124

nsObjCExceptionLogAbort nsAppShell::ProcessGeckoEvents CoreFoundation@0x735f4 CoreFoundation@0x73cd7 you're going to need to use console.app or something to get the useful information

The message in Console.app is: 26/01/09 10:42:20 AM thunderbird-bin[1474] Mozilla has caught an Obj-C exception [NSInvalidArgumentException: Invalid parameter not satisfying 'uniqueId != nil && [uniqueId length] > 37']

I've just checked and confirmed the bug is still there on today's nightly Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090125 Shredder/3.0b2pre and is not there on the 23rd Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shredder/3.0b2pre -- its a consistent, and repeatable crash -- 26/01/09 10:50:02 AM [0x0-0xd80d8].org.mozilla.thunderbird 2009-01-26 10:50:02.671 thunderbird-bin[1508:10b] Mozilla has caught an Obj-C exception [NSInvalidArgumentException: Invalid parameter not satisfying 'uniqueId != nil && [uniqueId length] > 37']

OK - its there again in today's nightly Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090127 Shredder/3.0b2pre I've no idea if this is effecting other OSX users, or even if there are any other testers running nightly on OSX? I'd attach a crash report, but its just one-line with the crash-id in it ! Could someone with the source code maybe just check where that exception is generated.... - Mitra

Just confirming - this crashing bug is still there on tonight's build, Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090124 Shredder/3.0b2pre I have a feeling that there may not be anyone else with OSX actively testing nightlys, and this is bad enough to block the beta going out, unless someone can confirm it actually works on OSX! I'm not sure how to get attention to this bug? If any OSX users are out there could you actually confirm the current nightlys work? I've done a bit more research and confirmed that the buggy nightly's actually download the messages, and then crash - i.e. if I go back to a working nightly, the downloaded messages are there in the (POP) Inbox.

Is there anyone who could check what patches were committed to the nightlys between the last known working version Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shredder/3.0b2pre and the first known buggy version Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090125 Shredder/3.0b2pre so that it can be reported on that bug? That is only two nightlys, so there can't have been too many patches committed, I just have no idea how to see what.

Ok - I've narrowed it down further, 20090124 has the bug as well, so its clearly one of the patches that went into that nightly.

(In reply to comment #8) > Ok - I've narrowed it down further, 20090124 has the bug as well, so its > clearly one of the patches that went into that nightly. Maybe it's caused by bug 474345

Mitra, if you make about:buildconfig the start page, you'll be able to get the mozilla-1.9.1 source revisions that were used to make those nightly builds, that may be helpful in tracking the regression as we will then know exactly what went in to core between the two builds.

I have tested this one, but sorry, "Get mail" workes perfect for me. I've sended myself a mail and retrieve it in Thunderbird by clicking the "Get mail" button. This workes perfect for me. I have tested this with message indexing enabled and disabled. And I tested this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shredder/3.0b2pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.2a1pre) Gecko/20090130 Thunderbird/3.1a1pre Maybe this depends on any preferences you set. Do you use IMAP or POP3? I use POP3.

Thanks Nomis, - I don't think its preferences, though it could be. I have indexing disabled (assuming you mean Preferences / Advanced / General / "Enable Message Indexer ) Makes it sound like its data dependent - except it happens with any new mail, so it would have to be with old mail. Do you have access to the source - I could run a test version that kept a log (or used console log) of what had been done, to narrow down where the crash is, as I suspect the stack trace above - identifying GeckoEvents, but not what hte event was - isn't much help. - Mitra

Something has been done that appears to fix this bug in the 31jan nightly, i.e. if I go back to 27jan it crashes, if I run 31jan its ok - this is on the same Profile. Hopefully someone fixed something, and its not just a bug thats disappeared and will resurface again for someone else less willing to be persistant!

Mark - by the way, that about page didn't seem to help the first buggy one (24jan) showed in about:buildconfig http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d93a8a38f98b Which, if I read it correctly, only seemed to change a test, but the 24jan nightly was repeatable broken compared to 23jan - Mitra

Mitra: the about:buildconfig page only gives the latest revision that went into a build. With two revisions (i.e. one build and the next) we can easily know exactly which range of revisions went into the build. However, as this seems to have disappeared I'm closing as WFM as is standard in this situation.

In response to your other suggestion - I'm not sure what it means to start Shredder in "Safe mode" - I'm happy to try that if it would provide useful information. (Preferably without it rebuilding index and losing all the tags etc)

Sorry - posted this to wrong bug.