[background: So, I tried this again with Ronald's latest Universal build of 2.4.2 and PyObjC from the head of SVN trunk (not using Ben's work). Same crash during NSUerDefaults.standardUserDefaults()]
On Mar 1, 2006, at 1:22 PM, Bob Ippolito wrote: > The first thing I would do is take gdb and figure out what file > it's looking at... that's the second argument to > CFURLCreateDataAndPropertiesFromResource. I'm guessing it would > live on the stack, but I haven't used gdb on intel enough lately to > remember what the offset is. Not in any way I can make sense of :^\ Here follows a mini transcript, complete with help text running on my MacBook Pro: (gdb) bt #0 0x90823daa in _CFReadBytesFromFile () #1 0x90823793 in CFURLCreateDataAndPropertiesFromResource () #2 0x9082d67a in _loadXMLDomainIfStale () . . . (gdb) frame 0 #0 0x90823daa in _CFReadBytesFromFile () (gdb) info frame Stack level 0, frame at 0xbfffd1f8: eip = 0x90823daa in _CFReadBytesFromFile; saved eip 0x90823793 called by frame at 0xbfffd2c8 Arglist at 0xbfffd1f0, args: Locals at 0xbfffd1f0, Previous frame's sp is 0xbfffd1f8 Saved registers: ebx at 0xbfffd1e4, ebp at 0xbfffd1f0, esi at 0xbfffd1e8, edi at 0xbfffd1ec, eip at 0xbfffd1f4 (gdb) frame 1 #1 0x90823793 in CFURLCreateDataAndPropertiesFromResource () (gdb) info frame Stack level 1, frame at 0xbfffd2c8: eip = 0x90823793 in CFURLCreateDataAndPropertiesFromResource; saved eip 0x9082d67a called by frame at 0xbfffd338, caller of frame at 0xbfffd1f8 Arglist at 0xbfffd2c0, args: Locals at 0xbfffd2c0, Previous frame's sp is 0xbfffd2c8 Saved registers: ebx at 0xbfffd2b4, ebp at 0xbfffd2c0, esi at 0xbfffd2b8, edi at 0xbfffd2bc, eip at 0xbfffd2c4 (gdb) frame 2 #2 0x9082d67a in _loadXMLDomainIfStale () (gdb) info frame Stack level 2, frame at 0xbfffd338: eip = 0x9082d67a in _loadXMLDomainIfStale; saved eip 0x90839978 called by frame at 0xbfffd358, caller of frame at 0xbfffd2c8 Arglist at 0xbfffd330, args: Locals at 0xbfffd330, Previous frame's sp is 0xbfffd338 Saved registers: ebx at 0xbfffd324, ebp at 0xbfffd330, esi at 0xbfffd328, edi at 0xbfffd32c, eip at 0xbfffd334 You can see that in none of the frames are any arguments present. I'm a complete n00b when it comes to gdb in general and, if as you suspect it performs significantly differently on intel, well, that's just a whole other sport :^) On a lark (uneducated, but trying to poke around), I e(x)amined some of the memory registers listed - specifically the arglist address: (gdb) x 0xbfffd2c0 0xbfffd2c0: 0xbfffd330 (gdb) x 0xbfffd330 0xbfffd330: 0xbfffd350 (gdb) x 0xbfffd350 0xbfffd350: 0xbfffd370 (gdb) x 0xbfffd370 0xbfffd370: 0xbfffd3e0 I'm a fish hopelessly out of water here, but I'm willing to poke around some more with some guidance. > Alternatively you could run it under ktrace to see which file it > opens. There should be a NAMI with the path it's opening. Boy does that make some kinda output ;^) I'm more than willing to post this to my site if it'll be helpful. Zac _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
