Re: Handling segV's

1999-10-16 Thread Kevin Day
> > > > I mmap() files in, then copy them to a device. This works great except when > > > > someone tries to change that file during the copy. If the size of the file > > > > shrinks, I'll SIGBUS or SIGSEGV when i try to touch past the new file size. > > > > So, i setup a signal handler and longjm

Re: Handling segV's

1999-10-16 Thread Wes Peters
Kevin Day wrote: > > > > > Kevin Day wrote: > > > > > > I mmap() files in, then copy them to a device. This works great except when > > > someone tries to change that file during the copy. If the size of the file > > > shrinks, I'll SIGBUS or SIGSEGV when i try to touch past the new file size. >

Re: Handling segV's

1999-10-16 Thread Kevin Day
> > Kevin Day wrote: > > > > I mmap() files in, then copy them to a device. This works great except when > > someone tries to change that file during the copy. If the size of the file > > shrinks, I'll SIGBUS or SIGSEGV when i try to touch past the new file size. > > So, i setup a signal handler

Re: Handling segV's

1999-10-16 Thread Wes Peters
Kevin Day wrote: > > I mmap() files in, then copy them to a device. This works great except when > someone tries to change that file during the copy. If the size of the file > shrinks, I'll SIGBUS or SIGSEGV when i try to touch past the new file size. > So, i setup a signal handler and longjmp in

Re: Handling segV's

1999-10-15 Thread Kevin Day
> > Dodge Ram wrote: > > > Also, is there a list of reasons for a SIGSEGV ? > > Only one: "Your program is buggy" :-) > >- mark I've actually got a SIGSEGV/SIGBUS handler in one of my programs that I needed, and couldn't figure a way around... I mmap() files in, then copy them to a dev

Re: Handling segV's

1999-10-15 Thread Mark Newton
Dodge Ram wrote: > Also, is there a list of reasons for a SIGSEGV ? Only one: "Your program is buggy" :-) - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd

Re: Handling segV's

1999-10-15 Thread Kip Macy
DDD somehow manages to do this, however, even if you tell it to ignore it and continue it will almost invariably segV again shortly thereafter. -Kip On Fri, 15 Oct 1999, Alec Kloss wrote: > Dodge Ram said: > > > Hi, > > > > I am looking at ways to

Re: Handling segV's

1999-10-15 Thread Dodge Ram
a list of reasons for a SIGSEGV ? thanks and regards, ramesh >From: Alec Kloss <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] (Dodge Ram) >CC: [EMAIL PROTECTED] >Subject: Re: Handling segV's >Date: Fri, 15 Oct 1999 11:23:37 -0500 (CDT) > >Dodge Ram said: > >

Re: Handling segV's

1999-10-15 Thread Alec Kloss
Dodge Ram said: > Hi, > > I am looking at ways to handle segV's gracefully without > letting a process die. I am aware of the siglongjmp() call and don't > know if that is the only way to handle segV's > > Any pointers on how to gracefully (?) handle segV and not > letting the proce

Re: Handling segV's

1999-10-15 Thread Graham Wheeler
On Fri, 15 Oct 1999, Dodge Ram wrote: > Hi, > > I am looking at ways to handle segV's gracefully without > letting a process die. I am aware of the siglongjmp() call and don't > know if that is the only way to handle segV's > > Any pointers on how to gracefully (?) handle segV and no

Handling segV's

1999-10-15 Thread Dodge Ram
Hi, I am looking at ways to handle segV's gracefully without letting a process die. I am aware of the siglongjmp() call and don't know if that is the only way to handle segV's Any pointers on how to gracefully (?) handle segV and not letting the process die will be of great help