Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS crash report once again

M

MACloop

macrumors 6502
Original poster
May 18, 2009
393
0
Germany
Hello,
can someone give me a hint where this crash may appear?
Thanks in advance!
MACloop

Code: 
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x454c4c45
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib               	0x000025fa objc_msgSend + 18
1   CoreFoundation                	0x00004714 -[NSObject release] + 24
2   MapKit                        	0x00052b96 -[MKAnnotationView dealloc] + 102
3   CoreFoundation                	0x00004714 -[NSObject release] + 24
4   MapKit                        	0x0005238e -[MKAnnotationView release] + 22
5   UIKit                         	0x00015754 -[UIView(Hierarchy) removeFromSuperview] + 392
6   UIKit                         	0x0003a6e4 -[UIView dealloc] + 148
7   MapKit                        	0x00026826 -[MKAnnotationContainerView dealloc] + 698
8   CoreFoundation                	0x00004714 -[NSObject release] + 24
9   UIKit                         	0x00015754 -[UIView(Hierarchy) removeFromSuperview] + 392
10  UIKit                         	0x0003a6e4 -[UIView dealloc] + 148
11  UIKit                         	0x000c8c6a -[UIScrollView dealloc] + 206
12  MapKit                        	0x000513f2 -[MKScrollView dealloc] + 58
13  CoreFoundation                	0x00004714 -[NSObject release] + 24
14  UIKit                         	0x00015754 -[UIView(Hierarchy) removeFromSuperview] + 392
15  UIKit                         	0x000c8b82 -[UIScrollView removeFromSuperview] + 42
16  UIKit                         	0x0003a6e4 -[UIView dealloc] + 148
17  CoreFoundation                	0x00004714 -[NSObject release] + 24
18  UIKit                         	0x00015754 -[UIView(Hierarchy) removeFromSuperview] + 392
19  UIKit                         	0x0003a6e4 -[UIView dealloc] + 148
20  MapKit                        	0x0000c7ec -[MKMapView dealloc] + 816
21  CoreFoundation                	0x00004714 -[NSObject release] + 24
22  Foundation                    	0x0007275a __delayedPerformCleanup + 22
23  CoreFoundation                	0x00026230 CFRunLoopTimerInvalidate + 244
24  CoreFoundation                	0x00022d60 CFRunLoopRunSpecific + 2160
25  CoreFoundation                	0x000224da CFRunLoopRunInMode + 42
26  GraphicsServices              	0x000030d4 GSEventRunModal + 108
27  GraphicsServices              	0x00003180 GSEventRun + 56
28  UIKit                         	0x000034c2 -[UIApplication _run] + 374
29  UIKit                         	0x000019ec UIApplicationMain + 636
30  iPadApp                   	0x00002d40 main (main.m:14)
31  iPadApp                   	0x00002cf4 start + 32
 
Given that it's seems to be map view annotation releases and timer related I suspect it's the release you are doing in a performSelector:withObject:afterDelay: that I told you yesterday was a bad idea and would lead to crashes that you would not be able to debug.
 
robbieduncan said:
Given that it's seems to be map view annotation releases and timer related I suspect it's the release you are doing in a performSelector:withObject:afterDelay: that I told you yesterday was a bad idea and would lead to crashes that you would not be able to debug.
Click to expand...

ok 1:0 for you ;-)
Hmmm...I have to reconsider how to solve that. The delegate method did not do the job, unfortunally :-(

MACLoop
 
MACloop said:
ok 1:0 for you ;-)
Hmmm...I have to reconsider how to solve that. The delegate method did not do the job, unfortunally :-(

MACLoop
Click to expand...

You suggested yesterday that I should control the view not to call dealloc/ViewDidUnload before the map was done loading. How can I control that?
 
MACloop said:
You suggested yesterday that I should control the view not to call dealloc/ViewDidUnload before the map was done loading. How can I control that?
Click to expand...

No, I didn't. I suggested you should not release the delegate until the map was done with it.
 
robbieduncan said:
No, I didn't. I suggested you should not release the delegate until the map was done with it.
Click to expand...

ok, and how did you mean that I could do that?

EDIT:
and what very strange is - this is happening without that I dealloc or get a memory warning. I use nslog to se where in the progress I am. I am not releasing or setting the map to nil, but in those to methods
 
MACloop said:
ok, and how did you mean that I could do that?
Click to expand...

Well my suggestion was not to release the reference to the delegate object until the map has completed loading. This may not be necessary: from what I remember of your code you release the delegate but you don't set the delegate property of the map view to nil which leaves a dangling pointer. I'd try setting the delegate property to nil before releasing the delegate object. This certainly stops UIWebViews crashing the app in identical circumstances.
 
robbieduncan said:
Well my suggestion was not to release the reference to the delegate object until the map has completed loading. This may not be necessary: from what I remember of your code you release the delegate but you don't set the delegate property of the map view to nil which leaves a dangling pointer. I'd try setting the delegate property to nil before releasing the delegate object. This certainly stops UIWebViews crashing the app in identical circumstances.
Click to expand...

So, to set it like this is not an option? If I have an IBOutlet, I have to retain it in the property?

.h
Code: 
IBOutlet MKMapView *map; //connected to object in .xib file

.m
Code: 
... in viewDidLoad
	region.span=span;
	region.center=austin;
	map.showsUserLocation = YES;
	map.userLocation.title = @"You are here!";
	[map setRegion:region animated:NO];
	[map regionThatFits:region];
	[self doSomething];
 
I don't see what any of the above has to do with the delegate property of the MKMapView which is where I understood the problem came from.
 
robbieduncan said:
You cannot remove the delegate property of MKMapView. Which is the property I am talking about. What you have done is stop declaring the instance variable map of your class as a property. Which I did not ever suggest.
Click to expand...

ok, so I have to use @property(nonatomic,retain)... for the map? I did so and it lead to memorywarnings... whitout self.map for instance and all the other IBOutlets for the view my app is running without no warnings...
 
I did not want you to change anything about how you keep a reference to the map. I am beginning to think you are intentionally misunderstanding what I type.

You are releasing the map property after some time to prevent what you call "the blue dot problem". I have no idea what this is. I assumed that you had set the map delegate property (the one I linked to above) to something and the map was trying to call a method on this delegate object that no longer existed when it completed loading/locating. So my suggestion was to ensure that the map delegate was set to nil before the delegate object gets released:

Code: 
map.delegate = nil;

It might be more helpful if you posted the crash log from this "blue dot problem"
 
robbieduncan said:
I did not want you to change anything about how you keep a reference to the map. I am beginning to think you are intentionally misunderstanding what I type.

You are releasing the map property after some time to prevent what you call "the blue dot problem". I have no idea what this is. I assumed that you had set the map delegate property (the one I linked to above) to something and the map was trying to call a method on this delegate object that no longer existed when it completed loading/locating. So my suggestion was to ensure that the map delegate was set to nil before the delegate object gets released:

Code: 
map.delegate = nil;

It might be more helpful if you posted the crash log from this "blue dot problem"
Click to expand...

ok, but I dont think this is the problem because I create the map and let it live till a memorywarning is raised or the viewcontroller is dealloced. None of those is happening when the crash appears. This means, it cannot be the reason for the crash. Here is a link about the mapkit problem http://omegadelta.net/2009/11/02/mkdotbounceanimation-animationdidstop-bug/
 
MACloop said:
ok, but I dont think this is the problem because I create the map and let it live till a memorywarning is raised or the viewcontroller is dealloced. None of those is happening when the crash appears. This means, it cannot be the reason for the crash. Here is a link about the mapkit problem http://omegadelta.net/2009/11/02/mkdotbounceanimation-animationdidstop-bug/
Click to expand...

And in the comments there are multiple solutions that look safer and better than performSelector:withObject:afterDelay:. I also note that right at the top of the page it says "set the delegate to nil when the delegate dealloc’s, as per that advice to fix one of the crashbugs" which is what I told you to do in this thread.
 
robbieduncan said:
And in the comments there are multiple solutions that look safer and better than performSelector:withObject:afterDelay:. I also note that right at the top of the page it says "set the delegate to nil when the delegate dealloc’s, as per that advice to fix one of the crashbugs" which is what I told you to do in this thread.
Click to expand...
I got this msg when running the app...seem to be some problem with my Annotations class...
Code: 
An instance 0x6cb6cc0 of class Annotations is being deallocated while key value observers are still registered with it. Observation info is being leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info:
<NSKeyValueObservationInfo 0x76d3500> (
<NSKeyValueObservance 0x7645110: Observer: 0x6c2b6f0, Key path: coordinate, Options: <New: NO, Old: NO, Prior: NO> Context: 0x0, Property: 0x6c7a680>
)
 
MACloop said:
I got this msg when running the app...seem to be some problem with my Annotations class...
Code: 
An instance 0x6cb6cc0 of class Annotations is being deallocated while key value observers are still registered with it. Observation info is being leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info:
<NSKeyValueObservationInfo 0x76d3500> (
<NSKeyValueObservance 0x7645110: Observer: 0x6c2b6f0, Key path: coordinate, Options: <New: NO, Old: NO, Prior: NO> Context: 0x0, Property: 0x6c7a680>
)
Click to expand...

So I have made some updates now. What do you think about this:

.h file
Code: 
	IBOutlet MKMapView *map;
	Annotations *annotation;
}
@property(nonatomic,retain)IBOutlet MKMapView *map;
@property(nonatomic,retain)Annotations *annotation;
- (IBAction) dismissView:(id)sender;
- (id)initWithAnnotation:(Annotations*)anno;

.m-file
Code: 
- (id)initWithAnnotation:(Annotations*)anno {
	if ((self = [super init])) {
		self.annotation = anno;
	}
	return self;
}


- (void)viewDidLoad { 
	[super viewDidLoad];
	...
	if(annotation != nil){
		
		[self.map setRegion:region animated:TRUE];
		[self.map regionThatFits:region];
		[self.map setHidden:NO];
		[self.map addAnnotation:annotation];
		 //some label are set from annotation title and subtitle 
	}
	[self.annotation release];
...
}

- (void)mapView:(MKMapView *)mapView didAddAnnotationViews:(NSArray *)views {
	if([[UIApplication sharedApplication] isIgnoringInteractionEvents] == TRUE){
		[[UIApplication sharedApplication] endIgnoringInteractionEvents];
	}
	[self.map release];
}
 
I have read some more and in almost every post I have seen about memory warnings and viewcontrollers, the answer was that it is ok to set variables free in the viewDidUnload method, because the dealloc is not going to be called in this case... Of course it would be dfifferent with a navigation controller for instance. So I have tried this aus and I have provoked some memory warnings and it seem to work out fine. I would very much appreciate you comment on this, because it has always been very helpful!
I have done this:
.h
Code: 
NSMutableArray *objects;
NSMutableArray *otherObjects;
@property(nonatomic,assign) NSMutableArray *objects;
@property(nonatomic,assign) NSMutableArray *otherObjects;

.m
Code: 
- (void)viewDidLoad {
	[super viewDidLoad];
	self.objects = [[NSMutableArray alloc]init];
	self.otherObjects = [[NSMutableArray alloc]init];
//other stuff....
}

- (void)viewDidUnload {
	self.objects = nil;
	self.otherObjects = nil;
	[super viewDidUnload];
}

//in dealloc are the vars released
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back