Re: Info request on crashing thread on Crashreport
Re: Info request on crashing thread on Crashreport
- Subject: Re: Info request on crashing thread on Crashreport
- From: Terry Lambert <email@hidden>
- Date: Wed, 25 Feb 2009 17:08:29 -0800
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden