Jim Meyering wrote:
In that case, I think we're just lucky that those malloc calls
seem to work. We'll need a more robust solution.
Right, I managed to hang dd with the following modifications:
- anticipatory gettext initialization (my patch)
- no gettext
- no fprintf (not even evaluating its
Jim Meyering wrote:
Thanks for the patch, but that `cure' seems worse than the disease.
I agree. The real good way to make this work on POSIX systems (without
assuming multithreading) is to use fork().
- Let the parent process fork a child process, block the signals SIGHUP,
SIGQUIT,
Bruno Haible wrote:
I agree. The real good way to make this work on POSIX systems (without
assuming multithreading) is to use fork().
- Let the parent process fork a child process, block the signals SIGHUP,
SIGQUIT, SIGPIPE in the parent, and watch the child's exit status.
If the exit
Bruno Haible [EMAIL PROTECTED] writes:
- Let the parent process fork a child process, block the signals SIGHUP,
SIGQUIT, SIGPIPE in the parent, and watch the child's exit status.
If the exit status of the child is 128 + SIGHUP/SIGQUIT/SIGPIPE,
print the statistics.
This 128 +
On Fri, Apr 08, 2005 at 01:34:41PM +0200, Bruno Haible wrote:
Jim Meyering wrote:
Thanks for the patch, but that `cure' seems worse than the disease.
I agree. The real good way to make this work on POSIX systems (without
assuming multithreading) is to use fork().
- Let the parent
Bruno Haible [EMAIL PROTECTED] wrote:
Guillaume Chazarain wrote:
As it prints a message for the first time, it has to
initialize gettext, and I'm not sure this qualifies for the do as
little as possible in a signal handler rule.
I agree. The list of guaranteed async-safe function calls on
Jim Meyering wrote:
If there is no better way to solve the problem, then I'd consider
leaving the code the way it is.
Don't forget, there is my workaround, it stills cause gettext() calls in
the signal handler,
but I cannot make it fail, unlike vanilla.
--- coreutils-5.3.0/src/dd.c
+++
Guillaume Chazarain [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
If there is no better way to solve the problem, then I'd consider
leaving the code the way it is.
Don't forget, there is my workaround, it stills cause gettext() calls in
the signal handler, but I cannot make it fail, unlike
Jim Meyering wrote:
Can you determine whether (with your patch) e.g., malloc is ever being
called from the signal handler?
Here is what I got when instrumenting malloc with a fprintf(stderr,
malloc(%d)\n) :
$ ./dd if=/dev/zero of=/dev/null
malloc(5)
malloc(60)
malloc(12)
malloc(388)
malloc(60)
There is a similar problem in csplit.c. The simplest fix there is to
not print an error message when an interrupt occurs and a file can't
be removed afterwards, and I've prepared a draft patch to do that,
which I'd like to test a bit more before installing.
The resulting csplit program still
Paul Eggert wrote:
Guillaume Chazarain [EMAIL PROTECTED] writes:
With recent linux distributions (using NPTL), dd can hang waiting on
a futex when being killed.
[...]
When dd gets a signal, it closes the input and output files, prints
some statistics, and exits. If it gets a second signal
Guillaume Chazarain [EMAIL PROTECTED] writes:
With recent linux distributions (using NPTL), dd can hang waiting on
a futex when being killed.
I'm not quite sure how to parse that, but it sounds like a problem
with some part of the system other than dd, not with dd itself.
When dd gets a
12 matches
Mail list logo
