Crash sending -sound to a notification ticket

fastsupply / growl

Automatically exported from code.google.com/p/growl

0 stars 0 forks source link

Crash sending -sound to a notification ticket #204

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. Set growlnotify (the application) to use MailMe.
2. Send a simple notification: growlnotify foo -m bar

What is the expected output?
Growl sends the message and doesn't crash.

What do you see instead?
Growl sends the message, then crashes.

No sound is set on this notification.

Original issue reported on code.google.com by p...@growl.info on 21 May 2011 at 5:54

Attachments:

GrowlHelperApp_2011-05-21-104638_Four-Sided-Cheese-Grater.crash

GoogleCodeExporter commented 9 years ago

This is a development build, by the way, which I believe is built from 
[4b793d319069]. I'll retest with 1.2.2b1.

Original comment by p...@growl.info on 21 May 2011 at 5:57

GoogleCodeExporter commented 9 years ago

b2, I mean. Successfully reproduced with 1.2.2b2.

Original comment by p...@growl.info on 21 May 2011 at 5:59

GoogleCodeExporter commented 9 years ago

This is actually a major crash, even though nobody's encountered it before. I'm 
attaching a screenshot showing the problem zombie in Instruments, including the 
stack trace of its deallocation.

I have yet to determine what's sending the Preferences Changed NSNotification, 
but if that can't be eliminated, the fix will be to amend GAC.m:~926 to tell 
the existing ticket object to reload (which should, in turn, modify existing 
notification ticket objects) rather than create a new one and replace the 
existing one. This fix would also fix #19.

Original comment by p...@growl.info on 21 May 2011 at 6:51

Added labels: Milestone-1.2.2, Priority-High
Removed labels: Priority-Medium

Attachments:

Growl-Issue204-ReproducedByMailMe.png

GoogleCodeExporter commented 9 years ago

The stack trace shown in that screenshot shows that a registration was 
processed during processing of the notification because MailMe waits for an 
NSTask, which runs the run loop. The registration re-creates the ticket for the 
registered application, which in this case was the same one that was notifying 
(growlnotify), and saves it, which causes the old ticket to get destroyed. 
Since the notification was using that, when it goes to ask it what sound (if 
any) to play, it sends a message to a dead object, which is the crash.

So this means that the crash pretty much *only* happened because I was using 
MailMe *and* growlnotify. No wonder no-one saw it before.

Anyway, the simplest fix for this is simply to retain and autorelease each 
application ticket upon retrieval, so that it stays alive until we next return 
to the application run loop, which is long enough for the notification 
processing to finish using it.

Original comment by p...@growl.info on 22 May 2011 at 3:32

GoogleCodeExporter commented 9 years ago

Fixed in [6a7d2283b316].

Original comment by p...@growl.info on 22 May 2011 at 3:33

Changed state: FixedInSource

GoogleCodeExporter commented 9 years ago

1.2.2 is released. Closing this issue.

Original comment by chrisf.g...@gmail.com on 25 May 2011 at 2:21

Changed state: Fixed