Search Results

Search found 15 results on 1 pages for 'nszombie'.

Page 1/1 | 1 

  • Debugging over-released objects, problem with NSZombie

    - by hyn
    I have a reproduceable EXC_BAD_ACCESS during NSAutoreleasePool -drain, which seems to indicate that I am over-releasing an object. So I enable NSZombie, but then the program does not crash any more. Nor do I get any info logged to the console. If I turn NSZombie off, the crash comes back. What is the meaning of this? I thought NSZombies were used to tackle exactly this kind of problem. If NSZombie won't help, is there another way to interrogate this over-released object? Also the crash is not reproduceable on Simulator, which is why I can't use Instruments with NSZombie.

    Read the article

  • EXC_BAD_ACCESS NSUrlConnection

    - by Lars
    Hi all, i got an EXC_BAD_ACCESS when i perform the last line of the function (webData). -(void)requestSoap{ NSString *requestUrl = @"http://www.website.com/webservice.php"; NSString *soapMessage = @"the soap message"; //website and soapmessage are valid in original code. NSError **error; NSURLResponse *response; //Convert parameter string to url NSURL *url = [NSURL URLWithString:requestUrl]; NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:10]; NSString *msgLength = [NSString stringWithFormat:@"%d", [soapMessage length]]; //Create an XML message for webservice [theRequest addValue: @"text/xml; charset=utf-8" forHTTPHeaderField:@"Content-Type"]; [theRequest addValue: msgLength forHTTPHeaderField:@"Content-Length"]; [theRequest setHTTPMethod:@"POST"]; [theRequest setHTTPBody: [soapMessage dataUsingEncoding:NSUTF8StringEncoding]]; NSData *webData = [NSURLConnection sendSynchronousRequest:theRequest returningResponse:&response error:error]; } I tried not to release a thing, because what i read on the net is it's almost always a memory thing. When i debug the code (NSZombieEnabled = YES) this is what i get: [Session started at 2010-05-31 15:56:13 +0200.] GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin".sharedlibrary apply-load-rules all Attaching to process 19856. test(19856) malloc: recording malloc stacks to disk using standard recorder test(19856) malloc: enabling scribbling to detect mods to free blocks test(19856) malloc: process 19832 no longer exists, stack logs deleted from /tmp/stack-logs.19832.test.w9Ek4L.index test(19856) malloc: stack logs being written into /tmp/stack-logs.19856.test.URRpQF.index Program received signal: “EXC_BAD_ACCESS”. Does anybody have a clue?? Thanks a lot! Lars

    Read the article

  • NSZombieEnabled breaking working code?

    - by Gordon Fontenot
    I have the following method in UIImageManipulation.m: +(UIImage *)scaleImage:(UIImage *)source toSize:(CGSize)size { UIImage *scaledImage = nil; if (source != nil) { UIGraphicsBeginImageContext(size); [source drawInRect:CGRectMake(0, 0, size.width, size.height)]; scaledImage = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); } return scaledImage; } I am calling it in a different view with: imageFromFile = [UIImageManipulator scaleImage:imageFromFile toSize:imageView.frame.size]; (imageView is a UIImageView allocated earlier) This is working great in my code. I resizes the image perfectly, and throws zero errors. I also don't have anything pop up under build - analyze. But the second I turn on NSZombieEnabled to debug a different EXC_BAD_ACCESS issue, the code breaks. Every single time. I can turn NSZombieEnabled off, code runs great. I turn it on, and boom. Broken. I comment out the call, and it works again. Every single time, it gives me an error in the console: -[UIImage release]: message sent to deallocated instance 0x3b1d600. This error doesn't appear if `NSZombieEnabled is turned off. Any ideas? --EDIT-- Ok, This is killing me. I have stuck breakpoints everywhere I can, and I still cannot get a hold of this thing. Here is the full code when I call the scaleImage method: -(void)setupImageButton { UIImage *imageFromFile; if (object.imageAttribute == nil) { imageFromFile = [UIImage imageNamed:@"no-image.png"]; } else { imageFromFile = object.imageAttribute; } UIImage *scaledImage = [UIImageManipulator scaleImage:imageFromFile toSize:imageButton.frame.size]; UIImage *roundedImage = [UIImageManipulator makeRoundCornerImage:scaledImage :10 :10 withBorder:YES]; [imageButton setBackgroundImage:roundedImage forState:UIControlStateNormal]; } The other UIImageManipulator method (makeRoundCornerImage) shouldn't be causing the error, but just in case I'm overlooking something, I threw the entire file up on github here. It's something about this method though. Has to be. If I comment it out, it works great. If I leave it in, Error. But it doesn't throw errors with NSZombieEnabled turned off ever.

    Read the article

  • How to debug EXC_BAD_ACCESS that occurs only on release target for an iPhone app?

    - by Bobby Moretti
    I'm developing an iPhone application. I have an EXC_BAD_ACCESS that occurs only in the release target; when I build the debug target the exception does not occur. However, when I set the NSZombieEnabled environment variable to YES, I still get the EXC_BAD_ACCESS with no further information. Is it even possible for NSZombieEnabled to work when executing the release target? I don't see why not, since gdb is running in both cases... Update: here is a printout of the top of the stack: #0 0x33369ebc in objc_msgSend () #1 0x3144f968 in -[EAInputStream _streamEventTrigger] () #2 0x3144fe78 in __streamEventTrigger () #3 0x338ae3a6 in CFRunLoopRunSpecific () #4 0x338adc1e in CFRunLoopRunInMode () #5 0x32ed6966 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #6 0x00005b06 in -[IOStreamDelegate removeMsg:] (self=0x142cc0, _cmd=<value temporarily unavailable, due to optimizations>, message=0x2fffe544) at /Users/robertmoretti/Documents/XXXXXXX/IOStreamDelegate.m:191 Here is a gdb session from inside the objc_msgSend call at the top: (gdb) p/x $r0 $6 = 0x3100000 (gdb) x/s $r1 0x32d7cff8: "release" (gdb) disassemble $pc Dump of assembler code for function objc_msgSend: 0x33369ea8 <objc_msgSend+0>: teq r0, #0 ; 0x0 0x33369eac <objc_msgSend+4>: moveq r1, #0 ; 0x0 0x33369eb0 <objc_msgSend+8>: bxeq lr 0x33369eb4 <objc_msgSend+12>: push {r3, r4, r5, r6} 0x33369eb8 <objc_msgSend+16>: ldr r4, [r0] 0x33369ebc <objc_msgSend+20>: ldr r5, [r4, #8] 0x33369ec0 <objc_msgSend+24>: ldr r6, [r5] 0x33369ec4 <objc_msgSend+28>: add r3, r5, #8 ; 0x8 0x33369ec8 <objc_msgSend+32>: and r5, r6, r1, lsr #2 0x33369ecc <objc_msgSend+36>: ldr r4, [r3, r5, lsl #2] 0x33369ed0 <objc_msgSend+40>: teq r4, #0 ; 0x0 0x33369ed4 <objc_msgSend+44>: add r5, r5, #1 ; 0x1 0x33369ed8 <objc_msgSend+48>: beq 0x33369efc <objc_msgSend+84> 0x33369edc <objc_msgSend+52>: ldr r12, [r4] 0x33369ee0 <objc_msgSend+56>: teq r1, r12 0x33369ee4 <objc_msgSend+60>: and r5, r5, r6 0x33369ee8 <objc_msgSend+64>: bne 0x33369ecc <objc_msgSend+36> 0x33369eec <objc_msgSend+68>: ldr r12, [r4, #8] 0x33369ef0 <objc_msgSend+72>: teq r4, r4 0x33369ef4 <objc_msgSend+76>: pop {r3, r4, r5, r6} 0x33369ef8 <objc_msgSend+80>: bx r12 0x33369efc <objc_msgSend+84>: pop {r3, r4, r5, r6} 0x33369f00 <objc_msgSend+88>: b 0x33369f04 <objc_msgSend_uncached> End of assembler dump. (gdb) p/x *$r0 $9 = 0x0 The exception occurs on the line 0x33369ebc <objc_msgSend+20>: ldr r5, [r4, #8]. r4 has just been given the value pointed to by r0, which happens to be 0. I am wondering what is supposed to be in the memory region of 0x3100000. Here's a memory dump of that area: (gdb) x/256w 0x3100000 0x3100000: 0x00000000 0x0000a293 0xaa650505 0x00000000 0x3100010: 0x0000a294 0xaa670505 0x00000000 0x0000a295 0x3100020: 0xaa690505 0x00000000 0x0000a296 0xaa6b0505 0x3100030: 0x00000000 0x0000a297 0xaa6d0505 0x00000000 0x3100040: 0x0000a298 0xaa6f0505 0x00000000 0x0000a299 0x3100050: 0xaa710505 0x00000000 0x0000a29a 0xaa730505 0x3100060: 0x00000000 0x0000a29b 0xaa750505 0x00000000 0x3100070: 0x0000a29c 0xaa770505 0x00000000 0x0000a29d 0x3100080: 0xaa790505 0x00000000 0x0000a29e 0xaa7b0505 0x3100090: 0x00000000 0x0000a29f 0xaa7d0505 0x00000000 0x31000a0: 0x0000a2a0 0xaa7f0505 0x00000000 0x0000a2a1 0x31000b0: 0xaa810505 0x00000000 0x0000a2a2 0xaa830505 0x31000c0: 0x00000000 0x0000a2a3 0xaa850505 0x00000000 0x31000d0: 0x0000a2a4 0xaa870505 0x00000000 0x0000a2a5 0x31000e0: 0xaa890505 0x00000000 0x0000a2a6 0xaa8b0505 0x31000f0: 0x00000000 0x0000a2a7 0xaa8d0505 0x00000000 0x3100100: 0x0000a2a8 0xaa8f0505 0x00000000 0x0000a2a9 0x3100110: 0xaa910505 0x00000000 0x0000a2aa 0xaa930505 0x3100120: 0x00000000 0x0000a2ab 0xaa950505 0x00000000 0x3100130: 0x0000a2ac 0xaa970505 0x00000000 0x0000a2ad 0x3100140: 0xaa990505 0x00000000 0x0000a2ae 0xaa9b0505 0x3100150: 0x00000000 0x0000a2af 0xaa9d0505 0x00000000 0x3100160: 0x0000a2b0 0xaa9f0505 0x00000000 0x0000a2b1 0x3100170: 0xaaa10505 0x00000000 0x0000a2b2 0xaaa30505 0x3100180: 0x00000000 0x0000a2b3 0xaaa50505 0x00000000 0x3100190: 0x0000a2b4 0xaaa70505 0x00000000 0x0000a2b5 0x31001a0: 0xaaa90505 0x00000000 0x0000a2b6 0xaaab0505 0x31001b0: 0x00000000 0x0000a2b7 0xaaad0505 0x00000000 0x31001c0: 0x0000a2b8 0xaaaf0505 0x00000000 0x0000a2b9 0x31001d0: 0xaab10505 0x00000000 0x0000a2ba 0xaab30505 0x31001e0: 0x00000000 0x0000a2bb 0xaab50505 0x00000000 0x31001f0: 0x0000a2bc 0xaab70505 0x00000000 0x0000a2bd 0x3100200: 0xaab90505 0x00000000 0x0000a2be 0xaabb0505 0x3100210: 0x00000000 0x0000a2bf 0xaabd0505 0x00000000 0x3100220: 0x0000a2c0 0xaabf0505 0x00000000 0x0000a2c1 0x3100230: 0xaac10505 0x00000000 0x0000a2c2 0xaac30505 0x3100240: 0x00000000 0x0000a2c3 0xaac50505 0x00000000 0x3100250: 0x0000a2c4 0xaac70505 0x00000000 0x0000a2c5 0x3100260: 0xaac90505 0x00000000 0x0000a2c6 0xaacb0505 0x3100270: 0x00000000 0x0000a2c7 0xaacd0505 0x00000000 0x3100280: 0x0000a2c8 0xaacf0505 0x00000000 0x0000a2c9 0x3100290: 0xaad10505 0x00000000 0x0000a2ca 0xaad30505 0x31002a0: 0x00000000 0x0000a2cb 0xaad50505 0x00000000 0x31002b0: 0x0000a2cc 0xaad70505 0x00000000 0x0000a2cd 0x31002c0: 0xaad90505 0x00000000 0x0000a2ce 0xaadb0505 0x31002d0: 0x00000000 0x0000a2cf 0xaadd0505 0x00000000 0x31002e0: 0x0000a2d0 0xaadf0505 0x00000000 0x0000a2d1 0x31002f0: 0xaae10505 0x00000000 0x0000a2d2 0xaae30505 0x3100300: 0x00000000 0x0000a2d3 0xaae50505 0x00000000 0x3100310: 0x0000a2d4 0xaae70505 0x00000000 0x0000a2d5 0x3100320: 0xaae90505 0x00000000 0x0000a2d6 0xaaeb0505 0x3100330: 0x00000000 0x0000a2d7 0xaaed0505 0x00000000 0x3100340: 0x0000a2d8 0xaaef0505 0x00000000 0x0000a2d9 0x3100350: 0xaaf10505 0x00000000 0x0000a2da 0xaaf30505 0x3100360: 0x00000000 0x0000a2db 0xaaf50505 0x00000000 0x3100370: 0x0000a2dc 0xaaf70505 0x00000000 0x0000a2dd 0x3100380: 0xaaf90505 0x00000000 0x0000a2de 0xaafb0505 0x3100390: 0x00000000 0x0000a2df 0xaafd0505 0x00000000 0x31003a0: 0x0000a2e0 0xab050505 0x00000000 0x0000a2e1 0x31003b0: 0xab070505 0x00000000 0x0000a2e2 0xab090505 0x31003c0: 0x00000000 0x0000a2e3 0xab0b0505 0x00000000 0x31003d0: 0x0000a2e4 0xab0d0505 0x00000000 0x0000a2e5 0x31003e0: 0xab0f0505 0x00000000 0x0000a2e6 0xab110505 0x31003f0: 0x00000000 0x0000a2e7 0xab130505 0x00000000 I don't really know what else to try; hopefully someone with more iphone experience will be able to recognize this memory as something meaningful.

    Read the article

  • How to set NSZombieEnabled for debugging EXC_BAD_ACCESS on release target for an iPhone app?

    - by Bobby Moretti
    I'm developing an iPhone application. I have an EXC_BAD_ACCESS that occurs only in the release target; when I build the debug target the exception does not occur. However, when I set the NSZombieEnabled environment variable to YES, I still get the EXC_BAD_ACCESS with no further information. Is it even possible for NSZombieEnabled to work when executing the release target? I don't see why not, since gdb is running in both cases...

    Read the article

  • Debugging EXC_BAD_ACCESS that occurs only on release target for an iPhone app?

    - by Bobby Moretti
    I'm developing an iPhone application. I have an EXC_BAD_ACCESS that occurs only in the release target; when I build the debug target the exception does not occur. However, when I set the NSZombieEnabled environment variable to YES, I still get the EXC_BAD_ACCESS with no further information. Is it even possible for NSZombieEnabled to work when executing the release target? I don't see why not, since gdb is running in both cases... Update: here is a printout of the top of the stack: #0 0x33369ebc in objc_msgSend () #1 0x3144f968 in -[EAInputStream _streamEventTrigger] () #2 0x3144fe78 in __streamEventTrigger () #3 0x338ae3a6 in CFRunLoopRunSpecific () #4 0x338adc1e in CFRunLoopRunInMode () #5 0x32ed6966 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #6 0x00005b06 in -[IOStreamDelegate removeMsg:] (self=0x142cc0, _cmd=<value temporarily unavailable, due to optimizations>, message=0x2fffe544) at /Users/robertmoretti/Documents/XXXXXXX/IOStreamDelegate.m:191 Here is a gdb session from inside the objc_msgSend call at the top: (gdb) p/x $r0 $6 = 0x3100000 (gdb) x/s $r1 0x32d7cff8: "release" (gdb) disassemble $pc Dump of assembler code for function objc_msgSend: 0x33369ea8 <objc_msgSend+0>: teq r0, #0 ; 0x0 0x33369eac <objc_msgSend+4>: moveq r1, #0 ; 0x0 0x33369eb0 <objc_msgSend+8>: bxeq lr 0x33369eb4 <objc_msgSend+12>: push {r3, r4, r5, r6} 0x33369eb8 <objc_msgSend+16>: ldr r4, [r0] 0x33369ebc <objc_msgSend+20>: ldr r5, [r4, #8] 0x33369ec0 <objc_msgSend+24>: ldr r6, [r5] 0x33369ec4 <objc_msgSend+28>: add r3, r5, #8 ; 0x8 0x33369ec8 <objc_msgSend+32>: and r5, r6, r1, lsr #2 0x33369ecc <objc_msgSend+36>: ldr r4, [r3, r5, lsl #2] 0x33369ed0 <objc_msgSend+40>: teq r4, #0 ; 0x0 0x33369ed4 <objc_msgSend+44>: add r5, r5, #1 ; 0x1 0x33369ed8 <objc_msgSend+48>: beq 0x33369efc <objc_msgSend+84> 0x33369edc <objc_msgSend+52>: ldr r12, [r4] 0x33369ee0 <objc_msgSend+56>: teq r1, r12 0x33369ee4 <objc_msgSend+60>: and r5, r5, r6 0x33369ee8 <objc_msgSend+64>: bne 0x33369ecc <objc_msgSend+36> 0x33369eec <objc_msgSend+68>: ldr r12, [r4, #8] 0x33369ef0 <objc_msgSend+72>: teq r4, r4 0x33369ef4 <objc_msgSend+76>: pop {r3, r4, r5, r6} 0x33369ef8 <objc_msgSend+80>: bx r12 0x33369efc <objc_msgSend+84>: pop {r3, r4, r5, r6} 0x33369f00 <objc_msgSend+88>: b 0x33369f04 <objc_msgSend_uncached> End of assembler dump. (gdb) p/x *$r0 $9 = 0x0 The exception occurs on the line 0x33369ebc <objc_msgSend+20>: ldr r5, [r4, #8]. r4 has just been given the value pointed to by r0, which happens to be 0. I am wondering what is supposed to be in the memory region of 0x3100000. Here's a memory dump of that area: (gdb) x/256w 0x3100000 0x3100000: 0x00000000 0x0000a293 0xaa650505 0x00000000 0x3100010: 0x0000a294 0xaa670505 0x00000000 0x0000a295 0x3100020: 0xaa690505 0x00000000 0x0000a296 0xaa6b0505 0x3100030: 0x00000000 0x0000a297 0xaa6d0505 0x00000000 0x3100040: 0x0000a298 0xaa6f0505 0x00000000 0x0000a299 0x3100050: 0xaa710505 0x00000000 0x0000a29a 0xaa730505 0x3100060: 0x00000000 0x0000a29b 0xaa750505 0x00000000 0x3100070: 0x0000a29c 0xaa770505 0x00000000 0x0000a29d 0x3100080: 0xaa790505 0x00000000 0x0000a29e 0xaa7b0505 0x3100090: 0x00000000 0x0000a29f 0xaa7d0505 0x00000000 0x31000a0: 0x0000a2a0 0xaa7f0505 0x00000000 0x0000a2a1 0x31000b0: 0xaa810505 0x00000000 0x0000a2a2 0xaa830505 0x31000c0: 0x00000000 0x0000a2a3 0xaa850505 0x00000000 0x31000d0: 0x0000a2a4 0xaa870505 0x00000000 0x0000a2a5 0x31000e0: 0xaa890505 0x00000000 0x0000a2a6 0xaa8b0505 0x31000f0: 0x00000000 0x0000a2a7 0xaa8d0505 0x00000000 0x3100100: 0x0000a2a8 0xaa8f0505 0x00000000 0x0000a2a9 0x3100110: 0xaa910505 0x00000000 0x0000a2aa 0xaa930505 0x3100120: 0x00000000 0x0000a2ab 0xaa950505 0x00000000 0x3100130: 0x0000a2ac 0xaa970505 0x00000000 0x0000a2ad 0x3100140: 0xaa990505 0x00000000 0x0000a2ae 0xaa9b0505 0x3100150: 0x00000000 0x0000a2af 0xaa9d0505 0x00000000 0x3100160: 0x0000a2b0 0xaa9f0505 0x00000000 0x0000a2b1 0x3100170: 0xaaa10505 0x00000000 0x0000a2b2 0xaaa30505 0x3100180: 0x00000000 0x0000a2b3 0xaaa50505 0x00000000 0x3100190: 0x0000a2b4 0xaaa70505 0x00000000 0x0000a2b5 0x31001a0: 0xaaa90505 0x00000000 0x0000a2b6 0xaaab0505 0x31001b0: 0x00000000 0x0000a2b7 0xaaad0505 0x00000000 0x31001c0: 0x0000a2b8 0xaaaf0505 0x00000000 0x0000a2b9 0x31001d0: 0xaab10505 0x00000000 0x0000a2ba 0xaab30505 0x31001e0: 0x00000000 0x0000a2bb 0xaab50505 0x00000000 0x31001f0: 0x0000a2bc 0xaab70505 0x00000000 0x0000a2bd 0x3100200: 0xaab90505 0x00000000 0x0000a2be 0xaabb0505 0x3100210: 0x00000000 0x0000a2bf 0xaabd0505 0x00000000 0x3100220: 0x0000a2c0 0xaabf0505 0x00000000 0x0000a2c1 0x3100230: 0xaac10505 0x00000000 0x0000a2c2 0xaac30505 0x3100240: 0x00000000 0x0000a2c3 0xaac50505 0x00000000 0x3100250: 0x0000a2c4 0xaac70505 0x00000000 0x0000a2c5 0x3100260: 0xaac90505 0x00000000 0x0000a2c6 0xaacb0505 0x3100270: 0x00000000 0x0000a2c7 0xaacd0505 0x00000000 0x3100280: 0x0000a2c8 0xaacf0505 0x00000000 0x0000a2c9 0x3100290: 0xaad10505 0x00000000 0x0000a2ca 0xaad30505 0x31002a0: 0x00000000 0x0000a2cb 0xaad50505 0x00000000 0x31002b0: 0x0000a2cc 0xaad70505 0x00000000 0x0000a2cd 0x31002c0: 0xaad90505 0x00000000 0x0000a2ce 0xaadb0505 0x31002d0: 0x00000000 0x0000a2cf 0xaadd0505 0x00000000 0x31002e0: 0x0000a2d0 0xaadf0505 0x00000000 0x0000a2d1 0x31002f0: 0xaae10505 0x00000000 0x0000a2d2 0xaae30505 0x3100300: 0x00000000 0x0000a2d3 0xaae50505 0x00000000 0x3100310: 0x0000a2d4 0xaae70505 0x00000000 0x0000a2d5 0x3100320: 0xaae90505 0x00000000 0x0000a2d6 0xaaeb0505 0x3100330: 0x00000000 0x0000a2d7 0xaaed0505 0x00000000 0x3100340: 0x0000a2d8 0xaaef0505 0x00000000 0x0000a2d9 0x3100350: 0xaaf10505 0x00000000 0x0000a2da 0xaaf30505 0x3100360: 0x00000000 0x0000a2db 0xaaf50505 0x00000000 0x3100370: 0x0000a2dc 0xaaf70505 0x00000000 0x0000a2dd 0x3100380: 0xaaf90505 0x00000000 0x0000a2de 0xaafb0505 0x3100390: 0x00000000 0x0000a2df 0xaafd0505 0x00000000 0x31003a0: 0x0000a2e0 0xab050505 0x00000000 0x0000a2e1 0x31003b0: 0xab070505 0x00000000 0x0000a2e2 0xab090505 0x31003c0: 0x00000000 0x0000a2e3 0xab0b0505 0x00000000 0x31003d0: 0x0000a2e4 0xab0d0505 0x00000000 0x0000a2e5 0x31003e0: 0xab0f0505 0x00000000 0x0000a2e6 0xab110505 0x31003f0: 0x00000000 0x0000a2e7 0xab130505 0x00000000 I don't really know what else to try; hopefully someone with more iphone experience will be able to recognize this memory as something meaningful.

    Read the article

  • How to NSZombieEnabled for debugging EXC_BAD_ACCESS on release target for an iPhone app?

    - by Bobby Moretti
    I'm developing an iPhone application. I have an EXC_BAD_ACCESS that occurs only in the release target; when I build the debug target the exception does not occur. However, when I set the NSZombieEnabled environment variable to YES, I still get the EXC_BAD_ACCESS with no further information. Is it even possible for NSZombieEnabled to work when executing the release target? I don't see why not, since gdb is running in both cases...

    Read the article

  • iPhone - making the crash information more specific

    - by Digital Robot
    I have an app that is crashing at some point. Even with NSZombieEnabled turned on, the only thing I see is this message on the console: : * -[CFRunLoopTimer release]: message sent to deallocated instance 0x4cb34e0 but as the app is crashed, there's no way to know what object is this and the thread overview is not helping that much. #0 0x34a80466 in objc_msgSend #1 0x357e53c8 in CFRelease #2 0x357f3976 in __CFTypeCollectionRelease #3 0x3580c0b6 in __CFSetReleaseValue #4 0x357e6a5c in __CFBasicHashDrain #5 0x357e6900 in __CFSetDeallocate #6 0x357e54b6 in _CFRelease #7 0x357e53dc in CFRelease #8 0x3580c098 in -[__NSCFSet release] #9 0x3570f3be in -[_NSFaultingMutableSet dealloc] #10 0x3570f260 in -[_NSFaultingMutableSet release] #11 0x35702480 in -[NSManagedObject(_NSInternalMethods) _clearRawPropertiesWithHint:] #12 0x357022a8 in -[NSFaultHandler turnObject:intoFaultWithContext:] #13 0x35703dc0 in -[NSManagedObject dealloc] #14 0x356eab34 in -[_PFManagedObjectReferenceQueue _processReferenceQueue:] #15 0x357127d6 in _performRunLoopAction #16 0x3580ac58 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ #17 0x3580aacc in __CFRunLoopDoObservers #18 0x358020ca in __CFRunLoopRun #19 0x35801c86 in CFRunLoopRunSpecific #20 0x35801b8e in CFRunLoopRunInMode #21 0x320c84aa in GSEventRunModal #22 0x320c8556 in GSEventRun #23 0x341dc328 in -[UIApplication _run] #24 0x341d9e92 in UIApplicationMain #25 0x00002e02 in main at main.m:14 it appears to be something related to core data, but knowing that doesn't help that much, because the app is all core data based and it crashes when I am not doing anything related to core data. is there a way to make the debugger more specific? thanks

    Read the article

  • Memory over-release problem when I am animating UIView

    - by Sheehan Alam
    I have enabled NSZombie's and I am getting the following message in my console when I am running my application: *** -[UIViewAnimationState release]: message sent to deallocated instance 0xf96d7e0 Here is the method that is performing the animation -(void)loadAvatar:(STObject*)st { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; avatar.alpha = 0; avatar.frame = avatarRectSmall; avatar.image = [ImageCache getMemoryCachedImageAtUrl:st.avatar_url]; [UIView beginAnimations:nil context:nil]; [UIView setAnimationDuration:.50]; avatar.frame = avatarRectNormal; [avatar setAlpha:1]; [UIView commitAnimations]; [pool release]; pool = nil; } I don't always get a crash, only sometimes. I'm wondering what is getting released?

    Read the article

  • NSZombieEnabled hides EXC_BAD_ACCESS error entirely

    - by David Liu
    So I have a subclass of a UIView that starts causing EXC_BAD_ACCESS errors when I go through a specific set of conditions (run on iPad instead of iPhone or simulator, first login only). It throws the exception when the UIView subclass gets deallocated, during the last line, where I have [super dealloc]. I heard about using NSZombieEnabled, so I tossed that on to see if I could get any more information about it, but now it hides the error completely! Does anyone know a bit more about this type of situation? I thought NSZombie would start spewing stuff into my console like before, but I'm hoping that the nonexistance of errors would tell me some sort of information as well.

    Read the article

  • EXC_BAD_ACCESS when executing ABAddressBookSave !

    - by Horatiu Paraschiv
    Hi everybody, I'm trying to create a new contact and add it to the AddressBook but when I get to the ABAddressSave line of code I get EXC_BAD_ACCESS. I cannot see what am I doing wrong, I enabled NSZombie to check if this is a memory related error but it didn't spot any. Can anybody tell me what is wrong with this code? Thank you in advance! CFErrorRef error = NULL; ABAddressBookRef iPhoneAddressBook = ABAddressBookCreate(); ABRecordRef newRecord = ABPersonCreate(); ABRecordSetValue(newRecord, kABPersonFirstNameProperty, @"Xxxxxx", &error); ABRecordSetValue(newRecord, kABPersonURLProperty, @"Yyyyyy", &error); //Add phone numbers to record ABMutableMultiValueRef phones = ABMultiValueCreateMutable(kABMultiStringPropertyType); ABMultiValueAddValueAndLabel(phones, @"1-555-555-5555", kABWorkLabel, NULL); ABRecordSetValue(newRecord, kABPersonPhoneProperty, phones, &error); CFRelease(phones); //Add email address to record ABMutableMultiValueRef emails = ABMultiValueCreateMutable(kABMultiStringPropertyType); ABMultiValueAddValueAndLabel(emails, @"[email protected]", kABWorkLabel, NULL); ABRecordSetValue(newRecord, kABPersonEmailProperty, emails, &error); CFRelease(emails); ABMutableMultiValueRef multiAddress = ABMultiValueCreateMutable(kABMultiDictionaryPropertyType); NSMutableDictionary *addressDict = [[NSMutableDictionary alloc] init]; [addressDict setObject:@"xxx1" forKey:(NSString *)kABPersonAddressStreetKey]; [addressDict setObject:@"xxx2" forKey:(NSString *)kABPersonAddressCityKey]; [addressDict setObject:@"xxx3" forKey:(NSString *)kABPersonAddressStateKey]; [addressDict setObject:@"xxx4" forKey:(NSString *)kABPersonAddressZIPKey]; ABMultiValueAddValueAndLabel(multiAddress, addressDict, kABWorkLabel, NULL); ABRecordSetValue(newRecord, kABPersonAddressProperty, multiAddress, &error); CFRelease(multiAddress); [addressDict release]; ABAddressBookAddRecord(iPhoneAddressBook, newRecord, &error); ABAddressBookSave(iPhoneAddressBook, NULL); if(error != nil){ NSLog(@"Error creating contact:%@", error); }

    Read the article

  • How to make a custom NSFormatter work correctly on Snow Leopard?

    - by Nathan
    I have a custom NSFormatter attached to several NSTextFields who's only purpose is to uppercase the characters as they are typed into field. The entire code for my formatter is included below. The stringForObjectValue() and getObjectValue() implementations are no-ops and taken pretty much directly out of Apple's documentation. I'm using the isPartialStringValid() method to return an uppercase version of the string. This code works correctly in 10.4 and 10.5. When I run it on 10.6, I get "strange" behaviour where text fields aren't always render the characters that are typed and sometimes are just displaying garbage. I've tried enabling NSZombie detection and running under Instruments but nothing was reported. I see errors like the following in "Console": HIToolbox: ignoring exception '*** -[NSCFString replaceCharactersInRange:withString:]: Range or index out of bounds' that raised inside Carbon event dispatch ( 0 CoreFoundation 0x917ca58a __raiseError + 410 1 libobjc.A.dylib 0x94581f49 objc_exception_throw + 56 2 CoreFoundation 0x917ca2b8 +[NSException raise:format:arguments:] + 136 3 CoreFoundation 0x917ca22a +[NSException raise:format:] + 58 4 Foundation 0x9140f528 mutateError + 218 5 AppKit 0x9563803a -[NSCell textView:shouldChangeTextInRange:replacementString:] + 852 6 AppKit 0x95636cf1 -[NSTextView(NSSharing) shouldChangeTextInRanges:replacementStrings:] + 1276 7 AppKit 0x95635704 -[NSTextView insertText:replacementRange:] + 667 8 AppKit 0x956333bb -[NSTextInputContext handleTSMEvent:] + 2657 9 AppKit 0x95632949 _NSTSMEventHandler + 209 10 HIToolbox 0x93379129 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1567 11 HIToolbox 0x933783f0 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 411 12 HIToolbox 0x9339aa81 SendEventToEventTarget + 52 13 HIToolbox 0x933fc952 SendTSMEvent + 82 14 HIToolbox 0x933fc2cf SendUnicodeTextAEToUnicodeDoc + 700 15 HIToolbox 0x933fbed9 TSMKeyEvent + 998 16 HIToolbox 0x933ecede TSMProcessRawKeyEvent + 2515 17 AppKit 0x95632228 -[NSTextInputContext handleEvent:] + 1453 18 AppKit 0x9562e088 -[NSView interpretKeyEvents:] + 209 19 AppKit 0x95631b45 -[NSTextView keyDown:] + 751 20 AppKit 0x95563194 -[NSWindow sendEvent:] + 5757 21 AppKit 0x9547bceb -[NSApplication sendEvent:] + 6431 22 AppKit 0x9540f6fb -[NSApplication run] + 917 23 AppKit 0x95407735 NSApplicationMain + 574 24 macsetup 0x00001f9f main + 24 25 macsetup 0x00001b75 start + 53 ) Can anybody shed some light on what is happening? Am I just using NSFormatter incorrectly? -(NSString*) stringForObjectValue:(id)object { if( ![object isKindOfClass: [ NSString class ] ] ) { return nil; } return [ NSString stringWithString: object ]; } -(BOOL)getObjectValue: (id*)object forString: string errorDescription:(NSString**)error { if( object ) { *object = [ NSString stringWithString: string ]; return YES; } return NO; } -(BOOL) isPartialStringValid: (NSString*) cStr newEditingString: (NSString**) nStr errorDescription: (NSString**) error { *nStr = [NSString stringWithString: [cStr uppercaseString]]; return NO; }

    Read the article

  • MapView EXC_BAD_ACCESS (SIGSEGV) and KERN_INVALID_ADDRESS

    - by user768113
    I'm having some 'issues' with my application... well, it crashes in an UIViewController that is presented modally, there the user enters information through UITextFields and his location is tracked by a MapView. Lets call this view controller "MapViewController" When the user submits the form, I call a different ViewController - modally again - that processes this info and a third one answers accordingly, then go back to a MenuVC using unwinding segues, which then calls MapViewController and so on. This sequence is repeated many times, but it always crashes in MapViewController. Looking at the crash log, I think that the MapView can be the problem of this or some element in the UI (because of the UIKit framework). I tried to use NSZombie in order to track a memory issue but it doesn't give me a clue about whats happening. Here is the crash log Hardware Model: iPad3,4 Process: MyApp [2253] OS Version: iOS 6.1.3 (10B329) Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000044 Crashed Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 IMGSGX554GLDriver 0x328b9be0 0x328ac000 + 56288 1 IMGSGX554GLDriver 0x328b9b8e 0x328ac000 + 56206deallocated instance 2 IMGSGX554GLDriver 0x328bc2f2 0x328ac000 + 66290 3 IMGSGX554GLDriver 0x328baf44 0x328ac000 + 61252 4 libGPUSupportMercury.dylib 0x370f86be 0x370f6000 + 9918 5 GLEngine 0x34ce8bd2 0x34c4f000 + 629714 6 GLEngine 0x34cea30e 0x34c4f000 + 635662 7 GLEngine 0x34c8498e 0x34c4f000 + 219534 8 GLEngine 0x34c81394 0x34c4f000 + 205716 9 VectorKit 0x3957f4de 0x394c7000 + 754910 10 VectorKit 0x3955552e 0x394c7000 + 582958 11 VectorKit 0x394d056e 0x394c7000 + 38254 12 VectorKit 0x394d0416 0x394c7000 + 37910 13 VectorKit 0x394cb7ca 0x394c7000 + 18378 14 VectorKit 0x394c9804 0x394c7000 + 10244 15 VectorKit 0x394c86a2 0x394c7000 + 5794 16 QuartzCore 0x354a07a4 0x35466000 + 239524 17 QuartzCore 0x354a06fc 0x35466000 + 239356 18 IOMobileFramebuffer 0x376f8fd4 0x376f4000 + 20436 19 IOKit 0x344935aa 0x34490000 + 13738 20 CoreFoundation 0x33875888 0x337e9000 + 575624 21 CoreFoundation 0x338803e4 0x337e9000 + 619492 22 CoreFoundation 0x33880386 0x337e9000 + 619398 23 CoreFoundation 0x3387f20a 0x337e9000 + 614922 24 CoreFoundation 0x337f2238 0x337e9000 + 37432 25 CoreFoundation 0x337f20c4 0x337e9000 + 37060 26 GraphicsServices 0x373ad336 0x373a8000 + 21302 27 UIKit 0x3570e2b4 0x356b7000 + 357044 28 MyApp 0x000ea12e 0xe9000 + 4398 29 MyApp 0x000ea0e4 0xe9000 + 4324 I think thats all, additionally, I would like to ask you: if you are using unwind segues then you are releasing view controllers from the memory heap, right? Meanwhile, performing segues let you instantiate those controllers. Technically, MenuVC should be the only VC alive in the heap during the app life cycle if you understand me.

    Read the article

  • TableViewCell autorelease error

    - by iAm
    OK, for two days now i have been trying to solve an error i have inside the cellForRowAtIndex method, let start by saying that i have tracked down the bug to this method, the error is [CFDictionary image] or [Not a Type image] message sent to deallocated instance. I know about the debug flags, NSZombie, MallocStack, and others, they helped me narrow it down to this method and why, but I do not know how to solve besides a redesign of the app UI. SO what am i trying to do, well for this block of code, displays a purchase detail, which contains items, the items are in there own section, now when in edit mode, there appears a cell at the bottom of the items section with a label of "Add new Item", and this button will present a modal view of the add item controller, item is added and the view returns to the purchase detail screen, with the just added item in the section just above the "add new Item" cell, the problem happens when i scroll the item section off screen and back into view the app crashes with EXC_BAD_ACCESS, or even if i don't scroll and instead hit the back button on the navBar, still the same error. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell = nil; switch (indexPath.section) { case PURCHASE_SECTION: { static NSString *cellID = @"GenericCell"; cell = [tableView dequeueReusableCellWithIdentifier:cellID]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleValue2 reuseIdentifier:cellID] autorelease]; cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator; } switch (indexPath.row) { case CATEGORY_ROW: cell.textLabel.text = @"Category:"; cell.detailTextLabel.text = [self.purchase.category valueForKey:@"name"]; cell.accessoryType = UITableViewCellAccessoryNone; cell.editingAccessoryType = UITableViewCellAccessoryDisclosureIndicator; break; case TYPE_ROW: cell.textLabel.text = @"Type:"; cell.detailTextLabel.text = [self.purchase.type valueForKey:@"name"]; cell.accessoryType = UITableViewCellAccessoryNone; cell.editingAccessoryType = UITableViewCellAccessoryDisclosureIndicator; break; case VENDOR_ROW: cell.textLabel.text = @"Payment:"; cell.detailTextLabel.text = [self.purchase.vendor valueForKey:@"name"]; cell.accessoryType = UITableViewCellAccessoryNone; cell.editingAccessoryType = UITableViewCellAccessoryDisclosureIndicator; break; case NOTES_ROW: cell.textLabel.text = @"Notes"; cell.editingAccessoryType = UITableViewCellAccessoryNone; break; default: break; } break; } case ITEMS_SECTION: { NSUInteger itemsCount = [items count]; if (indexPath.row < itemsCount) { static NSString *itemsCellID = @"ItemsCell"; cell = [tableView dequeueReusableCellWithIdentifier:itemsCellID]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:itemsCellID] autorelease]; cell.accessoryType = UITableViewCellAccessoryNone; } singleItem = [self.items objectAtIndex:indexPath.row]; cell.textLabel.text = singleItem.name; cell.detailTextLabel.text = [singleItem.amount formattedDataDisplay]; cell.imageView.image = [singleItem.image image]; } else { static NSString *AddItemCellID = @"AddItemCell"; cell = [tableView dequeueReusableCellWithIdentifier:AddItemCellID]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:AddItemCellID] autorelease]; cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator; } cell.textLabel.text = @"Add Item"; } break; } case LOCATION_SECTION: { static NSString *localID = @"LocationCell"; cell = [tableView dequeueReusableCellWithIdentifier:localID]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:localID] autorelease]; cell.accessoryType = UITableViewCellAccessoryNone; } cell.textLabel.text = @"Purchase Location"; cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator; cell.editingAccessoryType = UITableViewCellAccessoryNone; break; } default: break; } return cell; } the singleItem is of Modal Type PurchaseItem for core data now that i know what is causing the error, how do i solve it, I have tried everything that i know and some of what i dont know but still, no progress, please any suggestions as to how to solve this without redesign is my goal, perhaps there is an error i am doing that I cannot see, but if it's the nature of autorelease, than i will redesign.

    Read the article

1