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.
Related
I studied the game code and came across the PurchaseDocument class and method, they send requests to the server, I tried to mark the request using Charles, it didn’t work, but disassembling the game code, the requests go to the server.
Here is the request sent to the server:
I'm interested in the part with Expression Attrinute Value "N"
Here is a part of the disassembled code that is responsible for the part highlighted in the request:
The address of the line in memory is written to the "x1" register, but the debugger does not work for me to find out immediately what the address is.
I will be happy if they help me with the problem, my experience with arm is very small
Let's focus on the "but the debugger does not work for me to find out immediately what the address is."
I assume you do have access to a jailbroken device and can install lldb on it.
In this code (adjusting for executable load address changing under ASLR):
0x013e0c80 adrp x8, 0x2d71000
0x013e0c84 nop //set breakpoint here
0x013e0c88 ldr x1, [x8, #0x250] //or here
You can inspect the memory like this:
x $x8+0x250
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'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 spent quite some time trying to trace this problem and read multiple suggestion from others with the same problem. I deal with a large code base so finding the problem without some hints is like looking for a needle in a hay stack.
On of the suggestion I read is to add a break point on *malloc_error_break* - but how do I do that. I understand that I have to add a symbolic break point but I'm not sure what exactly to enter in the two text fields, Symbol and Module?
I tried to enable Malloc Scribble and Malloc Guard Edges - but none of it results in any break point or crashes.
If I enable Zombie Objects the programs stops crashing but there is nothing in the output log showing any problems.
Finally I tried to enable Guard Malloc. I understand that it only works with the simulator so I tries that - but the problem is that the programs crashes in the start up phase before any line in my program is executed:
0x958e0cd4 <+0000> mov 0x4(%esp),%eax
0x958e0cd8 <+0004> mov %gs:0x0(,%eax,4),%eax < Crash
0x958e0ce0 <+0012> ret
and the call stack looks like this:
pthread_getspecific
__dyld__dyld_start
I'm not sure what I'm doing wrong here?
To add a breakpoint on malloc_error_break, simply stop in the debugger and type b malloc_error_break at the "gdb" or "lldb" prompt.
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.