site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Feb 24, 2009, at 6:48 AM, Arnab Ganguly wrote: Hi All, Not sure this email is being sent on the correct group or not. I am analysing the Apple crash report.So I launched my application and tried to forcibly (kill -11 pid) crash the application.The app crashed and even the Apple crash report got generated. The crash report says Thread 1 crashed, but when I go through the stack trace of Thread 0 I see sigtramp is being received by Thread 0.Is this correct report? How is the thread received signal is different from the thread that got crashed as per the report ?Any help or suggestion would be of great help. Non-hardware exceptions are signalled as BSD AST to the first thread that happens to be there if you use kill() instead of pthread_kill() to deliver the signal. Basically, short of blocking all signals and then explicitly unblocking them in a thread intended to act as the handler thread, you will not be able to ensure that a signal gets delivered to one thread rather than another thread. How to portably handle signals in multithreaded programs is actually very well documented in the O'Reilly pthreads book (both the final, standard version, and the common Draft 4 version, which describes the HP/SGI implementation of pthreads version 4 prior to the standardization of pthreads). If, on the other hand, you're actually getting a SIGSEGV because you are dereferencing unmapped regions, or SIGBUS because you are attemting to write read-only regions or read non-readable regions, or SIGILL because you are trying to execute in a non-execute segment (such as a stack), that will be treated as a hard exception and delivered to the thread that caused it. So the bottom line is that fake exceptions aren't going to behave like real exceptions. This email sent to site_archiver@lists.apple.com