NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lib/45572: EFAULT from time(3)

The following reply was made to PR lib/45572; it has been noted by GNATS.

From: David Holland <>
Subject: Re: lib/45572: EFAULT from time(3)
Date: Sun, 6 Nov 2011 03:02:35 +0000

 On Sun, Nov 06, 2011 at 02:20:05AM +0000, Christos Zoulas wrote:
  >  |  If the stars are aligned just so, it *can* fail and return EFAULT.
  >  How?
 If it's right off the end of the stack, only the stack address passed
 to gettimeofday() will be invalid.
  >  |  Also, based on this text in errno(2) I think it would be better to
  >  |  change the man page back:
  >  |  
  >  |     14 EFAULT Bad address.  The system detected an invalid address in
  >  |         attempting to use an argument of a call.  The reliable detection
  >  |         of this error cannot be guaranteed and when not detected may
  >  |         result in the generation of a signal, indicating an address vio-
  >  |         lation, which is sent to the process.
  >  |  
  >  |  I have argued in the past that all syscalls returning EFAULT should
  >  |  also post SIGSEGV; there are a number of reasons that's desirable.
  >  And the siginfo information should point to what PC? How is the debugger
  >  supposed to behave?
 The PC address from the trapframe. As far as the debugger's concerned
 the syscall instruction faulted. Getting the right fault address out
 is a bigger hassle but it's hardly impossible.
 The primary reason it's desirable: if you've installed a SIGSEGV
 handler, because you're doing, say, generational garbage collection,
 or you're an object database using page faults to move things in and
 out of memory, you don't want faults that occur during syscalls to get
 lost or bypass the handler.
 Anyway, I'm not saying we should rush out and do this, just that
 receiving SIGSEGV in place of or in addition to EFAULT is already
 documented behavior.
 David A. Holland

Home | Main Index | Thread Index | Old Index