Re: Debugging a crash
Re: Debugging a crash
- Subject: Re: Debugging a crash
- From: Shawn Erickson <email@hidden>
- Date: Wed, 1 Dec 2004 16:32:38 -0800
On Dec 1, 2004, at 4:00 PM, Mark Dawson wrote:
-(int)vramSize:(long**)vsArray
The method appears to receive an array called vsArray that is typed
cast as long**. How exactly is the memory object passed in for vsArray
defined in the calling code?
CFNumberGetValue(typeCode, kCFNumberSInt32Type, vsArray[i]);
Here you are passing a pointer (defined to be a pointer to a long) in
for valuePtr (the last parameter). In side of CFNumberGetValue this
pointer will dereferenced (to get at the memory it points at) and a 32
bit number will be written into that memory.
So did the caller of the vramSize method actually allocate memory of at
least 32 bits (as your SInt32 type is requesting) in size and assign a
pointer to that memory in the vsArray slot?
My guess is that IORegistryEntryCreateCFProperty is returning a bad
value; however, I'm not sure how to tell (via the debugger), nor how
to protect the code against it. Any suggestions?
Could be something IORegistryBlah is returning but it is unlikely in
this case. To use the debugger simply set a break point just inside of
the for loop and step your program (step over) watching what values
show up in typeCode, etc. to understand if the values look sensible.
Anyway I believe you have an issue with how you are using vsArray or
about how you are assuming CFNumberGetValue behaves (it doesn't
allocate memory for you). You likely want something like the following
(written in mail)...
SInt32 vsArray[dspCount];
[someObject vramSize:vsArray];
.... and inside of vramSize ...
CFNumberGetValue(typeCode, kCFNumberSInt32Type, &vsArray[i]);
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden