Growlmail "assertion failure" messages in log

[sddawson]

I have upgraded from Leopard to Snow Leopard (not a clean install of Snow Leopard). I have installed Growl and GrowlMail V1.2.

I have noticed some error messages in the console log when some email messages arrive. Doesn't happen for all of them, but once it happens for a particular message, it is repeatable. That is, I can forward that message to myself and see the messages. If Growlmail is uninstalled, the messages do not appear. Everything does seem to work, but I guess something untoward is going on. Message sample:

Code: Select all

4/11/09 5:05:59 PM	Mail[896]	Using Growl.framework 1.2 (1.2)
4/11/09 5:05:59 PM	Mail[896]	Loaded GrowlMail 1.2
4/11/09 5:08:35 PM	Mail[896]	*** Assertion failure in -[MimeBody dataForMimePart:], /SourceCache/Message/Message-1076.1/Message.subproj/MIME.subproj/MimeBody.m:422
This method must be called off the main thread
(
	0   Message                             0x00007fff81e46828 -[MFAssertionHandler _handleFailureWithPreamble:description:arguments:] + 137
	1   Message                             0x00007fff81e4678d -[MFAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 220
	2   Message                             0x00007fff81d23a66 -[MimeBody dataForMimePart:] + 349
	3   Message                             0x00007fff81d237c9 -[MimePart bodyData] + 57
	4   Message                             0x00007fff81d231bc -[MimePart(DecodingSupport) decode] + 865
	5   Message                             0x00007fff81e4e103 -[MimePart _getMessageAttachment:] + 333
	6   Message                             0x00007fff81e228a4 -[MessageAttachment dataForFetchLevel:] + 289
	7   Message                             0x00007fff81e6c500 -[ParsedMessage attributedString] + 231
	8   Message                             0x00007fff81e4796e -[MimeBody attributedString] + 81
	9   GrowlMail                           0x00000001007b67cd 0x0 + 4303054797
	10  Foundation                          0x00007fff8668f713 __NSThreadPerformPerform + 219
	11  CoreFoundation                      0x00007fff8427f281 __CFRunLoopDoSources0 + 1361
	12  CoreFoundation                      0x00007fff8427d879 __CFRunLoopRun + 873
	13  CoreFoundation                      0x00007fff8427d03f CFRunLoopRunSpecific + 575
	14  HIToolbox                           0x00007fff8334ac4e RunCurrentEventLoopInMode + 333
	15  HIToolbox                           0x00007fff8334aa53 ReceiveNextEventCommon + 310
	16  HIToolbox                           0x00007fff8334a90c BlockUntilNextEventMatchingListInMode + 59
	17  AppKit                              0x00007fff844b4520 _DPSNextEvent + 718
	18  AppKit                              0x00007fff844b3e89 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
	19  AppKit                              0x00007fff84479a7d -[NSApplication run] + 395
	20  AppKit                              0x00007fff84472798 NSApplicationMain + 364
	21  Mail                                0x000000010000167c 0x0 + 4294973052
)
4/11/09 5:08:44 PM	Mail[896]	*** Assertion failure in -[MimeBody dataForMimePart:], /SourceCache/Message/Message-1076.1/Message.subproj/MIME.subproj/MimeBody.m:422
This method must be called off the main thread
(
	0   Message                             0x00007fff81e46828 -[MFAssertionHandler _handleFailureWithPreamble:description:arguments:] + 137
	1   Message                             0x00007fff81e4678d -[MFAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 220
	2   Message                             0x00007fff81d23a66 -[MimeBody dataForMimePart:] + 349
	3   Message                             0x00007fff81d237c9 -[MimePart bodyData] + 57
	4   Message                             0x00007fff81d231bc -[MimePart(DecodingSupport) decode] + 865
	5   Message                             0x00007fff81e4e103 -[MimePart _getMessageAttachment:] + 333
	6   Message                             0x00007fff81e228a4 -[MessageAttachment dataForFetchLevel:] + 289
	7   Message                             0x00007fff81e6c500 -[ParsedMessage attributedString] + 231
	8   Message                             0x00007fff81e4796e -[MimeBody attributedString] + 81
	9   GrowlMail                           0x00000001007b67cd 0x0 + 4303054797
	10  Foundation                          0x00007fff8668f713 __NSThreadPerformPerform + 219
	11  CoreFoundation                      0x00007fff8427f281 __CFRunLoopDoSources0 + 1361
	12  CoreFoundation                      0x00007fff8427d879 __CFRunLoopRun + 873
	13  CoreFoundation                      0x00007fff8427d03f CFRunLoopRunSpecific + 575
	14  HIToolbox                           0x00007fff8334ac4e RunCurrentEventLoopInMode + 333
	15  HIToolbox                           0x00007fff8334aa53 ReceiveNextEventCommon + 310
	16  HIToolbox                           0x00007fff8334a90c BlockUntilNextEventMatchingListInMode + 59
	17  AppKit                              0x00007fff844b4520 _DPSNextEvent + 718
	18  AppKit                              0x00007fff844b3e89 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
	19  AppKit                              0x00007fff84479a7d -[NSApplication run] + 395
	20  AppKit                              0x00007fff84472798 NSApplicationMain + 364
	21  Mail                                0x000000010000167c 0x0 + 4294973052
)

Anyone know what's going on? Thanks.

[boredzo]

Code: Select all

4/11/09 5:08:35 PM	Mail[896]	*** Assertion failure in -[MimeBody dataForMimePart:], /SourceCache/Message/Message-1076.1/Message.subproj/MIME.subproj/MimeBody.m:422
This method must be called off the main thread

Interesting. And yet we can't call attributedString off the main thread because WebKit started throwing exceptions when we did that.

We could try again—maybe they've removed that exception from WebKit. If so, great: We can start checking WebKit's version and doing the whole thing on a secondary thread, like we used to. If not, working for most messages beats working for none.

[sddawson]

Forgive my ignorance, but what exactly isn't working? What side effects, if any, does this have (since I can't see any myself)?

Thanks for responding!

[boredzo]

Forgive my ignorance, but what exactly isn't working?

We retrieve the message body on the main thread because WebKit doesn't (or, if we're lucky, briefly didn't) like it when we retrieved it on a secondary thread.

Now, according to that message, Mail doesn't like us retrieving it on the main thread, and wants us to do it on a secondary thread.

What side effects, if any, does this have (since I can't see any myself)?

No idea. But I'd still switch it to summary mode, or take the %body keyword out of the notification description format.

[sddawson]

OK. My notification description only has %subject, so maybe that's why it doesn't seem to have any effect. Thanks. I'll watch out for an update and test again.

[boredzo]

My notification description only has %subject, …

No it doesn't. If it only had %subject, you wouldn't be getting an assertion failure in trying to retrieve the body.

Check on the second line of the description.

[sddawson]

Ah yes, a quick scroll down and there it was! I've removed it, even though it didn't seem to be causing any trouble, just to be on the safe side...

Thanks again.

[sddawson]

Although, now I know what leads to the error, I can say that even for those emails that cause this (I think it's only those with attachments, although maybe not ALL those with attachments), the body still appears fine in the Growlmail notification if I use %body.