Double piping breaks LIBCx

[dmik]

This command run from CMD.EXE:

dash -c "uname | cat" | b

gives this crash provided that b is a non-existent command:

SYS1041: The name b is not recognized as an
internal or external command, operable program or batch file.

_fmutex operation failed:  LIBC Heap request

Killed by SIGABRT
pid=0x0058 ppid=0x0057 tid=0x0001 slot=0x0074 pri=0x0200 mc=0x0002 ps=0x0017
C:\USR\BIN\DASH.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

This crash seems to happen while LIBCx is holding its global mutex so all other processes using it become affected: sooner or later they will crash with an assertion on any attempt to lock this mutex with OS/2 error 105 (ERROR_SEM_OWNER_DIED). This is one example of such a crash:

C:>libcx-stats.exe
0006e31d 01 ff 0000 Asrt: Assertion Failed!!!
0006e31d 01 ff 0000 Asrt: Function: <NULL>
0006e31d 01 ff 0000 Asrt: File:     D:/Users/dmik/rpmbuild/BUILD/libcx-0.6.0/src/shared.c
0006e31d 01 ff 0000 Asrt: Line:     185
0006e31d 01 ff 0000 Asrt: Expr:     arc == NO_ERROR
0006e31d 01 ff 0000 Asrt: 105

While the original problem seems not be related to LIBCx itself but rather to some LIBC fork bug, we should not let it screw LIBCx up that badly.

[dmik]

Note that if I use ash instead of dash, the failure is a bit different:

C:>ash -c "uname | cat" | b
SYS1041: The name b is not recognized as an
internal or external command, operable program or batch file.

LIBC PANIC!!
LIBC fork: Child aborting fork()! rc=0xfffffffc
pid=0x0053 ppid=0x0051 tid=0x0001 slot=0x0089 pri=0x0200 mc=0x0000 ps=0x0010
C:\USR\BIN\ASH.EXE
DOSCALL1 1:00001bee
cs:eip=005b:1ffc1bee      ss:esp=0053:0013ff20      ebp=0013ff20
 ds=0053      es=0053      fs=150b      gs=0000     efl=00000202
eax=00000000 ebx=0013ff40 ecx=00150048 edx=00000001 edi=1afe0008 esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

This is still some LIBC fork break, but since ash doesn't use LIBCx, LIBCx doesn't become affected.