Growl.framework (1.3) crashes

[serb]

Hey guys,

we're having issues at some of our customers' Macs, which we consider
critical.

Growl.framework is crashing our app on start on OSX Lion with Growl
1.3.1 installed. Uninstalling Growl 1.3.1 solves the issue,
reinstalling causes our app to crash again. This is unfortunately not
happening on all Macs with the same settings.

Can you shed some light on this ASAP?
Thanks.

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
objc[763]: garbage collection is ON

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff8d77407b CFRelease + 27
1 com.growl.growlframework 0x000000010010f786 +
[GrowlGNTPPacket addSentAndReceivedHeadersFromDict:toArray:] + 98
2 com.growl.growlframework 0x000000010011023d +
[GrowlRegisterGNTPPacket
getHeaders:andBinaryChunks:forRegistrationDict:] + 1076
3 com.growl.growlframework 0x000000010010bc91 +
[GrowlGNTPOutgoingPacket outgoingPacketOfType:forDict:] + 413
4 com.growl.growlframework 0x00000001000fe238 -
[GrowlGNTPCommunicationAttempt socket:didConnectToHost:port:] + 36
5 com.growl.growlframework 0x0000000100103f2c __29-
[GCDAsyncSocket didConnect:]_block_invoke_0 + 79
6 libdispatch.dylib 0x00007fff9506a8ba
_dispatch_call_block_and_release + 18
7 libdispatch.dylib 0x00007fff9506c72a
_dispatch_main_queue_callback_4CF + 308
8 com.apple.CoreFoundation 0x00007fff8d7a44dc __CFRunLoopRun +
1724
9 com.apple.CoreFoundation 0x00007fff8d7a3ae6
CFRunLoopRunSpecific + 230
10 com.apple.HIToolbox 0x00007fff8ffa63d3
RunCurrentEventLoopInMode + 277
11 com.apple.HIToolbox 0x00007fff8ffad58f
ReceiveNextEventCommon + 181
12 com.apple.HIToolbox 0x00007fff8ffad4ca
BlockUntilNextEventMatchingListInMode + 62
13 com.apple.AppKit 0x00007fff9440a3f1 _DPSNextEvent +
659
14 com.apple.AppKit 0x00007fff94409cf5 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
15 com.apple.AppKit 0x00007fff9440662d -[NSApplication
run] + 470
16 com.apple.AppKit 0x00007fff9468580c
NSApplicationMain + 867
17 com.powerybase.NotifyMeForMac 0x00000001000018d4 0x100000000 +
6356

[Chris Forsythe]

Growl framework 1.3 requires at least 10.6.

The 1.3.1 sdk will have an example of how to load different versions of the framework based on the os. The example is called MultiGrowl. This will be out by the end of Sunday.

Chris

> --
> You received this message because you are subscribed to the Google Groups "Growl Development" group.
> To post to this group, send email to growl-de...@googlegroups.com.
> To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.
>

[serb]

I believe you've misunderstood the issue. I've clearly stated that the
target environment is OS X Lion (that means 10.7).

On Nov 23, 4:03 pm, Chris Forsythe <ch...@growl.info> wrote:
> Growl framework 1.3 requires at least 10.6.
>
> The 1.3.1 sdk will have an example of how to load different versions of the framework based on the os. The example is called MultiGrowl. This will be out by the end of Sunday.
>
> Chris
>

[Chris Forsythe]

Sorry I read Leopard somewhere, must have transposed it in my head. :)

-- 
Chris Forsythe

[Daniel Siemer]

The crash you see is fixed in the 1.3.1 SDK and Growl.app 1.3.2, both of which we are almost finished with. We were releasing a CFStringRef without checking to see if it was NULL first. We apologize for this, the condition under which it happens (SCDynamicStoreCopyLocalHostName() can return NULL) was not seen on any of our Mac's before release.

[serb]

That's pretty much unfortunate. This bug just rendered our app useless
for some of our customers. Sorry to say that, but I take this as a
first strike of Growl as we're in pretty bad situation just because of
bundling it. What we need is a workaround from you, guys, for our
affected users. Is there anything they can update/modify in their
system to be able to launch the app? I'm sorry, but we can't afford to
wait until you release an update and until Apple approves our new
"minor" update.

[Daniel Siemer]

SCDynamicStoreCopyLocalHostName copy's the system's hostname, which should be the one set/shown in System Preferences -> Sharing -> Computer Name.  If the user doesn't have a name set there, likely it would cause the function to return NULL (I can't get the name to unset at all, I try leaving a blank name, and it reenters the old name).  Unfortunately the people I have asked to try this possible workaround that have reported the bug not reported back if that worked around it for them or not. 

