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 <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
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
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index