From: Evan S. <ev...@ad...> - 2006-07-02 08:24:10
|
I've seen this crash multiple times, seemingly randomly, and it's being reported by users in our Adium 1.0 alpha releases. Thread 0 Crashed: 0 libSystem.B.dylib 0x9002c434 restore_sem_to_pool 84 1 libSystem.B.dylib 0x90001bb4 pthread_mutex_lock 604 2 ...apple.AddressBook.framework 0x94ccebb8 -[ABMetaDataController postpone] 32 3 ...apple.AddressBook.framework 0x94cce4a4 _ABExitFunction 228 4 libSystem.B.dylib 0x90014c98 __cxa_finalize 260 5 libSystem.B.dylib 0x90014b64 exit 36 6 Libgaim 0x059faecc gg_resolve 264 7 Libgaim 0x059fb9a4 gg_login 968 8 Libgaim 0x05952e1c ggp_login 160 9 Libgaim 0x059226b0 gaim_prpl_change_account_status 140 10 Libgaim 0x05916714 notify_status_update 100 Somehow, gg_resolve() is ending up calling into the Apple Address Book framework... all I can figure is that it's getting an invalid pointer reference and then following it, and for whatever reason that goes there. It's always to that same function (_ABExitFunction). Any thoughts? -Evan |
From: Ethan B. <ebl...@cs...> - 2006-07-02 16:03:02
|
Evan Schoenberg spake unto us the following wisdom: > 3 ...apple.AddressBook.framework 0x94cce4a4 _ABExitFunction 228 > 4 libSystem.B.dylib 0x90014c98 __cxa_finalize 260 > 5 libSystem.B.dylib 0x90014b64 exit 36 > 6 Libgaim 0x059faecc gg_resolve 264 >=20 > Somehow, gg_resolve() is ending up calling into the Apple Address =20 > Book framework... all I can figure is that it's getting an invalid =20 > pointer reference and then following it, and for whatever reason that =20 > goes there. It's always to that same function (_ABExitFunction). That's not at all what is happening. gg_resolve is calling *exit*, and the Address Book framework has (for some reason) installed an atexit() handler which is being called by exit(). I suspect gg_resolve() has an assertion or some such in it which is failing (though true assertions won't call exit), but that's a guess. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Evan S. <ev...@dr...> - 2006-07-02 17:46:55
Attachments:
PGP.sig
|
On Jul 2, 2006, at 12:02 PM, Ethan Blanton wrote: > Evan Schoenberg spake unto us the following wisdom: >> 3 ...apple.AddressBook.framework 0x94cce4a4 _ABExitFunction 228 >> 4 libSystem.B.dylib 0x90014c98 __cxa_finalize 260 >> 5 libSystem.B.dylib 0x90014b64 exit 36 >> 6 Libgaim 0x059faecc gg_resolve 264 >> >> Somehow, gg_resolve() is ending up calling into the Apple Address >> Book framework... all I can figure is that it's getting an invalid >> pointer reference and then following it, and for whatever reason that >> goes there. It's always to that same function (_ABExitFunction). > > That's not at all what is happening. gg_resolve is calling *exit*, > and the Address Book framework has (for some reason) installed an > atexit() handler which is being called by exit(). I suspect > gg_resolve() has an assertion or some such in it which is failing > (though true assertions won't call exit), but that's a guess. Ah, thanks, Ethan. That does make more sense. I didn't realize atexit() existed so didn't consider that possibility. Bartosz, any thoughts on the assertion or whatever it is? -Evan |
From: Evan S. <ev...@dr...> - 2006-07-02 18:12:59
Attachments:
PGP.sig
|
On Jul 2, 2006, at 12:02 PM, Ethan Blanton wrote: > I suspect > gg_resolve() has an assertion or some such in it which is failing > (though true assertions won't call exit), but that's a guess. Looking at it more closely, gg_resolve() does a fork(). The child then does a DNS lookup and then exit(0)s. So that's our codepath to exit()... The problem with the Address Book framework having an atexit() handler is that according to this cocoa-dev post [1] by Chris Kane, who works on the Cocoa Frameworks for Apple, after a fork() no such libraries can be used without a paired execve()... and apparently the AB is having its handler called when the child process exits and then being... difficult. How does exit() differ from _exit()? The proxy.c code in gaim does _exit() within its child process and I've never seen a crash like this. (Speaking of the proxy.c child processes, is there something different about OS X that's leading the code to spawn zombie processes just for us, or is it a problem everwhere? We've installed a signal handler to waitpid() for them and thereby destroy them... which seems like something that shouldn't be necessary). -Evan |
From: Ethan B. <ebl...@cs...> - 2006-07-02 18:36:55
|
Evan Schoenberg spake unto us the following wisdom: > On Jul 2, 2006, at 12:02 PM, Ethan Blanton wrote: > > I suspect > >gg_resolve() has an assertion or some such in it which is failing > >(though true assertions won't call exit), but that's a guess. >=20 > Looking at it more closely, gg_resolve() does a fork(). The child =20 > then does a DNS lookup and then exit(0)s. So that's our codepath to =20 > exit()... Sounds reasonable. > The problem with the Address Book framework having an atexit() =20 > handler is that according to this cocoa-dev post [1] by Chris Kane, =20 > who works on the Cocoa Frameworks for Apple, after a fork() no such =20 > libraries can be used without a paired execve()... and apparently the =20 > AB is having its handler called when the child process exits and then =20 > being... difficult. That sounds like a broken library, to me. It's exiting the process group on exit() or something. At any rate, a solution is below... > How does exit() differ from _exit()? The proxy.c code in gaim does =20 > _exit() within its child process and I've never seen a crash like this. That's right, and that's the "solution" I would probably go for, in the face of yet another example of Apple lacking clue. _exit() calls the exit system call directly, without any of the associated cleanup that libc normally does; this means that it may not flush stdio buffers, it won't call atexit() handlers, etc. etc. (I think that what it does and does not do is actually unspecified, but it *will not* call atexit() handlers.) > (Speaking of the proxy.c child processes, is there something =20 > different about OS X that's leading the code to spawn zombie =20 > processes just for us, or is it a problem everwhere? We've installed =20 > a signal handler to waitpid() for them and thereby destroy them... =20 > which seems like something that shouldn't be necessary). We have to wait for every child that exits, or zombies will appear; is OSX spawning children that Gaim on other platforms does not? Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Simon W. <si...@sx...> - 2006-07-02 18:40:56
|
On 2 Jul 2006, at 19:12, Evan Schoenberg wrote: > How does exit() differ from _exit()? The proxy.c code in gaim does > _exit() within its child process and I've never seen a crash like > this. See the manual pages for _exit() and exit() for the complete details. In particular, I believe that _exit() doesn't call any of the registered exit handlers - which is why you aren't seeing these problems in proxy.c. Simon. |
From: Evan S. <ev...@dr...> - 2006-07-02 18:20:01
Attachments:
PGP.sig
|
On Jul 2, 2006, at 2:12 PM, Evan Schoenberg wrote: > according to this cocoa-dev post [1] by Chris Kane [1] http://lists.apple.com/archives/cocoa-dev/2005/Jan/msg00676.html Sorry, forgot the link. Apologies for the mail flood. -Evan |
From: Ethan B. <ebl...@cs...> - 2006-07-02 18:38:27
|
Evan Schoenberg spake unto us the following wisdom: > On Jul 2, 2006, at 2:12 PM, Evan Schoenberg wrote: >=20 > >according to this cocoa-dev post [1] by Chris Kane >=20 > [1] http://lists.apple.com/archives/cocoa-dev/2005/Jan/msg00676.html >=20 > Sorry, forgot the link. Apologies for the mail flood. This is a somewhat different issue from what we're seeing, and is not unreasonable. What he describes is not a bug; what we are seeing here I would classify as a bug. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |