The bogus paths in the -p output can be fixed by changing line 708 in
read.c from this:
if (r < 2)
to this:
if (!r)
I can reproduce the other problem, but I haven't tracked it down yet.
It doesn't seem to be a memory error, at first blush--anyway, Purify
doesn't com
It seems like you've got some serious memory corruption here, but I've
never seen anything like this before.
You don't have a copy of Purify lying around anywhere, have you? If
not, the dmalloc library will do; if you have a copy you can configure
make with --enable-dmalloc and rebuild and see i
Aloha,
I'm trying to debug a problem of some sort in a make. The output from
make -p is included below. If you've seen something like the original
problem before, I'd appreciate a clue. The actual commands lost something
between the "%: %.c" rule shown in the dump and their execution - the RM
What I want to do is compare the values configure found in your config.h
that you sent me to decide exactly how make is handling signals.
Depending on what the system supports it can deal with children, etc. in
various different ways.
What I need to do is sit down and figure out whether the probl
On Fri, 19 May 2000, Paul D. Smith wrote:
> PS. IMHO looping if stat(2) fails with EINTR is a much simpler, and
> probably much more efficient, solution to this problem than trying
> to block the signals.
>
> Was there a particular reason you were dissatisfied with the EINTR
> lo
PS. IMHO looping if stat(2) fails with EINTR is a much simpler, and
probably much more efficient, solution to this problem than trying
to block the signals.
Was there a particular reason you were dissatisfied with the EINTR
loop? That's a pretty common idiom, I believe.
--
Paul -
After looking at this problem for a while longer, I've come up with the
attached patch which solves the problem (at least for #ifdef POSIX).
When name_mtime() is called, SIGCHLD is not set to SIG_IGN or SIG_DFL,
but has a signal handler assigned. This causes the signal t
