URL: <http://savannah.gnu.org/bugs/?49023>
Summary: glibc - hurd_safe_{copyin, copyout, memmove, memset} broken Project: The GNU Hurd Submitted by: baccala Submitted on: Wed 07 Sep 2016 09:02:09 PM GMT Category: glibc Severity: 3 - Normal Priority: 5 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Reproducibility: Every Time Size (loc): None Planned Release: None Effort: 0.00 Wiki-like text discussion box: _______________________________________________________ Details: The hurd_safe_* routines currently fail to catch memory faults and instead deliver signals which, if uncaught, terminate the faulting task. The problem seems to lie in the interaction between the signal preemption code in hurd/ and sysdeps/mach/hurd/i386/exc2signal.c's exception2signal(): 38 case EXC_BAD_ACCESS: 39 switch (detail->exc_code) 40 { 41 case KERN_INVALID_ADDRESS: 42 case KERN_MEMORY_FAILURE: 43 *signo = SIGSEGV; 44 detail->code = posix ? SEGV_MAPERR : detail->exc_subcode; 45 break; Notice that if the 'posix' flag is set, detail->code becomes SEGV_MAPERR (#defined to be 1), instead of the faulting memory address, which the kernel provides in exc_subcode. However, the hurd_signal_preemptor structure, as it is used in hurd/catch-signal.c (see also the macro HURD_PREEMPT_SIGNAL_P), is used to compare detail->code to the memory range being accessed by the hurd_safe_* routine to determine if the signal should be preempted. The net result is that 1 (SEGV_MAPERR) is never in the memory range being accessed, so the signal is never preempted. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?49023> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/