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
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 need to repetitively send 4 bytes, 00 00 00 F6, every two seconds.
BUT, IdUDPClient.SendBuffer does not return after transmission.
I try sending a few more bytes, and it returns every time.
This works:
UDP.SendBuffer(RawToBytes(#0 + #0 + #0 + #1 + #127 + #128 + #246, 7));
This does not work:
UDP.SendBuffer(RawToBytes(#0 + #0 + #0 + #246, 4));
I have unsuccessfully tried many of the suggestions I have found in various related StackExchange questions.
I have seen at least three scenarios:
Hanging, Wireshark sees 1 transmission.
Working repetitive transmissions, but NOT with 4 bytes of data.
Sometimes bytes > 7F are sent as 3F.
Can someone point out what I am doing wrong?
Edit: The above happens in a thread. If the TIdUDPClient is put as a visible component on a form, then it works fine.
Could this be a threading/reentrancy issue???
It would definitely help to see more of your code, have you made sure that your thread is actually running (calling Execute) otherwise your code won´t run, obviously :)
The difference when using the TIdUDPClient component on a visible form is that it is autocreated (The constructor is run automatically by the delphi designer)
TIdUDPClient.Create(AOwner: **)
by doing so the component will be operating on the main thread ("GUI thread" if you like)
A few things I´d suggest you do in order to hunt this down is:
First Make sure that the thread is actually executing
The problem could also be that the TIdUDPClient does not have an owner if instantiated with TIdUDPClient.Create(nil) inside the thread, try to instantiate int with and owner either the TThread or the Application
TIdUDPClient.Create(Self)
or
TIdUDPClient.Create(Application)
Hope this helps, but as I said posting more of your code would definitely make it possible for me to help you!
I am trying to understand why an installation file hangs up using Windbg, but I am at a point where I can't stop the execution.
As background, I had already been able to install this program on the same PC, but for some reason I had then uninstalled, and now I can't re-install it (I tried to clean up everything from the old installation, incl. registry). Now this setup.exe starts and stays idle among the running processes without doing anything.
But let's go to the actual question. I am trying to use Windbg for the first time (I only had some practice with the old 8086 debug at DOS-time :-), so please bear with me if I'm asking something straightforward).
I have tracked the code up to a point where I have a RET code. I am able to stop the debugger at the RET instruction, but as soon as I "step into" the RET, the execution starts and does not stop, while I was expecting it to just go to the instruction following the previous CALL. From how I see things, it seems that after the RET the execution goes somewhere else ... how is it possible? Also, just before the RET there is a SYSCALL that I don't fully understand ... can it have an impact?
This is the portion of the code I am examining at the moment:
ntdll!NtTerminateThread:
00007ff9`fc8b5b20 4c8bd1 mov r10,rcx
00007ff9`fc8b5b23 b853000000 mov eax,53h
00007ff9`fc8b5b28 f604250803fe7f01 test byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
00007ff9`fc8b5b30 7503 jne ntdll!NtTerminateThread+0x15 (00007ff9`fc8b5b35)
00007ff9`fc8b5b32 0f05 syscall
00007ff9`fc8b5b34 c3 ret
00007ff9`fc8b5b35 cd2e int 2Eh
00007ff9`fc8b5b37 c3 ret
I am stuck at the first RET instruction, at address 5b34.
At this time, this is the stack call:
00000000`0203fc38 00007ff9`fc86c63e ntdll!NtTerminateThread+0x14
00000000`0203fc40 00007ff9`fc8d903a ntdll!RtlExitUserThread+0x4e
00000000`0203fc80 00007ff9`fc86c5c5 ntdll!DbgUiRemoteBreakin+0x5a
00000000`0203fcb0 00000000`00000000 ntdll!RtlUserThreadStart+0x45
so my understanding is that execution should continue at address 00007ff9`fc86c63e. However, even if I add a BP at this address, or if I just go for a trace, the execution continues and keeps running some idle loop until I hit the "pause" button in windbg, after which it resume at a completely different address.
In case the registers are relevant, here are some of them:
rax: 353000
rbx: 0
rcx: 0
rdx: 0
rsp: 203fc38
rdi: 7ff9c8d8fe0
rip: 7ff9fc8b5b34
So, eventually, where am I wrong? How can I see where the code goes after this RET?
Thanks in advance for any help,
Bob
when a thread exits the execution wont return to the return address
the system is free to schedule another thread that is ready in the process
the stack shows NtTerminateThread on the stack it is a function that does not return
__declspec noreturn foo (...) ;
btw when you say it goes elsewhere do you mean the app keeps running and is not terminated if so hit ctrl+break and check what other threads are doing
ie if usermode ~*kb should show all the threads callstack
answering the comment about where it goes
process is a collection of threads
each thread has a stack and each thread gets a bit of time to execute from the scheduler (thread quantum)
each thread that has a lower priority can be preempted by threads xxxx ,yyy ,zzz with higher priorities by interrupts by apcs , dpcs etc
when a thread has completed its quantum or is preempted by some vip cavalcade happening to travel on the road that this poor thread is walking
a trap is made _KTRAP and this poor threads position EIP is filled into it and put in a waiting threads barricade
when the vip cavalcade's dust has settled police open the barricade and let the poor thread walk from where it stopped
for such gory details you may need a kernel debugging setup and may need to control your process from a kernel debugger
when you hit the return os sees the thread is dead and has no return address
so it checks the !ready threads and selects the highest priority thread and provides it a quantum to enjoy
so before hitting the return address check what all other threads are doing in your app set an appropriate break on threads of interest and hit the return when the other thread executes its quantum your break will get hit
You're looking at the wrong thread!
From the partial output you supplied seems like you're attaching to a running process (rather than start it from the debugger). To break into a running process the debugger injects a thread into the target process that basically contains a hardcoded int 3 instruction and not much more.
It does it by calling ntdll!RtlpCreateUserThreadEx (the internal undocumented native parallel of CreateRemoteThread) supplying ntdll!DbgUiRemoteBreakin as the start address for the new thread.
The sole purpose of this synthetic thread is to generate the breakpoint exception. This exception causes the operating system to stop running the target process and passes control to the debugger. After it does this it's not needed anymore and it commits suicide.
What you're supposed to do at this point is probably switch to your thread of interest using ~s command, set breakpoints and then continue execution.
If try to step through this synthetic thread it will just end, and then the process will continue doing whatever it was doing before you broke into it, which is pretty much the opposite of what you want,
That's what this stack means:
00000000`0203fc38 00007ff9`fc86c63e ntdll!NtTerminateThread+0x14
00000000`0203fc40 00007ff9`fc8d903a ntdll!RtlExitUserThread+0x4e
00000000`0203fc80 00007ff9`fc86c5c5 ntdll!DbgUiRemoteBreakin+0x5a
00000000`0203fcb0 00000000`00000000 ntdll!RtlUserThreadStart+0x45
ntdll!RtlUserThreadStart is the real user-mode entry point of all user-mode threads and you can see that it just called ntdll!DbgUiRemoteBreakin after which you continued a bit until the thread finally ends itself.
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 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.