|
Home > Archive > Unix Programming > April 2005 > SIGSEGV handler
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| fireflyblue@gmail.com 2005-04-12, 2:51 am |
| Hi,
Let's say I use mprotect to protect a page of memory and I set
PROT_READ permissions. In the signal handler, I want to toggle this
state to PROT_WRITE the first time signal is received. The next time, I
want to change it back to PROT_READ and so on.
Well, my basic question is, it there any way I can find out what my
memory protection on the page was when the SIGSEGV signal handler is
called ?
thanks,
Allison
| |
| Barry Margolin 2005-04-13, 2:52 am |
| In article <1113285418.581405.174580@l41g2000cwc.googlegroups.com>,
fireflyblue@gmail.com wrote:
> Hi,
>
> Let's say I use mprotect to protect a page of memory and I set
> PROT_READ permissions. In the signal handler, I want to toggle this
> state to PROT_WRITE the first time signal is received. The next time, I
> want to change it back to PROT_READ and so on.
>
> Well, my basic question is, it there any way I can find out what my
> memory protection on the page was when the SIGSEGV signal handler is
> called ?
Keep track of how you set it in a global variable.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| fireflyblue@gmail.com 2005-04-14, 2:51 am |
| That's not what I really wanted to do. I made up that situation and
only after posting I realized that was a bad example. Sorry about that.
What I really need to know in the handler is, if my memory page is not
given ANY access (PROT_NONE), then any time a read or write is
performed to the memory page, there will be a segmentation violation.
How do I know if it was a read or a write that caused the access error
?
thanks,
Allison
Barry Margolin wrote:
> In article <1113285418.581405.174580@l41g2000cwc.googlegroups.com>,
> fireflyblue@gmail.com wrote:
>
time, I[vbcol=seagreen]
is[vbcol=seagreen]
>
> Keep track of how you set it in a global variable.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
| |
| Kurtis D. Rader 2005-04-14, 2:51 am |
| On Wed, 13 Apr 2005 19:19:07 -0700, fireflyblue wrote:
> That's not what I really wanted to do. I made up that situation and only
> after posting I realized that was a bad example. Sorry about that.
>
> What I really need to know in the handler is, if my memory page is not
> given ANY access (PROT_NONE), then any time a read or write is performed
> to the memory page, there will be a segmentation violation.
>
> How do I know if it was a read or a write that caused the access error ?
Install your signal handler with the SA_SIGINFO flag. A pointer to a
siginfo_t will be passed as the second argument to your signal handler.
The si_addr member will tell you which address was accessed which resulted
in the fault. The third argument to your signal handler will be a pointer
to a ucontext_t. The mcontext_t member of that structure should have a
gregset_t member which in turn should contain the instruction pointer
(typically accessed via REG_EIP) of the instruction which caused the
fault. Simply decode the bytes at that location to determine if it was a
read or write violation. Easy :-)
I don't have my x86 architecture docs at home. It's possible the cr2
member of the mcontext_t structure (for ia32/x86/i386 architecture) has
information on whether the faulting access was a read or write.
| |
| fireflyblue@gmail.com 2005-04-15, 5:56 pm |
| Thanks a lot! That was helpful.
However, this solution is architecture dependent.
I wonder why there isn't a more elegant solution ?
Allison
| |
| William Ahern 2005-04-15, 5:57 pm |
| fireflyblue@gmail.com wrote:
> Thanks a lot! That was helpful.
> However, this solution is architecture dependent.
>
> I wonder why there isn't a more elegant solution ?
Because the reason for wanting this info is inelegant by nature. If you get
a SIGSEGV you're program is either buggy, your hardware has a glitch, or
you're poking at the VM subsystem. Unix wasn't architected to let
programmers manage any of that stuff, and neither would the C standard ever
dream of exposing that much information "portably".
| |
| Matthias Buelow 2005-04-15, 5:57 pm |
| William Ahern <william@wilbur.25thandClement.com> writes:
> Because the reason for wanting this info is inelegant by nature. If you get
> a SIGSEGV you're program is either buggy, your hardware has a glitch, or
> you're poking at the VM subsystem. Unix wasn't architected to let
> programmers manage any of that stuff, and neither would the C standard ever
> dream of exposing that much information "portably".
There're other uses, like implementing write barriers for generational
garbage collectors by readonly mappings, although I agree that it
isn't pretty.
mkb.
| |
| David Schwartz 2005-04-15, 5:57 pm |
|
<fireflyblue@gmail.com> wrote in message
news:1113580326.553873.16350@g14g2000cwa.googlegroups.com...
> Thanks a lot! That was helpful.
> However, this solution is architecture dependent.
>
> I wonder why there isn't a more elegant solution ?
The meaning of a SIGSEGV is architecture-dependent, so the solution to
analyzing them has to be architecture-dependent.
DS
| |
| Kurtis D. Rader 2005-04-16, 2:48 am |
| On Fri, 15 Apr 2005 08:52:06 -0700, fireflyblue wrote:
> Thanks a lot! That was helpful.
> However, this solution is architecture dependent.
>
> I wonder why there isn't a more elegant solution ?
The solution has to be architecture specific, and thus "inelegant" by your
definition, because each architecture implements memory management
differently. The architecture (i.e., the CPU and associated MMU, if any)
might not even distinguish between read versus write access when reporting
an address space access violation. In which case there isn't any way for
the kernel to distinguish (short of examining the faulting instruction).
Similarly, each architecture has its own method for reporting such
violations. Some architectures which UNIX runs on don't even have a
MMU (memory management unit) but might still chose to report accesses to
invalid addresses using SIGSEGV rather than SIGBUS. It would be
extremely difficult, if possible at all, for UNIX to expose that
information in an architecture neutral manner.
If you are still perplexed I would recommend learning how to program in
assembly language on a minimum of two dissimilar architectures.
| |
| Prafulla Harpanhalli 2005-04-16, 2:48 am |
|
Kurtis D. Rader wrote:
<snip>
> The solution has to be architecture specific, and thus "inelegant" by
your
> definition, because each architecture implements memory management
> differently. The architecture (i.e., the CPU and associated MMU, if
any)
> might not even distinguish between read versus write access when
reporting
> an address space access violation. In which case there isn't any way
for
> the kernel to distinguish (short of examining the faulting
instruction).
> Similarly, each architecture has its own method for reporting such
> violations. Some architectures which UNIX runs on don't even have a
> MMU (memory management unit) but might still chose to report accesses
to
> invalid addresses using SIGSEGV rather than SIGBUS.
Ok, i maybe wrong here but if there is no MMU, its similar to a flat
address space. If so, then where is the question of segmentation
violation? Please clarify.
> If you are still perplexed I would recommend learning how to program
in
> assembly language on a minimum of two dissimilar architectures.
Shall try this..
--
Best Rregards,
Prafulla Harpanhalli
| |
| Måns Rullgård 2005-04-16, 2:48 am |
| "Prafulla Harpanhalli" <prafulla_ng@rediffmail.com> writes:
> Kurtis D. Rader wrote:
> <snip>
>
>
> Ok, i maybe wrong here but if there is no MMU, its similar to a flat
> address space. If so, then where is the question of segmentation
> violation? Please clarify.
Even in the absence of an MMU, there can be (and usually are)
addresses that don't physically exist. How accesses to such addresses
are reported is dependent on both the CPU and the OS.
>
> Shall try this..
While your at it, make note of how insanely the x86 is designed, if
design is at all the proper word to use about that monster.
--
Måns Rullgård
mru@inprovide.com
|
|
|
|
|