Closed Bug 475205 Opened 16 years ago Closed 15 years ago

Get mail crashes on restart

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mitra_lists, Unassigned)

Details

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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
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.
You need to log in before you can comment on or make changes to this bug.