Re: MADV_FREE and wait4 EFAULT

On Fri, Apr 19, 2013 at 5:49 AM, Konstantin Belousov wrote: > It would be of some interest to see the evidence. > Certainly. Here is some of the debugging messages that I added to my application. The first line is a print statement that executes after the system call returns. (As an aside, we

Re: MADV_FREE and wait4 EFAULT

On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov wrote: > Did you ensured with e.g. ktrace and procstat -v that your assumptions > hold, i.e. the addresses supplied as wait4(2) arguments are valid ? > Please provide the minimal test case demonstrating the behaviour. > Yes. I instrumented my

MADV_FREE and wait4 EFAULT

I am seeing wait4 system calls failing with an EFAULT and I am trying to understand what might be going wrong. An inspection of the wait4 implementation suggests the opportunity for EFAULT is within its invocations of copyout. In my situation, the status and rusage pointer arguments contain addr

Re: close(2) while accept(2) is blocked

On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon wrote: > But the summary seems to be is that currently it is not possible to break > a thread > out of accept(2) (at least without resorting to signals). > This is a known problem for Java. Closing a socket that another thread is block on is suppose

Re: binary compatibility query

Kris & Julian Thank you for clarifiying the compatibility situation. This information was exactly what I was looking for. I have a follow-up question based on this remark... On 5/5/08, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Actually we don't attempt to keep this form of ABI compatibility (

binary compatibility query

FreeBSD Hackers, I have a general question about the compatibility of FreeBSD binaries within major releases. If I build a binary for a given release of FreeBSD can I make a reasonable guarantee that the binary will run on both previous and subsequent minor releases of the same major release? In

Re: critical floating point incompatibility

On 12/20/07, Peter Jeremy <[EMAIL PROTECTED]> wrote: > I believe this is an oversight. See the thread beginning > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html Thanks for the pointer into the -stable mailing list. The incorrect precision control bits is a serious qu

critical floating point incompatibility

Developers, There is a critical incompatibility between the floating point environment of the 32-bit compatibility environment of AMD64 systems and a genuine i386 system. The default setting of the x87 floating point control word on the i386 port is 0x127F. Among other things, this value sets th