19

I have a program in Linux which is multithreaded. There are certain memory areas in which I'm interested to see if they have been written within a certain time period. For that I give only read access to those memory pages and install a signal handler for SIGSEGV. Now my question is, will each thread call the signal handler for itself. Say Thread 1 writes to some forbidden memory area, will it be the one to execute the signal handler?

MetallicPriest
  • 29,191
  • 52
  • 200
  • 356

2 Answers2

30

First of all

Signal dispositions are process-wide; all threads in a process share the same disposition for each signal. If one thread uses sigaction() to establish a handler for, say, SIGINT, then that handler may be invoked from any thread to which the SIGINT is delivered.

But read on

A signal may be directed to either the process as a whole or to a specific thread. A signal is thread-directed if

it is generated as the direct result of the execution of a specific hardware instruction within the context of the thread (SIGBUS, SIGFPE, SIGILL, and SIGSEGV)

I am quoting from TLPI.

cnicutar
  • 178,505
  • 25
  • 365
  • 392
  • 1
    So that means SIGSEGV signal handler will be executed by the thread who has written to the forbidden memory, right? – MetallicPriest Jun 30 '11 at 10:40
  • @MetallicPriest Yes, but it's the same handler for all threads. – cnicutar Jun 30 '11 at 10:42
  • Does it also depends upon which thread called mprotect? I think mprotect is for the whole process, right? – MetallicPriest Jun 30 '11 at 10:45
  • 2
    Yes. mmap, mprotect etc, affect the whole process. A SIGSEGV is always delivered to the thread which caused it. – MarkR Jun 30 '11 at 11:22
  • is there a way to force a "universal" SIGSEGV handler for the process? or redirect a fault to a particular handler? without overriding the default handler of each thread.. – Paschalis Oct 13 '15 at 11:23
  • Unlikely, doubtful. I wouldn't know how this could supposedly work. SIGSEGV is caused by a thread doing a bad memory access. How would another thread which isn't necessarily scheduled to run at that time possibly handle this, even if there was an API to define such a handler? The only "working" approach is to invoke the handler from the thread that caused the access. Which is also the only one that really makes sense logic-wise. – Damon Feb 02 '19 at 15:14
6

No, per the question title.

To the question body: For the particular signal that you are asking for, yes (otherwise: it depends). The thread causing a segfault will receive the signal.

See signal(7):

A signal may be generated (and thus pending) for a process as a whole (e.g.,
when sent using kill(2)) or for a specific thread (e.g., certain signals, such
as SIGSEGV and SIGFPE, generated as a consequence of executing a specific
machine-language instruction are thread directed [...].
Damon
  • 67,688
  • 20
  • 135
  • 185
  • Why do you say no, when in the description it is written that SIGSEGV is thread directed? – MetallicPriest Jun 30 '11 at 10:39
  • 3
    Because the question is about "to _each_ thread". `SIGSEGV` is delivered to _one_ thread (the one that caused it). Thus, no. (But, of course if it's not handled, it may (usually will) kill the entire process, which would obviously affect every other thread -- but the signal is not delivered to each one.) – Damon Jun 30 '11 at 11:23
  • The question in the title doesn't quite match the question in the body; they're asking for the same underlying piece of information, but a "no" to one is a "yes" to the other. So you might want to adjust your answer to make clear which one you're saying "no" to. – ruakh Jun 25 '16 at 05:20