Terrence J. Doyle
2014-12-31 17:10:11 UTC
I've been having trouble running "package make" with the newly
compiled and installed ksh-20120929; i.e., "package make" would hang
after producing just a few lines of screen output. Perhaps the fact that
I'm piping the output of "package make" to tee has something to do with
it. Ksh-20120612 didn't seem to have any trouble with the first build,
although I didn't pipe that build though tee. To get around the problem
I used bash to run "package make" on subsequent builds.
However, I finally decided to take a closer look at the hang with
tracing turned on. The last command I saw before the hang was "exec
2>/dev/null". So, I typed "exec 2>/dev/null" at the command prompt, and
sure enough the shell hung. But, this was a harder hang than with
"package make". Control-c wouldn't stop it. I had to open another window
and kill the hung shell with SIGKILL. The system load remained low
through the hang, so it didn't appear to be an infinite loop.
In an attempt to confirm that this is a new problem with
ksh-20140929 I started ksh-20120612 and typed "exec 2>/dev/null" at the
command prompt. But, that version of the shell hung, too. I tried this
with all the versions of ksh I have, and they all hung. This no longer
seemed exemplary of the problem with "package make", so I decided to try
it with bash. Even bash hung. Then, I tried zsh. Zsh was the only shell
that didn't hang.
The fact that bash hung makes it clear that, whatever's going wrong
in interactive mode, it's not the same problem that's occurring with
"package make". So, I tried reproducing the "package make" hang through
a shell script. But, a simple shell script with "exec 2>/dev/null" in it
succeeds with no hang. I even tried piping the test script's output
through tee -- no hang.
I couldn't think of anything more to try other than using the
ksh-20140929 built with debug=1 to produce a back-trace from the point
of the hang(s). This was fairly straightforward with the interactive
hang. The back trace is attached as interactive_back_trace.txt. It was a
little more tricky for the "package make" hang. Here's what I did there:
$ mkdir /tmp/build
$ export INSTALLROOT=/tmp/build
$ cd "$PACKAGEROOT"
$ PATH=${PWD}/bin:$PATH
$ cd arch/darwin.ppc/bin
$ gdb ./ksh
(gdb) r -x package make
# Note: no pipe through tee.
# Wait for the following trace output:
+ exec
+ 2>/dev/null
^C
Program received signal SIGINT, Interrupt.
...
(gdb) where
This back trace is attached as package_make_back_trace.txt. The
differences between these two back traces makes it clear that these are
two separate bugs.
It's interesting that bash has the interactive bug. I'm using bash
version 4.3.30(5)-release.
Here are a couple more bits of information about the interactive hang:
exec 2>&- # Causes the same hang with the same back
trace.
exec >/dev/null # Succeeds. No hang.
exec >&- # Succeeds. No hang.
Could this indicate that this is a buffering problem since stderr is
character-buffered and stdout is line buffered?
Terrence Doyle
compiled and installed ksh-20120929; i.e., "package make" would hang
after producing just a few lines of screen output. Perhaps the fact that
I'm piping the output of "package make" to tee has something to do with
it. Ksh-20120612 didn't seem to have any trouble with the first build,
although I didn't pipe that build though tee. To get around the problem
I used bash to run "package make" on subsequent builds.
However, I finally decided to take a closer look at the hang with
tracing turned on. The last command I saw before the hang was "exec
2>/dev/null". So, I typed "exec 2>/dev/null" at the command prompt, and
sure enough the shell hung. But, this was a harder hang than with
"package make". Control-c wouldn't stop it. I had to open another window
and kill the hung shell with SIGKILL. The system load remained low
through the hang, so it didn't appear to be an infinite loop.
In an attempt to confirm that this is a new problem with
ksh-20140929 I started ksh-20120612 and typed "exec 2>/dev/null" at the
command prompt. But, that version of the shell hung, too. I tried this
with all the versions of ksh I have, and they all hung. This no longer
seemed exemplary of the problem with "package make", so I decided to try
it with bash. Even bash hung. Then, I tried zsh. Zsh was the only shell
that didn't hang.
The fact that bash hung makes it clear that, whatever's going wrong
in interactive mode, it's not the same problem that's occurring with
"package make". So, I tried reproducing the "package make" hang through
a shell script. But, a simple shell script with "exec 2>/dev/null" in it
succeeds with no hang. I even tried piping the test script's output
through tee -- no hang.
I couldn't think of anything more to try other than using the
ksh-20140929 built with debug=1 to produce a back-trace from the point
of the hang(s). This was fairly straightforward with the interactive
hang. The back trace is attached as interactive_back_trace.txt. It was a
little more tricky for the "package make" hang. Here's what I did there:
$ mkdir /tmp/build
$ export INSTALLROOT=/tmp/build
$ cd "$PACKAGEROOT"
$ PATH=${PWD}/bin:$PATH
$ cd arch/darwin.ppc/bin
$ gdb ./ksh
(gdb) r -x package make
# Note: no pipe through tee.
# Wait for the following trace output:
+ exec
+ 2>/dev/null
^C
Program received signal SIGINT, Interrupt.
...
(gdb) where
This back trace is attached as package_make_back_trace.txt. The
differences between these two back traces makes it clear that these are
two separate bugs.
It's interesting that bash has the interactive bug. I'm using bash
version 4.3.30(5)-release.
Here are a couple more bits of information about the interactive hang:
exec 2>&- # Causes the same hang with the same back
trace.
exec >/dev/null # Succeeds. No hang.
exec >&- # Succeeds. No hang.
Could this indicate that this is a buffering problem since stderr is
character-buffered and stdout is line buffered?
Terrence Doyle