[Pythonmac-SIG] NSUserDefaults causes crash on MOSXI

[Zachery Bir]

[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