Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#2230 exec / system commands hang in RedHat 8.0

obsolete: 8.4.1

Under RedHat Linux redhat 2.4.18-19.7.x #1

Application was compiled with

-nodefaultlibs -Xlinker -Bstatic -lstdc++ -lgcc
-Xlinker -Bdynamic -ldl -lc and -lpthread

tcl8.4.1 was NOT compiled with --enable-threads

The symptoms are as follows

The application opens and enters the tcl_shell_prompt

All the tcl_specific commands work fine.

But, when a system command or exec command is issued,
the tcl hangs for a long time.. on issuing a ctrl-C the
following stack trace was generated:

#0 0x402fff74 in __libc_read () at __libc_read:-1
#1 0x0887c36c in __DTOR_END__ ()
#2 0x0866295f in TclCreatePipeline (interp=0x913f838,
argc=1, argv=0x91d0890, pidArrayPtr=0xbfffdab8,
outPipePtr=0xbfffdac4,errFilePtr=0xbfffdac0) at
#3 0x08662ca1 in Tcl_OpenCommandChannel
(interp=0x913f838, argc=3, argv=0x91d0890, flags=12) at
#4 0x0864bf54 in Tcl_ExecObjCmd (dummy=0x0,
interp=0x913f838, objc=4, objv=0xbfffdc44) at
#5 0x085fce4c in TclEvalObjvInternal
(interp=0x913f838, objc=4, objv=0xbfffdc44,
command=0x91d0818 "exec >&@stdout <@stdin /bin/ls",
length=30, flags=0) at ./../generic/tclBasic.c:3048
#6 0x085fdb20 in Tcl_EvalEx (interp=0x913f838,
script=0x91d0818 "exec >&@stdout <@stdin /bin/ls",
numBytes=30, flags=262144) at ./../generic/tclBasic.c:3646
#7 0x085fe12b in Tcl_EvalObjEx (interp=0x913f838,
objPtr=0x91d11c0, flags=262144) at
#8 0x086670fd in Tcl_UplevelObjCmd (dummy=0x0,
interp=0x913f838, objc=4, objv=0x9141348) at
#9 0x085fce4c in TclEvalObjvInternal
(interp=0x913f838, objc=6, objv=0x9141340, command=0x0,
length=0, flags=0) at ./../generic/tclBasic.c:3048
#10 0x0862b5cf in TclExecuteByteCode (interp=0x913f838,
codePtr=0x9165688) at ./../generic/tclExecute.c:1431
#11 0x0862a5a3 in TclCompEvalObj (interp=0x913f838,
objPtr=0x9147578) at ./../generic/tclExecute.c:1008
#12 0x08667831 in TclObjInterpProc
(clientData=0x914ba58, interp=0x913f838, objc=2,
objv=0x91cf5d0) at ./../generic/tclProc.c:1082
#13 0x085fce4c in TclEvalObjvInternal
(interp=0x913f838, objc=2, objv=0x91cf5d0, command=0x0,
length=0, flags=0) at ./../generic/tclBasic.c:3048
#14 0x085fccf5 in TclEvalObjvInternal
(interp=0x913f838, objc=1, objv=0x914133c, command=0x0,
length=0, flags=0) at ./../generic/tclBasic.c:3001
#15 0x0862b5cf in TclExecuteByteCode interp=0x913f838,
codePtr=0x91d4ff8) at ./../generic/tclExecute.c:1431
#16 0x0862a5a3 in TclCompEvalObj (interp=0x913f838,
objPtr=0x9147440) at ./../generic/tclExecute.c:1008
#17 0x085fe15e in Tcl_EvalObjEx (interp=0x913f838,
objPtr=0x9147440, flags=131072) at
#18 0x0863dd9c in Tcl_RecordAndEvalObj
(interp=0x913f838, cmdPtr=0x9147440, flags=131072)
at ./../generic/tclHistory.c:142
#19 0x08655801 in Tcl_Main (argc=1, argv=0xbfffefa4,
appInitProc=0x80f26f8 <InitCom>) at
#20 0x080f6f9f in main ()
#21 0x4023b657 in __libc_start_main (main=0x80f6984
<main>, argc=1, ubp_av=0xbfffefa4, init=0x80f0678
<_init>, fini=0x873b4dc <_fini>, rtld_fini=0x4000dcd4
stack_end=0xbfffef9c) at

This occurs just in Linux Architecture... But not under


  • Jeffrey Hobbs
    Jeffrey Hobbs

    • priority: 5 --> 7
  • Logged In: YES


    Followup on this, I further investigated problem to

    TclpCreateProcess under tclUnixPipe.c

    Here the system waits indefinitely in this line:

    484 TclpCloseFile(errPipeOut);
    485 errPipeOut = NULL;
    487 fd = GetFd(errPipeIn);
    488 count = read(fd, errSpace, (size_t)
    (sizeof(errSpace) - 1));

    for an input after the process has been forked out.

    • milestone: --> obsolete: 8.4.1
  • Logged In: YES

    Note: The docs.sun.com link is 404. :(

  • Logged In: YES
    Originator: NO

    I don't understand the setup. Is it vanilla tclsh or an embedding case ? What's the 'system' Tcl command mentioned ?
    This is so enormous, we should have seen it many more times in vanilla tclsh...
    If somebody is able to reproduce, I'd strongly suggest an strace to see what happens on the fork-error pipe. But source diving shows no hole, since the errPipe is CLOEXEC, and written to if execve fails.
    Otherwise I propose to close on the grounds that it was a red herring (maybe a bug in the embedding app).

  • Timing out on request for followups.

    • status: open --> pending-works-for-me