Comment 18 for bug 57731

Hi,

> By interpreting the 1st argument as an address and reading the value on this address, I get a 0 for the first three lines of my output (which are the futex calls).

No surprise for the first one because you just pushed a 0 at it to
unblock your process.
For the later ... I just wonder where is it from in the code (which lib,
which function ?).
You may try to send a SEGV signal to your process.
If it has be started under no limit for core (ulimit -c unlimited) you
should have a core dumped that could help you to know more about this
context with a debugger ...

> Very nice how you use awk and the created header file in the middle of your code. I tried it. It works ;-)

Yes, awk is a very fine and simple program for such a job.
The basic idea was to "extract" names of syscall regardless of your
system (32|64 bits, distro ...) and not to hard to regenerate if you
change some version of your box.
You just have to feed it with the correct header file ...

The difficulty now is to know how many arguments have been passed to
your syscall (and also the nature of those arguments).
That is mainly why strace is a very great tool and should be difficult
to maintain ...

>
> A few answers ago, you said restoring the signal handler is not
> neccessary. Is this a general fact or does it only apply to some kernel
> versions/architectures?

Well, historically in the Unix world there were two main branches of
Unices, the System V created by the Bell Labs. and the BSD created at
Berkeley University.
Many years ago, on System V Unices you had to restore the handler from
within the handler just like you did in your program. On BSD, the
management of signal
were cleaner and much more like you can see on Linux today, you could
specify if the handler should be reseted or not.
Except that the default behaviour is inverted.
On Linux today, the default is to keep the handler, and only an explicit
SA_ONESHOT or SA_RESETHAND prevents it.
I suppose there is a Posix on it ...