Brian Stecher
|
RE: RE: Signal Handler for Stack Overflow
|
Brian Stecher
12/18/2018 10:30 AM
post119367
|
RE: RE: Signal Handler for Stack Overflow
Sorry, that won't work here either. Signals caused by CPU exceptions (SIGSEGV, SIGBUS, etc) are always delivered to the
thread (and on its stack) that caused the exception. Blocking such a signal on the thread will just cause the process to
be terminated when the CPU exception occurs. Blocking signals and having a single thread deal with them only works for
software initiated ones (SIGQUIT, SIGTERM, etc).
________________________________________
From: Albrecht Uhlmann [community-noreply@qnx.com]
Sent: December 18, 2018 9:39 AM
To: ostech-core_os
Subject: Re: RE: Signal Handler for Stack Overflow
Thanks for clarifying Brian. What would work, to best of my belief, is to have a dedicated thread sitting in
sigwaitinfo(), and have all other threads block all signals, so as to have a single point where to handle signals. If
sigwaitinfo() is set up such that the SI_INFO is delivered by kernel, you should be able to see what the original thread
was, and SI_CODE/SI_VALUE will tell you the reason.
Having the main Thread 1 go to SIGWAITINFO after spawning off all the real worker threads seems to be a commonly used
design pattern in QNX drivers, looking at a "pidin" output of a regular machine.
Regards,
Albrecht
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post119366
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|