Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2949

Re: Using sigsetjmp/siglongjmp from multithreaded application

Show all headers | View raw

(I'm retaining the three-year old original article.)

In article <d0f72c4d-f70c-440e-aea1-173275458910@googlegroups.com>,
 <gyhuang@ucdavis.edu> wrote:
>On Friday, July 20, 2012 at 2:42:22 PM UTC-7, Michael Podolsky wrote:
>> Hi All,
>> 
>> I am writing a stack tracing code and to make this code safe I want to
>protect myself from a SIGSEGV.
>> 
>> So I chose to process SIGSEGV and jump from a signal handler to a
>position set by sigsetjmp. Then, to my disappointment I found that there
>is no straightforward solution to associate a sigjmp_buf buffer with a
>particular thread.
>> 
>> I can't use standard thread local storage or implement it by myself
>with mutexes because these functions should not be called from a signal
>hanlder.
>> 
>> And, I don't want to run stack tracing code under a mutex as the
>performance of application may degrade -- otherwise I could solve my
>task by having one thread only at risk of SIGSEGV and one sigjmp_buf per
>whole application.
>> 
>> So, going back, is there a robust way in linux to write a multithread
>application in which some critical parts of code are SIGSEGV-tolerant?
>> 
>> Thanks in advance!

>Hi
>I met a similar issue. Finally I use thread specific key as follows:
>function(){
>    Sigjmp_buf localbuf;
>    pthread_setspecific(pthread_key_t key, (const void *)&localbuf);
>
>    if (sigsetjmp(localbuf, 0) != 0) {
>        //assign error
>        //return error
>    }
>    //done with everything
>    pthread_setspecific(pthread_key_t key, NULL);
>}
>
>void signal_handler(int sig)
>{
>    if (sig == SIGSEGV){
>        void * sigjmplocal =pthread_getspecific(pthread_key_t key);
>        if (sigjmplocal)
>            siglongjmp(*(Sigjmp_buf*)sigjmplocal, 1);
>         
>    }
>}
>
>From book, SIGSEGV is sent to the thread that triggers it. 
>Is it safe to use this approach? It seems working with simple UT. But I
>can not foresee its risk.
>
>Thanks a lot. 

No, not according to the rules established by the earlier poster:
        >>I can't use standard thread local storage or implement it by
        >>myself with mutexes because these functions should not be
        >>called from a signal hanlder.

You're using the function pthread_setspecific in a signal handler.
This is not allowed by POSIX. (And I believe that Linux just follows
POSIX in this regard.)  There are only a very few functions that you
are allowed to execute in a signal handler.  Look up the concept
"async-signal-safe."  You might start in section "2.4.3 Signal
Actions" of
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_04>.

It's not at all clear that there is a way to solve this problem in
general.  Here are a few suggestions:
    - Your current code is likely (but not guaranteed) to work on many
      current platforms, including Linux.  You could just live with
      that restriction.
    - If your rate of thread creation is low, you might be able to
      create a static, shared list of task-id to storage pointer
      associations (i.e., reimplement pthread's thread-specific
      storage).  pthread_self() IS on the list of routines allowed to
      be used in a signal handler.  But, the maintenance of this list
      will be complicated and require lots of use of atomic-variables
      in order to comply with POSIX.
    - It's possible that the thread-storage mechanism in C11 and C++11
      can be used for this.  The standard is not clear to me.  Some
      sections hint that it might be supported; other hint that it
      might not.  I don't know of an interpretation on this.

Good luck,

 - dmw
-- 
   Douglas Wells             .  Connection Technologies      .
   Internet:  -sp201504- -at- -gmail.com-                     .

Back to comp.programming.threads | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-20 14:42 -0700
  Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-21 03:32 +0200
    Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-21 04:05 +0200
      Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 10:22 -0700
        Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-25 03:28 +0200
  Re: Using sigsetjmp/siglongjmp from multithreaded application Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-07-21 09:10 +0200
    Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 10:34 -0700
      Re: Using sigsetjmp/siglongjmp from multithreaded application Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-07-24 22:58 +0200
        Re: Using sigsetjmp/siglongjmp from multithreaded application Drazen Kacar <dave@fly.srk.fer.hr> - 2012-07-24 21:23 +0000
        Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 15:48 -0700
  Re: Using sigsetjmp/siglongjmp from multithreaded application gyhuang@ucdavis.edu - 2015-03-31 11:58 -0700
    Re: Using sigsetjmp/siglongjmp from multithreaded application sp9804@butternut.contek.com (Douglas Wells (USENET)) - 2015-04-01 19:05 +0000

csiph-web