Ticket #7564 (closed defect: duplicate)
crash on startup or when checking for updates
| Reported by: | raeburn | Owned by: | nobody |
|---|---|---|---|
| Milestone: | Component: | Adium Core | |
| Version: | 1.1 | Severity: | normal |
| Keywords: | Cc: | ||
| Patch Status: |
Description
Today I've suddenly started seeing lots of crashes on launching Adium. It doesn't happen every time, but it happens a lot, and it's both in 1.1 which I just downloaded to my desktop machine, and 1.0.5 that I'm still running on my laptop. When it doesn't crash on startup, I can usually trigger the crash by telling Adium to check for updates. Again, not always. If it doesn't happen on launch or the first time I check for updates, generally checking for updates again will trigger it.
I've submitted crash reports from the desktop machine. There's some variation, but it seems to consistently be a problem in [SUUpdater newVersionAvailable]:
(PPC 1.1)
Thread 0 Crashed:
0 libobjc.A.dylib 0x90a402e8 _class_lookupMethodAndLoadCache + 112
1 libobjc.A.dylib 0x90a401d4 objc_msgSend + 244
2 org.ironcoder.SparklePlus 0x001dd7f0 -[SUAppcastItem minimumSystemVersion] + 36
3 org.ironcoder.SparklePlus 0x001da3c4 -[SUUpdater newVersionAvailable] + 52
4 org.ironcoder.SparklePlus 0x001da734 -[SUUpdater appcastDidFinishLoading:] + 672
Thread 0 Crashed:
0 libobjc.A.dylib 0x90a400f8 objc_msgSend + 24
1 org.ironcoder.SparklePlus 0x001dd7f0 -[SUAppcastItem minimumSystemVersion] + 36
2 org.ironcoder.SparklePlus 0x001da3c4 -[SUUpdater newVersionAvailable] + 52
3 org.ironcoder.SparklePlus 0x001da734 -[SUUpdater appcastDidFinishLoading:] + 672
(Intel 1.0.5, trace copied by hand)
Thread 0 Crashed:
0 libobjc.A.dylib 0x90a594c7 objc_msgSend + 23
1 org.ironcoder.SparklePlus 0x001cb881 -[SUUpdater newVersionAvailable] + 45
It looks like the same crash as in #7559, and #7557, and #7549, etc... In #7542 the submitter indicates the crash happens 90% of the time, which is consistent with what I've seen, and I think would explain how random factors like removing a Yahoo account from Mail would seem to "fix" the problem in other tickets. I don't recall if the check-on-launch is set up to happen only every so often, but if so, that would also explain why it seems to stay "fixed" once a successful check happens (also consistent with what I'm seeing); if that's the case, it'll break again after a certain delay.
The 90% and the variations in the stack trace suggest some kind of race condition to me...