DF and signal handlers

[Nikodemus Siivola]

On 3/5/08, Debian Bug Tracking System <owner at bugs.debian.org> wrote:

> tag 469058 + patch
>  Bug#469058: sbcl doesn't reset direction flag upon exit
>  There were no tags set.
>  Tags added: patch

Thanks for the patch, but... while I agree that it is good to change
SBCL to reset the direction flag every time it is diddled, instead of
just before calling C, I don't think SBCL is actually at fault here.

 1. SBCL does actually reset DF before any call to foreign (GCC generated) code.
    See line 236 in src/compiler/x86/c-call.lisp, and line 125 in
    src/runtime/x86-assem.S.

    (It is possible I'm missing out a call-path here, but even so, read on and
    see if my fears are unfounded or not.)

 2. If the problem was due to a foreign call, it should be deterministic.

 3. If the problem was due to _returning_ to main(), it should be deterministic.

What I suspect is actually going on (especially considering your
statement that compiling signals/ with 4.2 avoided the issue) is that
a signal handler is entered while DF is set.

If this is the case, then clearing it right after each REP loop where
SBCL uses it just makes seeing the bug much more unlikely -- but not
impossible in the presence of async signals.

If so, this may also explain some _very_ hard to reproduce faults we
have seen over the years: using a pre 4.3-GCC compiled libc, a signal
at an in opportune moment in the middle of a REP loop could clear DF!
Yikes!

I'm not sure what is The Right Thing here, though. Should SBCL (and
_any_ program that ever sets DF!) save, clear, and restore DF in its
signal handlers? Should libc/kernel do that? Should signals be blocked
before ever setting DF? Is setting DF Just A Bad Idea?

Cheers,

 -- Nikodemus