3

I have been trying to solve this problem for 2 days now and it is driving me crazy. When Xcode launches the app it works fine, but If I manually launch the app from Springboard it crashes. The console prints out this:

Jan 20 15:26:29 unknown UIKitApplication:com.yourcompany.ThinClient[0x28cf][1119] <Notice>: ThinClient(1119,0x3db0000) malloc: *** error for object 0x643434: incorrect checksum for freed object - object was probably modified after being freed.
Jan 20 15:26:29 unknown UIKitApplication:com.yourcompany.ThinClient[0x28cf][1119] <Notice>: *** set a breakpoint in malloc_error_break to debug
Jan 20 15:26:29 unknown ThinClient[1119] <Error>: ThinClient(1119,0x3db0000) malloc: *** error for object 0x643434: incorrect checksum for freed object - object was probably modified after being freed.
    *** set a breakpoint in malloc_error_break to debug

The stack for the crashed thread (usually) looks like this, although sometimes it crashes in different spots:

Thread 5 Crashed:
0   libsystem_kernel.dylib          0x33d4da1c __pthread_kill + 8
1   libsystem_c.dylib               0x353523b4 pthread_kill + 52
2   libsystem_c.dylib               0x3534abf8 abort + 72
3   libsystem_c.dylib               0x3535e822 szone_error + 210
4   libsystem_c.dylib               0x3535e920 free_list_checksum_botch + 16
5   libsystem_c.dylib               0x35361722 tiny_malloc_from_free_list + 82
6   libsystem_c.dylib               0x35361e76 szone_malloc_should_clear + 166
7   libsystem_c.dylib               0x35362fd4 szone_malloc + 4
8   libsystem_c.dylib               0x35386230 malloc_zone_malloc + 48
9   libsystem_c.dylib               0x35386c2c malloc + 28
10  ThinClient                      0x0000590c -[MySocket readBytes:] (MySocket.m:231)
11  ThinClient                      0x00007b7e -[ThinServerTalker onSocket:readCallbackBytesWaiting:] (ThinServerTalker.m:362)
12  ThinClient                      0x000057e2 ReadDataCB (MySocket.m:201)
13  CoreFoundation                  0x33cca48a __CFSocketDoCallback + 334
14  CoreFoundation                  0x33ccb4a2 __CFSocketPerformV0 + 78
15  CoreFoundation                  0x33cc5a72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
16  CoreFoundation                  0x33cc7758 __CFRunLoopDoSources0 + 376
17  CoreFoundation                  0x33cc84e4 __CFRunLoopRun + 224
18  CoreFoundation                  0x33c58ebc CFRunLoopRunSpecific + 224
19  CoreFoundation                  0x33c9b6d2 CFRunLoopRun + 42
20  ThinClient                      0x00005656 -[MySocket _connect] (MySocket.m:160)
21  Foundation                      0x33d71382 -[NSThread main] + 38
22  Foundation                      0x33de35c6 __NSThread__main__ + 966
23  libsystem_c.dylib               0x3535230a _pthread_start + 242
24  libsystem_c.dylib               0x35353bb4 thread_start + 0

I suspect its from the application writing to memory that has already been freed, so I have already tried a few things:

  • I tried debugging the app with guard malloc, scribble, guard edges, zombie objects, malloc stack, etc..
  • I tried going to the code where the app crashed and finding an issue there ( i do not believe there is an issue there because the app crashes at different places, but they are all near each other)
  • I tried going through and commenting out all of my free() function calls.

I still have not found the problem! If anybody could please shed some light on this it would be much appreciated! Thanks! Any Suggestions?

Edit: The app will crash every time if it is launched from springboard, but if Xcode launches it, it will work fine.

Chris
  • 101
  • 2
  • 9
  • enable zombie and malloc-stack debug. This would give you more information when it crashes. Also if you are still not able to figure out, try posting the log here. – aqs Jan 20 '12 at 21:25
  • I have Zombie Objects Enabled, and Malloc Stack Enabled. The issue is that it doesn't crash when I am debugging it, but it will crash every time if I am not debugging it. – Chris Jan 20 '12 at 21:30
  • post the obj-c code which you think is related to the crash. especially MySocket,any delegates you are using etc. Also one guess would be to disable your internet and then debug, and see if it throws some light – aqs Jan 20 '12 at 21:40
  • 1
    So is the difference you launching it manually (from Springboard) vs Xcode launching it, or the presence of the debugger? – David Dunham Jan 20 '12 at 21:41
  • I just tested it. The difference is Springboard vs XCode. We are narrowing down the issue. Thanks. Any further suggestions? – Chris Jan 20 '12 at 21:55
  • Can you then attach a debugger after the fact? – David Dunham Jan 20 '12 at 22:44
  • Oh, the other thing that comes to mind: this is threaded code. Launching from Xcode attaches a debugger, and this might change timing slightly, and mask a race condition. Is there a single MySocket per thread, or is it used from another thread? – David Dunham Jan 20 '12 at 22:47
  • Good idea, but there is a single My Socket Per Thread, so I don't think there is an issue with the threads. I don't know how to attach a debugger after the fact... do you? – Chris Jan 20 '12 at 22:57
  • Product > Attach to Process. BTW, have you tried running this in Instruments, like with Leaks? (Yeah, it's a double-free, but that still does do some stuff to track allocations and all.) – David Dunham Jan 21 '12 at 00:00
  • on which iOS Version you are facing this? as in my application its coming on 5.0.1. I am also working on same. – Sagar... Jan 23 '12 at 05:36
  • 5.0.1 as well. I posted my answer! It took a while to find! Good luck! – Chris Jan 30 '12 at 21:18

1 Answers1

1

I found the issue. I was returning a direct pointer to the bytes in a NSData object from a function. I simply replaced a function called "-(char*)getBytes" with a function called "-(NSData*)getDataCopy". Get data copy instead returns an autoreleased copy of the data class.

To reiterate:

I had this:

-(char*)getBytes{
    return _data.bytes;}

and I replaced it with this

-(NSData*)getDataCopy{
return [NSData dataWithData:_data];
}

The issue was I was writing to memory that had already been released.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Chris
  • 101
  • 2
  • 9