Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Sep 1998 12:43:05 -0500 (EST)
From:      Alfred Perlstein <bright@hotjobs.com>
To:        "Ron G. Minnich" <rminnich@Sarnoff.COM>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Catching SIGSEGV
Message-ID:  <Pine.BSF.3.96.980915123624.21829G-100000@bright.fx.genx.net>
In-Reply-To: <Pine.SUN.3.91.980915110107.14273C-100000@terra>

next in thread | previous in thread | raw e-mail | index | archive | help

ok, basically what is going on is that there is data being read for where
it ain't supposed to be, the OS traps and your signal handler ought to
handle it, else when the OS _RESTARTS_ the intruction you'll fault again
then then loop.

"there is no buffer in memory" it's the reading of the memory that's
causing the fault, someone in this thread brought up setjmp, that could
also work, another trick would be to change the value of 'ptr' to
something valid, (in the handler) then when the instruction is restarted
it will access valid memory and proceed as planned.

> On Tue, 15 Sep 1998, Mikael Karpberg wrote:
> > My guess is that you would want to declare things like this:
> > volatile int nsegv = 0;
> > volatile int *ptr;
> > int zero = 0;
> > 
> > Then the restarted "buf = *ptr;" line will not use a buffered value for ptr
> > but read it from memory. I think.

that is TOTALLY wrong. no matter what happens the CPU will fault on the
fetch from the bad address.

> Depends on the instruction and how restart happens. I think it's going to 
> be iffy for portability. But it will be interesting to see how it works 
> out :-)

there was an OS that did something funky to the first page of memory that
allowed programmers to abuse the fact that it was null and accessable.
many programs broke when the system was brought to a different
archetecture.

Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com
-- There are operating systems, and then there's FreeBSD.
-- http://www.freebsd.org/                        3.0-current




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980915123624.21829G-100000>