Andi,
thanks for the response.
The code forks immediately and the new process segfaults immediately.
From an inspection of 'strace -f' on a working version, the next call
would have been setsid() . (The library call in the code is daemon(0,0)).
The original Makefile has an LDFLAG of -N (OMAGIC:
Andi,
thanks for the response.
The code forks immediately and the new process segfaults immediately.
From an inspection of 'strace -f' on a working version, the next call
would have been setsid() . (The library call in the code is daemon(0,0)).
The original Makefile has an LDFLAG of -N (OMAGIC:
Mark Studebaker <[EMAIL PROTECTED]> writes:
> I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap
> from 1994 that's been running without complaint
> on kernels for 11 years now consistently segfaults.
>
> I upgraded to a version 4 RPM (circa 2002) and that fixed it.
>
>
Mark Studebaker [EMAIL PROTECTED] writes:
I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap
from 1994 that's been running without complaint
on kernels for 11 years now consistently segfaults.
I upgraded to a version 4 RPM (circa 2002) and that fixed it.
If some
I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap
from 1994 that's been running without complaint
on kernels for 11 years now consistently segfaults.
I upgraded to a version 4 RPM (circa 2002) and that fixed it.
If some compatibility was broken on purpose, that's fine,
I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap
from 1994 that's been running without complaint
on kernels for 11 years now consistently segfaults.
I upgraded to a version 4 RPM (circa 2002) and that fixed it.
If some compatibility was broken on purpose, that's fine,
6 matches
Mail list logo