As a final measure, if nothing else works, they can run Growl 1.2.2, and this bug will not manifest as the framework will use a different method which does not have this crash, to talk to Growl.  

Again, we are very sorry about this.  

[Chris Forsythe]

We can only do so much testing. If you'd like to be added to our sdk beta testing list, I'd be happy to add you. This was not caught in testing by multiple third party developers such as yourself, and we ran the beta for weeks with multiple revisions to it.

-- 
Chris Forsythe

[serb]

Thanks. Will try those suggestions and let you know the results.

[Chris Forsythe]

If those don't work definitely let us know. We're going to expedite shipping the update (hopefully today). Sorry about the problem.

Chris

[Zeflash]

I'm working on an app that uses Growl SDK 1.3.1, and a client whom has growl 1.3.3 installed still experiences the crash with the exact same stack.

This isn't acceptable - we have no workarounds available for him other than uninstalling growl - or taking out the growl sdk from our app.

There should be a way to prevent using GNTP - or it should be *very* resilient, and full of try / catches to prevent *any* crashes.

Please release a new SDK that doesn't have network code in it yet as sandboxing is not (yet) mandatory for app store apps.

Le mercredi 23 novembre 2011 17:13:02 UTC+1, Christopher Forsythe a écrit :

If those don't work definitely let us know. We're going to expedite shipping the update (hopefully today). Sorry about the problem.

Chris

On Nov 23, 2011, at 9:51 AM, serb <serb...@pavel.cz> wrote:

> Thanks. Will try those suggestions and let you know the results.
>
>
> On Nov 23, 4:39 pm, Daniel Siemer <dan...@growl.info> wrote:
>> SCDynamicStoreCopyLocalHostName copy's the system's hostname, which should be the one set/shown in System Preferences -> Sharing -> Computer Name.  If the user doesn't have a name set there, likely it would cause the function to return NULL (I can't get the name to unset at all, I try leaving a blank name, and it reenters the old name).  Unfortunately the people I have asked to try this possible workaround that have reported the bug not reported back if that worked around it for them or not.
>>
>> As a final measure, if nothing else works, they can run Growl 1.2.2, and this bug will not manifest as the framework will use a different method which does not have this crash, to talk to Growl.
>>
>> Again, we are very sorry about this.
>>
>> On Nov 23, 2011, at 9:28 AM, serb wrote:
>>
>>
>>
>>> That's pretty much unfortunate. This bug just rendered our app useless
>>> for some of our customers. Sorry to say that, but I take this as a
>>> first strike of Growl as we're in pretty bad situation just because of
>>> bundling it. What we need is a workaround from you, guys, for our
>>> affected users. Is there anything they can update/modify in their
>>> system to be able to launch the app? I'm sorry, but we can't afford to
>>> wait until you release an update and until Apple approves our new
>>> "minor" update.
>
> --
> You received this message because you are subscribed to the Google Groups "Growl Development" group.

> To post to this group, send email to growl-development@googlegroups.com.
> To unsubscribe from this group, send email to growl-development+unsubscribe@googlegroups.com.

[Chris Forsythe]

We'll do no such thing. We will however help you out. You didn't provide the crash logs, but assuming this is the same based on you saying it's the same stack (I'm hoping you looked at the right thread).

Like Daniel said earlier, we've received no feedback on it. We believe we have it resolved in the 1.3.1 framework, that's obviously not the case. So instead of demanding that we remove something, let's work to simply fix it instead.

We are running a beta of the sdk *right now* on the sdk beta list. If you'd like I can add you to that list.

-- 
Chris Forsythe

To view this discussion on the web visit https://groups.google.com/d/msg/growl-development/-/iAwrO9LWrWMJ.
To post to this group, send email to growl-de...@googlegroups.com.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.

[Zeflash]

Like I said, it's the exact same crashlog, same stack, same functions, same line offsets. I couldn't reproduce the conditions to make that happen though, and it's obviously not happening to every users.

I'd like to be part of the sdk beta list, I'll try to provide the user who experiences the crash an updated build that includes the new SDK.

[Chris Forsythe]

Definitely try the updated framework before sending it out to your user of course. You're added to the list. :)

-- 
Chris Forsythe

To view this discussion on the web visit https://groups.google.com/d/msg/growl-development/-/Rmofw9Tpdt8J.
To post to this group, send email to growl-de...@googlegroups.com.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.

[Zeflash]

Just so you know, when the user set a computer name on his machine the crash went away. So that means this specific issue isn't yet fixed in 1.3.1, and it also means we don't have a way to test new versions of the framework anymore - at least for that user.