 |
 |
Crash on [invalid release]
|
 |
|
 |
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
Getting signal 11 (SIGSEV) when running, and EXC_BAD_ACCESS when debugging.
I'm reading data from a file previously saved by the application. Most of the items being decoded to are NSStrings and most of them work fine, but one is causing problems, although I can't see how it's implementation is any different to any of the others.
I'm using the statement:
[self setSource:[coder decodeObject]];
to call the method in which the error occurs:
Code:
- (void)setSource:(NSString *)aString
{
[source release]; //CRASHES ON THIS LINE
source = [aString copy];
}
The error occurs on the release call above.
NB: There are many instances of this class and the first 12 instances work fine. It's only at the 13th instance where trouble comes. No I'm not superstitious  . There is a difference with the 13th instance, and that is that the first 12 instances have an empty aString decoded from the file, whereas the 13th instance contains a string with a useful value.
Now when trying to debug this, I noticed that for the first 12 instances (where aString is empty), source is also empty. However, when it gets to the 13th instance (where aString is not empty), source is "invalid" according to the debugger.
How did that happen? Nothing has changed source as far as I can tell.
Any help would be very much appreciated.
(Last edited by Brass; Oct 14, 2002 at 01:00 AM.
)
|
|
|
| |
|
|
|
 |
|
 |
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
Hmmm... I did notice one difference between the [source release] and the release in the accessor methods for other variables. The other variables use "autorelease" instead of "release".
However if I change it to "autorelease" for source, it still crashes, but with a signal 10 (SIGBUS) instead of signal 11 (SIGSEV)
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Elite
Join Date: May 2002
Status:
Offline
|
|
Well, this is exactly the error you'd get if source is nil...
Which would happen if [coder decodeObject] is returning nil...
Which will happen if you're trying to apply the wrong kind of decoding. I suggest you look very carefully at what you're doing with the coder. Is it an NSUnarchiver? Some custom class of your own?
|
|
[vash:~] banana% killall killall
Terminated
|
| |
|
|
|
 |
|
 |
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
Originally posted by Gul Banana:
Well, this is exactly the error you'd get if source is nil...
Which would happen if [coder decodeObject] is returning nil...
Which will happen if you're trying to apply the wrong kind of decoding. I suggest you look very carefully at what you're doing with the coder. Is it an NSUnarchiver? Some custom class of your own?
But if you look at my code above, [coder decodeObject] is returning a value which the accessor method gets as 'aString'. In the case where it crashes the debugger shows that 'aString' is a valid string (and a string I recognise that it should be getting).
Why would this affect the value of 'source' when it does not get assigned to 'source' until the line AFTER it crashes?
However, something does seem to be affecting the value of 'source' as it is showing in the debugger as "invalid" on the occurrances when it crashes. What on earth would be changing 'source', I don't know.
Yes, using NSUnarchiver to decode NSStrings. Should be fairly simple stuff (but these complex problems usually do have simple causes).
|
|
|
| |
|
|
|
 |
|
 |
|
Junior Member
Join Date: Feb 2002
Status:
Offline
|
|
It's perfectly OK to send a message to nil.
[nil release];
is legal and doesn't actually do anything.
The odds are, either source is not pointing anywhere meaningful, or it's being released too many times. Be careful with NSUnarchiver- I think some of its methods return autoreleased objects. You may want to retain the objects you unarchive.
|
|
self = [[JeffBinder alloc] init];
|
| |
|
|
|
 |
|
 |
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
Originally posted by Jeff Binder:
It's perfectly OK to send a message to nil.
[nil release];
is legal and doesn't actually do anything.
That's what I thought, otherwise a standard accessor method (eg, setSource) would never work the first time it is used for each instance.
The odds are, either source is not pointing anywhere meaningful, or it's being released too many times. Be careful with NSUnarchiver- I think some of its methods return autoreleased objects. You may want to retain the objects you unarchive.
The problem appears to be that source is invalid (according to the debugger) at the point where I'm trying [source release] and get a SIGBUS or SIGSEV.
What I need to figure out is how is 'source' becoming invalid? Nothing (that I can think of) is accessing it. It only becomes invalid when 'aString' has a legitimate value (other than empty). At all other instances (when 'aString' is empty) 'source' is not invalid (but is empty - new objects are supposed to be nil aren't they?)
|
|
|
| |
|
|
|
 |
|
 |
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
SOLVED IT!!!
(sorry for shouting, but I'm happy now!)
Immediately before decoding to the 'source' object, I was decoding to the address of an int. However, I was using decodeValueOfObjCType:"d" instead of "i" ('d' is used for int in other situations, so I guess I was confused).
In any case, whatever "d" stands for in this situation, it was blatting it's data over whatever was next in the address space, which in this case was my 'source' object. So I used NSLog(@"%s", @encode(int)) to find out what I really needed to use.
|
|
|
| |
|
|
|
 |
 |
|
 |
|
|
|
|
|

|
|
 |
Forum Rules
|
 |
 |
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
 |
 |
 |
 |
|
 |
|