Is it possible to kill a thread that is locked due to a dispatch_sync? Here is the code:
dispatch_sync(q_, ^{
...
});
Here is the stack trace when it is locked:
#0 0x00007fff8d69951a in semaphore_wait_trap ()
#1 0x00007fff9aad7c5b in _os_semaphore_wait ()
#2 0x0000000100aec692 in _dispatch_barrier_sync_f_slow ()
I tried using pthread_kill but the thread does not terminate.
If you look through all the POSIX information, it is possible.
In reality, forget it. You'll never make it work. If you have a deadlock in your code, the only way to get rid of the deadlock is to fix your code.
BTW, a deadlock on an iOS device is much much worse than a crash. When an app crashes, many users don't even take any notice, they just start it again. When an app deadlocks, the user needs to use a much more complicated process to kill the app manually.
As a rule, I'd avoid dispatch_sync as much as possible.
pthread_kill() does not "kill" a thread in terms of ending it, it just sends it a signal.
The function of choice to (try to) end a thread is pthread_cancel().
Cancellation however only happpens when the code execution "passes" a cancellation point. The latter are well defined. See here for a list.
Related
Sometimes my iPhone application crashes with a weird crashlog, that reads exception code is 0x8badf00d. The stacktraces show random snapshots of app execution, but nothing suspicious. This happens very rarely and I'm not able to find out how to reproduce it. Does anybody know more about this kind of exception and exception code?
Here is an excerpt from my crashlogs:
Exception Type: 00000020
Exception Codes: 0x8badf00d
Highlighted Thread: 0
Application Specific Information:
Failed to deactivate
Thread 0:
...
< nothing suspicious here >
...
Unknown thread crashed with unknown flavor: 5, state_count: 1
0x8badf00d is the error code that the watchdog raises when an application takes too long to launch or terminate. See Apple's Crash Reporting for iPhone OS Applications document
If you get Exception Type: 00000020 and Exception Codes: 0x8badf00d then it is watchdog timeout crash reports. The exception code 0x8badf00d is called "ate bad food".
The most common reason for this crash is synchronous activity on main thread. The fix is to switch to asynchronous activity on main thread.
Refer this Apple document for more detail.
It is HexSpeak, see here: http://en.wikipedia.org/wiki/Hexspeak
It's some programmer's idea of a joke. You have to pick a number for your code, but the number doesn't necessarily mean anything in itself. 8badf00d is just another way to write the number 2,343,432,205, and was chosen because it looks 'funny' when represented in hex for an exception log.
0x8badf00d exception is raised by apple provided watchdog. The most common cause for watchdog timeout crashes in a network application is synchronous networking on the main thread. There are four contributing factors here:
synchronous networking — This is where you make a network request and block waiting for the response.main thread — Synchronous networking is less than ideal in general, but it causes specific problems if you do it on the main thread. Remember that the main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive.long timeouts — If the network just goes away (for example, the user is on a train which goes into a tunnel), any pending network request won't fail until some timeout has expired. Most network timeouts are measured in minutes, meaning that a blocked synchronous network request on the main thread can keep the user interface unresponsive for minutes at a time.Trying to avoid this problem by reducing the network timeout is not a good idea. In some situations it can take many seconds for a network request to succeed, and if you always time out early then you'll never make any progress at all.watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it's always less than a network timeout.
There are two common solutions:
asynchronous networking — The best solution to this problem is to run your networking code asynchronously. Asynchronous networking code has a number of advantages, not least of which is that it lets you access the network safely without having to worry about threads.synchronous networking on a secondary thread — If it's prohibitively difficult to run your networking code asynchronously (perhaps you're working with a large portable code base that assumes synchronous networking), you can avoid the watchdog by running your synchronous code on a secondary thread.
Refer apple docs for more information.
It's a failure code added by a dev with a good sense of humor. Because hexadecimal uses letters as well as numbers, it's possible to come up with hex numbers that look approximately like english words, such as "0xdeadbeef", etc. I'm sure that the exception has a specific meaning, but if there's no major symptoms associated with it, you can probably ignore it without too much concern.
from wikipedia 0xBAADF00D ("bad food") is used by Microsoft's LocalAlloc(LMEM_FIXED) to indicate uninitialised allocated heap memory when the debug heap is used.[7]
I have an app where I read data from input stream and visualize it to user. When I set up input stream, I set it up in background run loop, open it and then run a background loop. But sometimes my app breaks unexpectedly. I can't repeat this crash so I don't even know where to start to fix it.
The crash I get looks like this:
And the method where it crashes looks like this:
It says that it is Enqueued from background queue (Thread 3). And Thread 3 looks like that:
What could be the reason of this? Where should I start to fix it?
And the strange thing is that in Thread 17, where it crashes variable bg_queue is nil, and anyway it passes the if condition where i do
if (bg_queue != nil)
But in Thread 3 it is not nil:
Thread 17
Thread 3
It seems, you create a run loop from a secondary thread managed by GCD. You should not obtain a run loop from a thread that is managed by GCD!
Create your own dedicated thread or use the main thread to obtain a run loop.
If you create a second runloop, you are more courageous than I am. I would never dare doing that, because I would be just sure that it leads to problems that are too hard for me to fix. As you are finding out.
If you are sure that you are a much more clever developer than I am, then sorry, you're on your own. If you are not sure, then DON'T DO THAT! Stay away from secondary run loops!
Sometimes my iPhone application crashes with a weird crashlog, that reads exception code is 0x8badf00d. The stacktraces show random snapshots of app execution, but nothing suspicious. This happens very rarely and I'm not able to find out how to reproduce it. Does anybody know more about this kind of exception and exception code?
Here is an excerpt from my crashlogs:
Exception Type: 00000020
Exception Codes: 0x8badf00d
Highlighted Thread: 0
Application Specific Information:
Failed to deactivate
Thread 0:
...
< nothing suspicious here >
...
Unknown thread crashed with unknown flavor: 5, state_count: 1
0x8badf00d is the error code that the watchdog raises when an application takes too long to launch or terminate. See Apple's Crash Reporting for iPhone OS Applications document
If you get Exception Type: 00000020 and Exception Codes: 0x8badf00d then it is watchdog timeout crash reports. The exception code 0x8badf00d is called "ate bad food".
The most common reason for this crash is synchronous activity on main thread. The fix is to switch to asynchronous activity on main thread.
Refer this Apple document for more detail.
It is HexSpeak, see here: http://en.wikipedia.org/wiki/Hexspeak
It's some programmer's idea of a joke. You have to pick a number for your code, but the number doesn't necessarily mean anything in itself. 8badf00d is just another way to write the number 2,343,432,205, and was chosen because it looks 'funny' when represented in hex for an exception log.
0x8badf00d exception is raised by apple provided watchdog. The most common cause for watchdog timeout crashes in a network application is synchronous networking on the main thread. There are four contributing factors here:
synchronous networking — This is where you make a network request and block waiting for the response.main thread — Synchronous networking is less than ideal in general, but it causes specific problems if you do it on the main thread. Remember that the main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive.long timeouts — If the network just goes away (for example, the user is on a train which goes into a tunnel), any pending network request won't fail until some timeout has expired. Most network timeouts are measured in minutes, meaning that a blocked synchronous network request on the main thread can keep the user interface unresponsive for minutes at a time.Trying to avoid this problem by reducing the network timeout is not a good idea. In some situations it can take many seconds for a network request to succeed, and if you always time out early then you'll never make any progress at all.watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it's always less than a network timeout.
There are two common solutions:
asynchronous networking — The best solution to this problem is to run your networking code asynchronously. Asynchronous networking code has a number of advantages, not least of which is that it lets you access the network safely without having to worry about threads.synchronous networking on a secondary thread — If it's prohibitively difficult to run your networking code asynchronously (perhaps you're working with a large portable code base that assumes synchronous networking), you can avoid the watchdog by running your synchronous code on a secondary thread.
Refer apple docs for more information.
It's a failure code added by a dev with a good sense of humor. Because hexadecimal uses letters as well as numbers, it's possible to come up with hex numbers that look approximately like english words, such as "0xdeadbeef", etc. I'm sure that the exception has a specific meaning, but if there's no major symptoms associated with it, you can probably ignore it without too much concern.
from wikipedia 0xBAADF00D ("bad food") is used by Microsoft's LocalAlloc(LMEM_FIXED) to indicate uninitialised allocated heap memory when the debug heap is used.[7]
Can anyone help me??. I am trying to kill them, but, that will require a signal. So, I thought of using cancel.
Definitely pthread_cancel will not free the thread's stack, given that the canceled thread may continue to execute for some time, for example, executing cancellation handlers.
Thread resources are cleaned up after both pthread_detach were called on the thread and the thread has terminated (which is possible to occur in either order).
I have an attached server thread blocked on an accept() waiting for connections. Externally I try to terminate the thread by calling pthread_cancel(), followed by pthread_join(). Upon calling the join, my program terminates with a SIGABRT.
I am, more than likely going to the detach the thread, and make it select() with a timeout to check for connections, so I can then "signal" it to quit. So, I know this is a solution, but being the curious type, I was wondering why the first solution doesn't work.
I think you're getting the program termination SIGABRT because of the pthread_cancel() -- when the blocked thread gets the signal, it probably dies. The signal delivery doesn't happen until after the call to pthread_cancel() has returned, so it just looks like it occurs because of the join call.
To check and see if my thoughts are right, I would insert a while(1); loop after the pthread_cancel() to see if you still get the SIGABRT.