I'm getting the following error while trying to run an iOS app I'm developing:
appname(6097,0x3e835d98) malloc: *** error for object 0x20104600: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
How can I find out which call to free() generated this error? If I add a breakpoint for malloc_error_break, the whole stack trace I get is a call to "malloc_error_break" which looks like this:
libsystem_c.dylib`malloc_error_break:
0x32f20fa8: push {r7, lr} < Thread 1: breakpoint 1.1
0x32f20faa: mov r7, sp
0x32f20fac: nop
0x32f20fae: nop
0x32f20fb0: pop {r7, pc}
0x32f20fb2: nop
If I don't add a breakpoint for malloc_error_break, I get a similarly useless stack trace, but this time with just a __pthread_kill and an assembler instruction.
Is there anything else I can do to get a better idea about the code that generated this error?
I have just created a new project called "Test" with the following main method:
void* data = malloc(100);
free(data);
free(data);
Then I open "Product->Edit Scheme", click on the "Test.app" tab and click on "Diagnostics". Then I select "Enable Guard Malloc".
Now, if I run the application, I get a break on the second free.
Related
I'm suddenly getting weird Malloc errors in my code such as:
malloc: *** error for object 0x7fbdc8daa2f8: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
It seems that they are random and just appear in different places when I set break points. I'm on XCode 8.1. Swift 3.0. Has anyone come across this?
I set the breakpoint and I get this:
libsystem_malloc.dylib`malloc_error_break:
-> 0x112fa4760 <+0>: pushq %rbp
0x112fa4761 <+1>: movq %rsp, %rbp
0x112fa4764 <+4>: nop
0x112fa4765 <+5>: nopl (%rax)
0x112fa4769 <+9>: popq %rbp
0x112fa476a <+10>: retq
The most common cause of this error is threading violations. For example, if one thread performs the final release on an object and begins to deallocate it, and then another thread which has an unowned (Swift) or assign (ObjC) reference to the object modifies it, that will trigger this error. (It should not be possible to get this error if all references are strong or weak, since it shouldn't be possible for the object to be deallocated in the former case, and weak references are thread-safe in the latter case.)
It's of course possible that this is exposing a bug in the latest SDK (and so you should open a radar), but it is more typical that it's a bug in your code that changes in timing have caused to manifest. As noted, you should set a symbolic breakpoint on malloc_error_break to find out what object is in question.
It happens due to freeing an object twice or freeing a pointer that was never allocated or writing through an invalid pointer which previously pointed to an object which was already freed.
Try Product > Scheme > Edit Scheme, and under Diagnostics tab enable all the Malloc settings and Guard Malloc.(This option is only available in simulator)
I'm seeing unexpected breaks in to the debugger in Xcode, related to the svc #128 ARM instruction from a call to pthread_kill to signal another thread. I've seen this for a number of StackOverflow questions related to this issue on iOS - but they weren't helpful for me. In this case, doing Debug->Continue (^⌘Y) repeatedly resolves the problem and execution continues without any apparent side effects. Also, if it's run outside of the debugger, then the app works fine. My goal is to understand why this is happening and avoid breaking in to the debugger except when intended.
Is there an Xcode setting that I might have accidentally set that breaks on these signals?
I'm using Google's Java to Objective-C Transpiler (j2objc), though other iOS devs have mentioned this issue unrelated to j2objc, so I don't believe that's the cause. It occurs when the j2objc Java Runtime Environment Emulation project is signaling other blocked threads. It consistently has 3 threads to signal. After doing Debug->Continue three times, then the program execution carries on without issue or apparent side effect. There are no breakpoints in the project.
The app spawns another thread at startup that uses the Java DatagramSocket class. The Java code works correctly. The transpiled Objective-C code also works correctly except for the annoying breaks in to the debugger.
This is the Stack Frame at interrupt:
main (1)Queue : com.apple.main-thread (serial)
#0 0x0000000195557270 in __pthread_kill ()
#1 0x00000001955f5228 in pthread_kill ()
// Java Runtime Environment Emulation
#2 0x00000001002f7898 in +[AsynchronousSocketCloseMonitor signalBlockedThreads:] ()
#3 0x00000001002f9754 in LibcoreIoIoBridge_closeSocketWithJavaIoFileDescriptor_ ()
#4 0x00000001001f4894 in -[JavaNetPlainDatagramSocketImpl close] ()
// My Code
#5 0x000000010016db88 in <my code>...
Local assembly in kernel pthread_kill method...
libsystem_kernel.dylib`__pthread_kill:
0x195557268: movz x16, #328
0x19555726c: svc #128
// The debugger lands on the following line but I think svc #128 is the cause
0x195557270: b.cc 0x195557288 ; __pthread_kill + 32
0x195557274: stp fp, lr, [sp, #-16]!
0x195557278: mov fp, sp
0x19555727c: bl 0x19553e59c ; cerror_nocancel
0x195557280: mov sp, fp
0x195557284: ldp fp, lr, [sp], #16
0x195557288: ret
The closest non-kernel function in the stack frame is signalBlockedThreads. When my code closes the socket, signalBlockedThreads iterates through all the threads, looking for those blocked against a specific file descriptor (I presume this corresponds to the port number that was just closed). For those relevant blocked threads, they're each signaled with pthread_kill. The method code is copied below.
For the file link, even though this is a Java file, it has embedded Objective-C code that is preserved by the j2objc transpiler:
https://github.com/google/j2objc/blob/765354b620b2c0248945b27062209620d4cf5e40/jre_emul/android/libcore/luni/src/main/java/libcore/io/AsynchronousCloseMonitor.java#L89
+ (void)signalBlockedThreads:(int)fd {
pthread_mutex_lock(&blockedThreadListMutex);
for (AsynchronousSocketCloseMonitor* it = blockedThreadList; it != NULL; it = it->mNext) {
if (it->mFd == fd) {
// MY ADDED COMMENT: BLOCKED_THREAD_SIGNAL == SIGUSR2 in this code
pthread_kill(it->mThread, BLOCKED_THREAD_SIGNAL);
// Keep going, because there may be more than one thread...
}
}
pthread_mutex_unlock(&blockedThreadListMutex);
}
Debug attempts without success:
* Add and remove "All Exceptions" breakpoint - nothing revealed by this
* Remove closeSocket call - averts issue but obviously not a solution to leave socket open
There's a trick to asking Xcode to ignore the signals. I'm curious as to why Xcode is configured by default to interrupt on signals but there you go. Note that the method varies according to the language that you're using - I've edited it to extend the example to Swift:
Permanently configuring LLDB (in Xcode 4.3.2) not to stop on signals
I've been working on a small app, actually in final staging of polish and debug.
I made few small changes to NSUserDefaults storage, which were very minor changes.
However, every time I try to run the app on iPod I get a weird LLDB error, without any further info, like which file, library etc... I set up breakpoints in application:didFinishLoadingWithOptions, but the error is before that?? The app is stuck on splashscreen.
Dump if it is on any help...
Thread 1: EXC_BAD_ACCESS (code=2, address=0x2fd77d4c)
0x2fd77d4c: svchs #14122336
0x2fd77d50: svchs #14122908
0x2fd77d54: svchs #14122923
0x2fd77d58: svchs #14122954
0x2fd77d5c: andeq r0, r0, r0
0x2fd77d60: rsbvc r7, r1, #49283072
0x2fd77d64: rsbvs r6, pc, #3008
0x2fd77d68: svchs #6646889
Does an empty project works with your iPOD? If the answer is yes, comment out all codes you wrote then uncomment it part by part to find which part caused this issue, vise versa.
It's always effective to slice suspect codes to pieces when you can't locate the issue.
I'm in Xcode using the gdb debugger, I just don't understand the error messages I am getting, they seem to change after every run too.
Here is a snippet of the code that is being shown:
0x001e8975 <+0006> sub $0xc,%esp
0x001e8978 <+0009> call 0x1e897d <prepareForMethodLookup+14>
0x001e897d <+0014> pop %edi
0x001e897e <+0015> mov 0x8(%ebp),%esi
0x001e8981 <+0018> mov 0x10(%esi),%eax
0x001e8984 <+0021> and $0xfffffffc,%eax
0x001e8987 <+0024> cmpl $0x0,(%eax)
0x001e898a <+0027> js 0x1e89d2 <prepareForMethodLookup+99>
0x001e898c <+0029> mov 0xfe697(%edi),%ebx
0x001e8992 <+0035> cmpl $0x0,(%ebx)
0x001e8995 <+0038> je 0x1e89aa <prepareForMethodLookup+59>
0x001e8997 <+0040> cmpl $0x2,0x103df7(%edi)
The line in the middle there is where the green arrow seems to be pointing. I just don't fully understand what it means. I'd paste some of the code, but I'm not entairly sure where the actual problem is, and theres a lot of code. It's probably a noob question, or I may not have explained it very well, but I'd appreciate the help.
Do you have exception breakpoints enabled?
Press CMD-6 while in XCode
This should change you from project explorer to breakpoints on your left hand tab
Click the little + at the bottom left of the page and "Add Exception Breakpoint", this adds a breakpoint for all exceptions that happen in the app.
I'm not sure why they're not on by default, it's a little annoying!
This may help you track down the problem you're facing.
I have strange problem with my application which uses scandit SDK for barcode scanning.
The next line
ScanditSDKBarcodePicker *scanditSDKBarcodePicker = [[ScanditSDKBarcodePicker alloc] initWithAppKey:kAppKey];
crashes application with EXC_BAD_ACCESS code. Also I got next code as cause of app crash:
0xf0a9c: push {r7, lr}
0xf0a9e: add r7, sp, #0
0xf0aa0: movs r0, #1
0xf0aa2: movw r1, #65535
0xf0aa6: bl #-114 ; 0x000f0a38 __static_initialization_and_destruction_0(int, int)
0xf0aaa: pop {r7, pc}
0xf0aac: lsls r0, r6
Note: This problem does not happen every time the code is executed.
This is Christian from Scandit.
The EXC_BAD_ACCESS could be caused by a problem with the app key/license integration. Can you double-check that the license key and app key are properly integrated?
You might also want to double-check whether the problem also occurs with the demo app that comes with the free development kit of our ios barcode scanner - after you integrated the license there.