From owner-freebsd-hackers Tue Sep 15 09:41:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11047 for freebsd-hackers-outgoing; Tue, 15 Sep 1998 09:41:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11027 for ; Tue, 15 Sep 1998 09:41:53 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.8.8) with SMTP id MAA03417; Tue, 15 Sep 1998 12:43:05 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 15 Sep 1998 12:43:05 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: "Ron G. Minnich" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Catching SIGSEGV In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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