Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange signal handling (FreeBSD 4.8) #8270

Closed
vicuna opened this issue Sep 7, 2003 · 2 comments
Closed

Strange signal handling (FreeBSD 4.8) #8270

vicuna opened this issue Sep 7, 2003 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Sep 7, 2003

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:

    Objective Caml version 3.07+beta 2

Sys.set_signal Sys.sigalrm (Sys.Signal_handle (fun _ -> prerr_endline

"SIGNAL"));;

  • : unit = ()

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

@vicuna
Copy link
Author

vicuna commented Sep 9, 2003

Comment author: administrator

Hi Gerd,

Sys.set_signal Sys.sigalrm (Sys.Signal_handle (fun _ -> prerr_endline

"SIGNAL"));;

  • : unit = ()

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.

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...

Cheers,

  • Xavier

@vicuna
Copy link
Author

vicuna commented Sep 9, 2003

Comment author: administrator

See #8271. At this point, looks like a problem in FreeBSD's libc_r.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant