I have the following line of code which activates the breakpoint
[mapView addAnnotations:grabinstance.itemArray];
This crashing randomly. grabinstance.itemArray is fully populated always and is never changing at the time due to this bit of code only being called once the array is full. This particular time this was confirmed as 323 items in the array.
NSZombieEnabled doesn't find anything at all either.
The backtrace is below and line 1154 is the line above.
#0 0x0126a372 in _insert ()
#1 0x0126a312 in _splitNode ()
#2 0x0126a3b7 in _insert ()
#3 0x011db253 in -[MKAnnotationContainerView addAnnotation:] ()
#4 0x011dfc2e in -[MKAnnotationContainerView addAnnotations:] ()
#5 0x011b0b30 in -[MKMapView addAnnotations:] ()
#6 0x00009257 in -[BigViewController plotItems] (self=0x614de90, _cmd=0x16464f) at /Users/zzzz/Documents/iPhone Projects/BigProject/Classes/BigViewController.m:1154
#7 0x005336c1 in _nsnote_callback ()
#8 0x01c18f99 in __CFXNotificationPost_old ()
#9 0x01b9833a in _CFXNotificationPostNotification ()
#10 0x00529266 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#11 0x00024071 in -[ItemGrabber parserDidEndDocument:] (self=0x617b540, _cmd=0x689aa3, parser=0xf6b4ab0) at /Users/zzzz/Documents/iPhone Projects/BigProject/Classes/ItemGrabber.m:267
You should check your annotations using CLLocationCoordinate2DIsValid():
if (CLLocationCoordinate2DIsValid(place.coordinate)) {
[_mapView addAnnotation:place];
} else {
NSLog(#"place %# has invalid coordinates", place.name);
}
Bug reported to Apple and as been acknowledged
I also had the same problem and i fixed it,The problem was with my locations,The objects in the array may not contain valid locations,They may be garbage values
Related
I am tring to upgrade to php7 and symfony3 from php5.6 and symfony2 resp. I have some symfony console commands which uses soap to request third party apis.
After upgrading to php7 and php7.0-soap, but command fails with segmentation fault. I tried debugging with gdb, below is the trace. Looks like this is the issue with php7.0-soap ? What is the solution ?
Program received signal SIGSEGV, Segmentation fault.
0x00005555557bc4db in zend_hash_destroy ()
(gdb) bt
#0 0x00005555557bc4db in zend_hash_destroy ()
#1 0x00007fffecbbe141 in delete_type_persistent () from /usr/lib/php/20151012/soap.so
#2 0x00005555557bc5dd in zend_hash_destroy ()
#3 0x00007fffecbc55f1 in ?? () from /usr/lib/php/20151012/soap.so
#4 0x00007fffecbc565f in ?? () from /usr/lib/php/20151012/soap.so
#5 0x00005555557bc4d2 in zend_hash_destroy ()
#6 0x00007fffecb95f0b in zm_shutdown_soap () from /usr/lib/php/20151012/soap.so
#7 0x00005555557b25f3 in module_destructor ()
#8 0x00005555557ab08c in ?? ()
#9 0x00005555557bd048 in zend_hash_graceful_reverse_destroy ()
#10 0x00005555557ac055 in zend_shutdown ()
#11 0x000055555574fb3b in php_module_shutdown ()
#12 0x000055555563d796 in main ()
you can't use WSDL_CACHE_MEMORY (or WSDL_CACHE_BOTH) in PHP7 for the time being: https://bugs.php.net/bug.php?id=71931
use WSDL_CACHE_DISK instead by setting soap.wsdl_cache in php.ini, or - if you don't have access to php.ini - using ini_set:
ini_set('soap.wsdl_cache', WSDL_CACHE_DISK);
I configured a mongodb's capped collection,with capacity more than 3G,after that mongod crash for many times,but there was nothing wrong in the mongd.log.Howerver linux abrt has core dumped for mongod,messages from coredump are as following:
Program terminated with signal 5, Trace/breakpoint trap. #0 0x00000000010b9951 in v8::internal::OS::DebugBreak() () Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64 (gdb) where #0 0x00000000010b9951 in v8::internal::OS::DebugBreak() () #1 0x00000000010ba06a in
v8::internal::OS::Abort() () #2 0x0000000000f1c5f3 in API_Fatal(char const*, char const*, ...) () #3 0x0000000000ece607 in ?? () #4 0x0000000000ece916 in
v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) () #5 0x000000000108c891 in v8::internal::Map::UpdateCodeCache(v8::internal::Handle<v8::internal::Map>,
v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::Code>) () #6 0x0000000001149180 in
v8::internal::StubCache::ComputeKeyedLoadOrStoreElement(v8::internal::Handle<v8::internal::Map>, v8::internal::KeyedIC::StubKind, v8::internal::StrictModeFlag) () #7
0x0000000001000bfc in v8::internal::KeyedIC::ComputeMonomorphicStub(v8::internal::Handle<v8::internal::Map>,
v8::internal::KeyedIC::StubKind, v8::internal::StrictModeFlag, v8::internal::Handle<v8::internal::Code>) () #8 0x000000000100779a in
v8::internal::KeyedIC::ComputeStub(v8::internal::Handle<v8::internal::JSObject>, v8::internal::KeyedIC::StubKind, v8::internal::StrictModeFlag,
v8::internal::Handle<v8::internal::Code>) () #9 0x0000000001008551 in v8::internal::KeyedLoadIC::Load(v8::internal::InlineCacheState,
v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool) () #10 0x000000000100894d in v8::internal::KeyedLoadIC_Miss(v8::internal::Arguments,
v8::internal::Isolate*) ()
my mongodb is 2.4.1, running in centos 6.3,16G memory and 8cpus.
Anyone can help me? Thanks very much.
The out of memory error mentioned makes me suspect that this could be an occurrence of this bug (V8 memory leaking):
https://jira.mongodb.org/browse/SERVER-9230
Can you upgrade to 2.4.2+ and see if the error still happens for you?
I am dispatch_sync()'ing a block on the main queue. In this block, a call to executeFetchRequest:error: is eventually made. Sometimes, this causes a deadlock.
Here is Thread 1 which shows the block invoked on the main thread and then the call to executeFetchRequest:error:
#0 0x981f3876 in __psynch_mutexwait ()
#1 0x97a016af in pthread_mutex_lock ()
#2 0x0135be32 in -[_PFLock lock] ()
#3 0x0135be0a in -[NSPersistentStoreCoordinator lock] ()
#4 0x01371d1c in -[NSManagedObjectContext(_NSInternalAdditions) lockObjectStore] ()
#5 0x013702c0 in -[NSManagedObjectContext executeFetchRequest:error:] ()
#6 0x0000a701 in -[NSManagedObjectContext(Convenience) fetchObjectsForEntityName:onlyIDs:withPredicate:] at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/NSManagedObjectContext(Convenience).m:50
#7 0x00065270 in +[NSManagedObject(ContextAdditions) contextForID:managedObjectContext:] at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/NSManagedObject+ContextAdditions.m:40
#8 0x0006597e in __85+[NSManagedObject(ContextAdditions) createContextIfNeededForID:managedObjectContext:]_block_invoke_0 at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/NSManagedObject+ContextAdditions.m:55
#9 0x00065aad in __85+[NSManagedObject(ContextAdditions) createContextIfNeededForID:managedObjectContext:]_block_invoke_050 at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/NSManagedObject+ContextAdditions.m:64
#10 0x023cf8d9 in _dispatch_barrier_sync_f_slow_invoke ()
#11 0x023d0509 in _dispatch_main_queue_callback_4CF ()
#12 0x01ae9803 in __CFRunLoopRun ()
#13 0x01ae8d84 in CFRunLoopRunSpecific ()
#14 0x01ae8c9b in CFRunLoopRunInMode ()
#15 0x019b47d8 in GSEventRunModal ()
#16 0x019b488a in GSEventRun ()
#17 0x004ba626 in UIApplicationMain ()
I can see that executeFetchRequest:error: is blocking on NSPersistentStoreCoordinator's lock, but I don't know who currently has it locked.
The original dispatch_sync() is occurring from a different thread, and here's that in case it's important:
Thread 18, Queue : (null)
#0 0x981f1c5e in semaphore_wait_trap ()
#1 0x023d1bda in _dispatch_thread_semaphore_wait ()
#2 0x023d0cb2 in _dispatch_barrier_sync_f_slow ()
#3 0x023d0e0f in dispatch_barrier_sync_f ()
#4 0x023d0f4c in _dispatch_sync_slow ()
#5 0x0006563a in +[NSManagedObject(ContextAdditions) createContextIfNeededForID:managedObjectContext:] at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/NSManagedObject+ContextAdditions.m:63
#6 0x0006e2ee in __109-[ItemFetcher createOrConfigureObjectWithDescriptor:withContext:jsonObjectIDKey:modelObjectIDKey:entityName:]_block_invoke_0 at /Users/mike/Dropbox/src/Tracky-iPhone/Tracky/Tracky/ItemFetcher.m:78
#7 0x023ce330 in _dispatch_call_block_and_release ()
#8 0x023cff0c in _dispatch_queue_drain ()
#9 0x023cfcb4 in _dispatch_queue_invoke ()
#10 0x023cf402 in _dispatch_worker_thread2 ()
#11 0x97a04b24 in _pthread_wqthread ()
Here is the code up to the original dispatch:
+ (Context *) createContextIfNeededForID: (NSString *) contextID managedObjectContext:(NSManagedObjectContext *) moc
{
// See if this context is in the main MOC. This call needs to happen synchronously on the main queue, if we're
// not on the main queue
Context * (^contextFromMainMOCBlock)(void) =
^ `Context` * {
// We are guaranteed to be in the main here; look at how this block is invoked.
return [self contextForID:contextID managedObjectContext:[UIApplication trackyAppDelegate].managedObjectContext] ;
} ;
__block Context *contextFromMainMOC = nil ;
if( [UIApplication trackyAppDelegate].managedObjectContext == moc )
contextFromMainMOC = contextFromMainMOCBlock() ;
else
dispatch_sync(dispatch_get_main_queue(), ^{
contextFromMainMOC = contextFromMainMOCBlock() ; // <-- here
}) ;
…
contextForID:contextID managedObjectContext: really doesn't do anything with core data until it calls executeFetchRequest:error:.
UPDATE
Here are the rest of the stack traces. AFAIK they're not doing anything interesting although I may be wrong.
Thread 3, Queue : (null)
#0 0x981f490a in kevent ()
#1 0x023d0372 in _dispatch_mgr_invoke ()
#2 0x023cebe1 in _dispatch_mgr_thread ()
Thread 5 WebThread, Queue : (null)
#0 0x981f1c22 in mach_msg_trap ()
#1 0x981f11f6 in mach_msg ()
#2 0x01b8610a in __CFRunLoopServiceMachPort ()
#3 0x01ae95d5 in __CFRunLoopRun ()
#4 0x01ae8d84 in CFRunLoopRunSpecific ()
#5 0x01ae8c9b in CFRunLoopRunInMode ()
#6 0x04776420 in _ZL12RunWebThreadPv ()
#7 0x97a02ed9 in _pthread_start ()
Thread 6 com.apple.NSURLConnectionLoader, Queue : (null)
#0 0x981f1c22 in mach_msg_trap ()
#1 0x981f11f6 in mach_msg ()
#2 0x01b8610a in __CFRunLoopServiceMachPort ()
#3 0x01ae95d5 in __CFRunLoopRun ()
#4 0x01ae8d84 in CFRunLoopRunSpecific ()
#5 0x01ae8c9b in CFRunLoopRunInMode ()
#6 0x00ebae30 in +[NSURLConnection(Loader) _resourceLoadLoop:] ()
#7 0x00dcc4d6 in -[NSThread main] ()
#8 0x00dcc447 in __NSThread__main__ ()
#9 0x97a02ed9 in _pthread_start ()
Thread 10 com.apple.CFSocket.private, Queue : (null)
#0 0x981f3b42 in select$DARWIN_EXTSN ()
#1 0x01b1a7cb in __CFSocketManager ()
#2 0x97a02ed9 in _pthread_start ()
And here is contextID:managedObjectContext: which is the method called in the dispatch_sync() :
+ (Context *) contextForID: (NSString *) contextID managedObjectContext:(NSManagedObjectContext *) moc
{
NSPredicate *predicate = [NSPredicate predicateWithFormat:#"cid == %#", contextID] ;
NSSet *contexts = [moc fetchObjectsForEntityName:#"Context" onlyIDs:NO withPredicate:predicate] ;
// Integrity check
NSAssert1(contexts.count < 2, #"More than one context with the same CID exists: %#" , contexts) ;
return [contexts anyObject] ;
}
fetchObjectsForEntityName:onlyIDs:withPredicate: looks like this:
- (NSSet *)fetchObjectsForEntityName:(NSString *)newEntityName onlyIDs: (BOOL) onlyIDs
withPredicate:(id)stringOrPredicate, ...
{
NSEntityDescription *entity = [NSEntityDescription
entityForName:newEntityName inManagedObjectContext:self];
NSAssert1( entity != nil , #"entity not found for \"%#\"" , newEntityName ) ;
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:entity];
[request setIncludesPropertyValues:!onlyIDs] ;
if (stringOrPredicate)
{
NSPredicate *predicate;
if ([stringOrPredicate isKindOfClass:[NSString class]])
{
va_list variadicArguments;
va_start(variadicArguments, stringOrPredicate);
predicate = [NSPredicate predicateWithFormat:stringOrPredicate
arguments:variadicArguments];
va_end(variadicArguments);
}
else
{
NSAssert2([stringOrPredicate isKindOfClass:[NSPredicate class]],
#"Second parameter passed to %s is of unexpected class %#",
sel_getName(_cmd), NSStringFromClass(stringOrPredicate));
predicate = (NSPredicate *)stringOrPredicate;
}
[request setPredicate:predicate];
}
NSError *error = nil;
NSArray *results ;
#try {
results = [self executeFetchRequest:request error:&error];
}
#catch (NSException *exception) {
NSLog(#"Exception caught: %#" , exception) ;
}
if (error != nil)
{
[NSException raise:NSGenericException format:#"%#",[error description]];
}
return [NSSet setWithArray:results];
}
To give more help, you need to show the code for all methods in the stack traces, along with line numbers. That way, it can be correlated.
Also, it looks like you have a lot of threads. I think you are going to have to examine the others to see what is happening.
You have to be very careful when calling a sync operation, especially if it may be called from other sync operations.
Check your NSManagedObjectContext for concurrencyType. It seems that your context has NSMainQueueConcurrencyType, which runs all requests in the main thread. From Apple reference:
NSMainQueueConcurrencyType
Specifies that the context will be associated with the main queue.
If I'm right you need to change type to NSPrivateQueueConcurrencyType
I have Integrated Cocos2d to my Windows based application. When I run my Project I am getting the Crash after executing the line CC_DIRECTOR_INIT(); The error is **sharedlibrary **apply-load-rules all
Warning: the current language does not match this frame.
Current language: auto; currently objective-c****. I found the meaning of the error form this POST. But My question is how can I Implement this in my Project. I am new to cocos2-d. Any suggestions is appreciated.
- (void) applicationDidFinishLaunching:(UIApplication*)application
{
CC_DIRECTOR_INIT();
CCDirector *director = [CCDirector sharedDirector];
[director setDeviceOrientation:kCCDeviceOrientationPortrait];
[director setDisplayFPS:YES];
EAGLView *view = [director openGLView];
[view setMultipleTouchEnabled:YES];
[CCTexture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGBA8888];
[[CCDirector sharedDirector] runWithScene: [Helloworld scene]];
}
This is the Screenshot where the crash occurs...
EDIT:
MY Console output..
#0 0x0002e60f in -[CCLabelAtlas updateAtlasValues] (self=0x68224c0, _cmd=0xc0be2) at CCLabelAtlas.m:75
#1 0x0002e994 in -[CCLabelAtlas setString:] (self=0x68224c0, _cmd=0x310f12c, newString=0xf3b98) at CCLabelAtlas.m:113
#2 0x0002e49c in -[CCLabelAtlas initWithString:charMapFile:itemWidth:itemHeight:startCharMap:] (self=0x68224c0, _cmd=0xb8d31, theString=0xf3b98, charmapfile=0xf3b88, w=16, h=24, c=46 '.') at CCLabelAtlas.m:50
#3 0x0002e380 in +[CCLabelAtlas labelAtlasWithString:charMapFile:itemWidth:itemHeight:startCharMap:] (self=0xf1ebc, _cmd=0xb6fd5, string=0xf3b98, charmapfile=0xf3b88, w=16, h=24, c=46 '.') at CCLabelAtlas.m:40
#4 0x0001268a in -[CCDirector setGLDefaultValues] (self=0x681c300, _cmd=0xb6b3d) at CCDirector.m:219
#5 0x0001406d in -[CCDirector setOpenGLView:] (self=0x681c300, _cmd=0xb6a18, view=0x681c850) at CCDirector.m:549
#6 0x00002e58 in -[cocowindowAppDelegate applicationDidFinishLaunching:] (self=0x681abe0, _cmd=0xd050a3, application=0x68016f0) at cocowindowAppDelegate.m:32
#7 0x00912ce2 in -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] ()
#8 0x00914d88 in -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] ()
#9 0x0091f617 in -[UIApplication handleEvent:withNewEvent:] ()
#10 0x00917abf in -[UIApplication sendEvent:] ()
#11 0x0091cf2e in _UIApplicationHandleEvent ()
#12 0x02e61992 in PurpleEventCallback ()
#13 0x01403944 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#14 0x01363cf7 in __CFRunLoopDoSource1 ()
#15 0x01360f83 in __CFRunLoopRun ()
#16 0x01360840 in CFRunLoopRunSpecific ()
#17 0x01360761 in CFRunLoopRunInMode ()
#18 0x009147d2 in -[UIApplication _run] ()
#19 0x00920c93 in UIApplicationMain ()
#20 0x00002b39 in main (argc=1, argv=0xbfffeff0) at main.m:14
(gdb)
EXC_ARITHMETIC usually means that you are dividing by zero. If you look in your screenshot then you are evaluating:
int row = (a % itemsPerRow) //...
From the output of your debugger it looks like itemsPerRow is 0 when this is caused and so the program is crashing. Try initialising this value or setting some conditional code if it is meant to be zero to stop it dividing by zero.
The warning message Warning: the current language does not match this frame. is just GDB getting a bit confused as to what language it is meant to be debugging. As you can see, it manages to sort itself out on the next line.
Edit:
This poster has a similar error to you: http://www.cocos2d-iphone.org/forum/topic/8209 Does his fix apply to you?
I have a core-data object "entity" with 2 fields - "name" (a NSString *) and "type" (a EntityType). EntityType is another core data obect with 1 field - name (NSString *).
I am creating and deleting an entity object using the code similar in functionality to the following code -
Entity *e1 = [NSEntityDescription insertNewObjectForEntityName:"#Entity" inManagedObjectContext: context]
EntityType *type = [NSEntityDescription insertNewObjectForEntityName:"#EntityType" inManagedObjectContext: context]
e1.type = type;
Now I delete the entity object without assigning any values or saving to the persistent store.
if([e1.name length] == 0) {
[context deleteObject:e1];
NSError *nil;
if(![context:save &error] {
// log error
}
}
At this point I see a crash, when I try to delete and save the object.
(Terminating due to uncaught exception 'NSRangeException' reason: [NSCFArray removeObjectAtIndex]: index(0) beyond bounds (0)]
Any pointers/suggestions are much appreciated.
Here's the stack trace that was requested -
#0 0x3266bdf4 in objc_exception_throw ()
#1 0x32d73b32 in +[NSException raise:format:arguments:] ()
#2 0x32d73ad2 in +[NSException raise:format:] ()
#3 0x33f4a710 in _NSArrayRaiseBoundException ()
#4 0x33f7ba3c in -[NSCFArray removeObjectAtIndex:] ()
#5 0x30537dc6 in -[NSFetchedResultsController(PrivateMethods) _removeObjectInFetchedObjectsAtIndex:] ()
#6 0x3053b50a in -[NSFetchedResultsController(PrivateMethods) _postprocessDeletedObjects:] ()
#7 0x3053aa9a in -[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] ()
#8 0x33f765d8 in _nsnote_callback ()
#9 0x32d9e510 in _CFXNotificationPostNotification ()
#10 0x33f741b2 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#11 0x304b4388 in -[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] ()
#12 0x3050768a in -[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:] ()
#13 0x3049c2b0 in -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] ()
#14 0x304cb186 in -[NSManagedObjectContext save:] ()
#15 0x00006d5a in -[MyAppViewController goToMain] (self=0x11b730, _cmd=0x174b3) at /Users/Me/Projects/MyApp/Classes/MyAppViewController.m:611
2010-09-15 17:37:10.053 MyApp[1273:207] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFArray removeObjectAtIndex:]: index (0) beyond bounds (0)'
2010-09-15 17:37:10.066 MApp[1273:207] Stack: (
853417245,
845594132,
852966195,
852966099,
............
.............
The error is coming from the fetchedResults array of the FRC. I suspect this is caused by you not implementing the FRC delegate methods properly such that when the tableview tries to update, it tries to access the zero index of an empty array.
When you have an FRC attached to any context, the FRC will update itself automatically when you make any change to context such as deleting an object (that is what the notifications in the trace stack are doing, telling the FRC to update.)