Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Signal Handler for Stack Overflow/List of Posts
Forum Topic - Signal Handler for Stack Overflow: (6 Items)
   
Update
Sai Devasani(deleted)
12/18/2018 8:11 AM
post119361
Signal Handler for Stack Overflow   
Hi,

We are trying to create signal handler to catch stack over flow exception for our application on target. Can any one 
help us to do the same.

Thank you in Advance.....

Thanks & Regards
Sai
Elad Lahav
12/18/2018 8:53 AM
post119363
RE: Signal Handler for Stack Overflow   
*If* the stack has a guard page and *if* the overflow hits this page (it can also jump over it, e.g. by writing to a 
high element in a large stack-allocated array) then the process will receive a SIGSEGV signal. Otherwise it may receive 
SIGBUS or nothing at all (the overflow just goes on to an adjacent mapped region). In general there is no deterministic 
way to detect a stack overflow.

--Elad
________________________________________
From: Sai Devasani [community-noreply@qnx.com]
Sent: December-18-18 8:11 AM
To: ostech-core_os
Subject: Signal Handler for Stack Overflow

Hi,

We are trying to create signal handler to catch stack over flow exception for our application on target. Can any one 
help us to do the same.

Thank you in Advance.....

Thanks & Regards
Sai



_______________________________________________

OSTech
http://community.qnx.com/sf/go/post119361
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
Albrecht Uhlmann
12/18/2018 9:13 AM
post119364
Re: Signal Handler for Stack Overflow   
Some ideas, although none of them will be ideal as Elad mentioned.

1) If single-threaded process, attach signal handler such that SIGINFO is enabled. The signal code and the si_addr 
should tell you if something went wrong in the stack.
/*
 * SIGSEGV codes (si_addr == address of faulting memory reference)
 */
#define SEGV_MAPERR	1	/* Address not mapped */
#define SEGV_ACCERR	2	/* No permissions */
#define SEGV_STKERR	3	/* ?? Stack exception */
#define SEGV_GPERR	4	/* ?? General protection */
#define SEGV_IRQERR	5	/* ?? Interrupt handler fault */
#if defined(__EXT_QNX)
#define NSIGSEGV	5
#endif

I do not know what the question marks mean, though.

2) Allocate all the stacks to be guarded yourself, create large enough guard page and fill stack with a well-known 
pattern. Create an additional thread which will periodically scan all the threads' last valid page if the pattern is 
still there (may cause realtime penalty).

Regards,
Albrecht
Brian Stecher
12/18/2018 9:15 AM
post119365
RE: Signal Handler for Stack Overflow   
1) won't work, since the signal handler can't be invoked - it will try to use the the same stack that originally 
overflowed. Neutrino doesn't have support for alternate signal handler stacks.

________________________________________
From: Albrecht Uhlmann [community-noreply@qnx.com]
Sent: December 18, 2018 9:13 AM
To: ostech-core_os
Subject: Re: Signal Handler for Stack Overflow

Some ideas, although none of them will be ideal as Elad mentioned.

1) If single-threaded process, attach signal handler such that SIGINFO is enabled. The signal code and the si_addr 
should tell you if something went wrong in the stack.
/*
 * SIGSEGV codes (si_addr == address of faulting memory reference)
 */
#define SEGV_MAPERR     1       /* Address not mapped */
#define SEGV_ACCERR     2       /* No permissions */
#define SEGV_STKERR     3       /* ?? Stack exception */
#define SEGV_GPERR      4       /* ?? General protection */
#define SEGV_IRQERR     5       /* ?? Interrupt handler fault */
#if defined(__EXT_QNX)
#define NSIGSEGV        5
#endif

I do not know what the question marks mean, though.

2) Allocate all the stacks to be guarded yourself, create large enough guard page and fill stack with a well-known 
pattern. Create an additional thread which will periodically scan all the threads' last valid page if the pattern is 
still there (may cause realtime penalty).

Regards,
Albrecht



_______________________________________________

OSTech
http://community.qnx.com/sf/go/post119364
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
Albrecht Uhlmann
12/18/2018 9:39 AM
post119366
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
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

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems