You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 1820 Reporter: administrator Status: closed Resolution: not a bug Priority: normal Severity: minor Category: ~DO NOT USE (was: OCaml general)
I am currently debugging a GODI problem that only occurs if it is run on
FreeBSD. It is a very strange problem, and may also be libc-related,
because there is a discrepancy between the sources and the actually performed
system calls.
If one defines a signal handler with Sys.set_signal, strace outputs that
sigaction is called with SA_RESTART and SA_SIGINFO flags, e.g.
for an attempt to define a SIGALRM handler. I have no explanation for
that, because after configuration the C macro POSIX_SIGNALS is defined,
and the sigaction call in byterun/signal.c looks differently. Especially
SA_RESTART hurts me, but that's not all.
The other, more serious problem is that the signal mask is not properly
reset when the signal happens in a blocking section. This means, everything
is ok for this situation:
(I do "kill -SIGALRM " from another terminal.) However, without the
"while" loop, only the first signal is executed, and the other signals
are ignored. If one prints Unix.sigprocmask SIG_BLOCK [], the output
is [14], i.e. SIGALRM is blocked. However, in the strace output there is
no hint why the signal mask is changed.
This all looks like that there is something wrong in the libc or in the
kernel, but it might also be bad initialization, I don't know. Another
observation is that ocamlrun is linked against libc_r and not libc, and
that the signal handlers seem to be "overloaded" (in the strace output,
often additional system calls are done after a signal that have nothing
to do with ocaml).
Further data:
OS: FreeBSD 4.8
Ocaml version: 3.07b2 (not tested with previous versions)
gcc: 2.95.4
libc: libc_r.so.4
Gerd Stolpmann
The text was updated successfully, but these errors were encountered:
(I do "kill -SIGALRM " from another terminal.) However, without the
"while" loop, only the first signal is executed, and the other signals
are ignored. If one prints Unix.sigprocmask SIG_BLOCK [], the output
is [14], i.e. SIGALRM is blocked. However, in the strace output there is
no hint why the signal mask is changed.
I tried this example under Linux and Tru64 Unix, and the behavior is
as expected: SIGALRM is not blocked after the first delivery.
strace on Linux shows the expected behavior:
if signal occurs in a blocking section, the kernel blocks the signal
during delivery, then unblocks it on signal return (sigreturn() sigcall);
if signal occurs outside a blocking section (as in your while true
example), ocamlrun blocks the signal while executing the handler code,
then unblocks it on return.
So, I suspect a problem with FreeBSD's libc_r. It's hard to make
signals and POSIX threads work together correctly (I'm speaking from
experience with LinuxThreads...), so I wouldn't be surprised that
there are some loose ends there in FreeBSD's thread library.
This makes me wonder whether the new thread configuration policy in 3.07
(configure for POSIX threads whenever they are available) is good.
If POSIX threads are activated, ocamlrun must be linked with the
thread-enabled libc. If the latter has bugs affecting even
single-threaded code, we have a bit of a problem...
Original bug ID: 1820
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Gerd Stolpmann
Version: 3.07beta2
OS: FreeBSD 4.8
Submission from: p50816b48.dip0.t-ipconnect.de (80.129.107.72)
Hello,
I am currently debugging a GODI problem that only occurs if it is run on
FreeBSD. It is a very strange problem, and may also be libc-related,
because there is a discrepancy between the sources and the actually performed
system calls.
If one defines a signal handler with Sys.set_signal, strace outputs that
sigaction is called with SA_RESTART and SA_SIGINFO flags, e.g.
sigaction(SIGALRM, {0x28133264, ~[], SA_RESTART|SA_SIGINFO}, NULL) = 0
for an attempt to define a SIGALRM handler. I have no explanation for
that, because after configuration the C macro POSIX_SIGNALS is defined,
and the sigaction call in byterun/signal.c looks differently. Especially
SA_RESTART hurts me, but that's not all.
The other, more serious problem is that the signal mask is not properly
reset when the signal happens in a blocking section. This means, everything
is ok for this situation:
Sys.set_signal Sys.sigalrm (Sys.Signal_handle (fun _ -> prerr_endline
"SIGNAL"));;
while true do () done;;
SIGNAL
SIGNAL
SIGNAL
(I do "kill -SIGALRM " from another terminal.) However, without the
"while" loop, only the first signal is executed, and the other signals
are ignored. If one prints Unix.sigprocmask SIG_BLOCK [], the output
is [14], i.e. SIGALRM is blocked. However, in the strace output there is
no hint why the signal mask is changed.
This all looks like that there is something wrong in the libc or in the
kernel, but it might also be bad initialization, I don't know. Another
observation is that ocamlrun is linked against libc_r and not libc, and
that the signal handlers seem to be "overloaded" (in the strace output,
often additional system calls are done after a signal that have nothing
to do with ocaml).
Further data:
OS: FreeBSD 4.8
Ocaml version: 3.07b2 (not tested with previous versions)
gcc: 2.95.4
libc: libc_r.so.4
Gerd Stolpmann
The text was updated successfully, but these errors were encountered: