Get faulting address on SIGSEGV

Hey all,

I try to write a shared memory for a distributed computing system.

In order to implement a kind of paging for this I want to invalidate the addresses of memory-pages that are currently not valid (using 'mprotect').
Then, to page-in I want to catch SIGSEGV signals, and give them a special treatment if they occured because of any of the shared memory addresses.

In order to do so I need to check if the faulting address is part of my shared memory.

Is there some way to get the faulting address on a SIGSEGV signal?

Thanks for any help!

You will need to use sigaction() to configure the signal handler instead of signal(). Ask again if the manual for sigaction() is not clear enough.

Makes sense, thank you very much!

I encountered another problem.
Is it possible to determine whether the fault occured because of an attempt to read or to write?
I'd assume, that this can be done using siginfo_t, but can't figure out how.

Doesn't look like you can tell, actually. Unless si_errno or si_code is telling that.

--
Mats

Quote:

---

Originally Posted by kruemelmonster

I encountered another problem.
Is it possible to determine whether the fault occured because of an attempt to read or to write?
I'd assume, that this can be done using siginfo_t, but can't figure out how.

---

There is no direct way. But you could do this:

1. open /proc/self/maps
2. scan the region descriptors until you find the region which contains the faulting address
3. check the map permissions for read/write/execute.

Note that on many platforms (importantly, x86), not all combinations of permissions can be implemented at the hardware level. So you may not be able to distinguish, for instance, an illegal read vs. an illegal execute.

But if both the 'r' and 'x' bits are set, then it's clear that the access was an illegal write. Make sense? (I'm assuming you're trying to implement COW, which is certainly possible with the available information)

You could avoid scanning /proc/self/maps if you are keeping track internally of your memory maps.

Thank you very much for your replies!
I solved it by requiring a write lock to be held in order to write, and assume that the access is a read if the lock is not held.

However another problem appeared that I hope you guys can give me some help on as well.

I installed a sigaction as suggested by brewbuck in the following way:

Code:

---

struct sigaction saSegf;
struct sigaction oldAct;
       
saSegf.sa_sigaction = sighandler;
sigemptyset(&saSegf.sa_mask);
saSegf.sa_flags = SA_SIGINFO;
       
       
if(0 > sigaction(SIGSEGV, &saSegf, NULL)); //&oldAct))
        perror("Error SigAction SIGSEG");

---

Unfortnuately the signal handler is not always called. Sometimes it gets called and sometimes the original handling is used.

Is there something wrong with my way of setting up the sigaction?

Quote:

---

Originally Posted by kruemelmonster

Unfortnuately the signal handler is not always called. Sometimes it gets called and sometimes the original handling is used.

---

I don't see anything wrong with what you've got there. Can you describe the circumstance in more detail?

Quote:

---

Originally Posted by brewbuck

I don't see anything wrong with what you've got there. Can you describe the circumstance in more detail?

---

In the meantime I figured out, that the signal handler does not catch the signal if I run the program in gdb, but does catch it if I run it normally.

However

Code:

---

if(0 > sigaction(SIGSEGV, &saSegf, NULL)); //&oldAct))
        perror("Error SigAction SIGSEG");

---

Always results in printing of "Error SigAction SIGSEG: Success", even when the signal handler gets successfully called afterwards.
So I figure there is still a problem with installing the handler.

Quote:

---

Originally Posted by kruemelmonster

Code:

---

if(0 > sigaction(SIGSEGV, &saSegf, NULL)); //&oldAct))
        perror("Error SigAction SIGSEG");

---

Always results in printing of "Error SigAction SIGSEG: Success", even when the signal handler gets successfully called afterwards.
So I figure there is still a problem with installing the handler.

---

I highlighted your problem in bold red.

Oh wow, thanks!
Don't know how I could have missed that!

Do you have any idea how to catch the signal using gdb?
The handler gets installed successfully (checked with my updated if-statement ;) )

Quote:

---

Originally Posted by kruemelmonster

Oh wow, thanks!
Don't know how I could have missed that!

Do you have any idea how to catch the signal using gdb?
The handler gets installed successfully (checked with my updated if-statement ;) )

---

gdb, like any other program which ptrace()'s another program, intercepts all signals for the process. It is gdb's decision whether to deliver the signal or to block it (as if the signal was never sent). Obviously gdb is deciding not to deliver the signal. There isn't much you can do.

(Well, there is one thing. After gdb breaks on the SIGSEGV, you can continue execution by saying "signal 11" instead of "continue" -- this will deliver the original SIGSEGV. You just can't do it by default)

Quote:

---

Originally Posted by brewbuck

(Well, there is one thing. After gdb breaks on the SIGSEGV, you can continue execution by saying "signal 11" instead of "continue" -- this will deliver the original SIGSEGV. You just can't do it by default)

---

That's good enough to be able to debug.
Thanks a lot for your help!