[Tcl-bugs] [ tcl-Bugs-1997007 ] [open|] blocks when redirecting stderr to pipe (Vista)

[SourceForge.net <no...@so...>]

Bugs item #1997007, was opened at 2008-06-18 18:11
Message generated for change (Comment added) made by danckaert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1997007&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 24. Channel Commands
Group: current: 8.5.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koen Danckaert (danckaert)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: [open|] blocks when redirecting stderr to pipe (Vista)

Initial Comment:
This report refers to the standalone [pipe] command which is currently part of TclX, but proposed for inclusion in the core in TIP304.

When using the [open|] command in combination with [pipe] to redirect a process' stderr, the [open|] command sometimes blocks on Vista:
  pipe pr pw
  open |[list {*}$command 2>@ $pr]

This happens both with Tcl 8.5.2 and 8.6.

The application goes into "not responding" state, and doesn't wake up again. It's difficult to reproduce (only happens between 1/100 ... 1/1000 times on average), but it never happens when using "2@>1" instead. It doesn't happen either when redirecting to a fake pipe created by another open command.

Further investigation learnt that it actually blocks during the "CreateProcess" system call, which should not block according to Microsoft's documentation (it should either fail or succeed). The launched process is visible in the Task manager, but it is in "suspended" state and has a very low memory footprint (about 56K).


----------------------------------------------------------------------

>Comment By: Koen Danckaert (danckaert)
Date: 2008-06-20 16:34

Message:
Logged In: YES 
user_id=1388916
Originator: YES

Sorry for the typos. I actually used "2>@ $pw" and "2>@1".

Yes, my machine is dual-core. When I disable the second core in the BIOS,
it becomes much harder to reproduce the problem. Normally I can reproduce
it in just one minute, with a single core it took half an hour (and I could
reproduce only once up to now).

Some information about the nature of the processes:
- the children are simple console processes
- the main application exists in a console and GUI version; both have the
same problem

The main application has an option to set the number of children to be
launched in parallel. The higher this number, the earlier the problem shows
up. When set to 1, it's hard to reproduce (but it still happens sometimes).
The children are short-lived (<0.1s); the main app is set up such that a
new child is launched when a previous one dies.

I've not been able to reproduce the problem on XP. Though I should add
that that's a single-core machine.

Currently I can't use a debugger; this Vista machine is not my development
machine. However, I've used a process monitor to observe the system calls
made by the processes. I've attached the log file.

File Added: plm.log

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-06-19 23:34

Message:
Logged In: YES 
user_id=496139
Originator: NO

Also:
  - try on XP
  - is your machine a multi-processor by any chance ? (see 1939509)

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-06-18 21:34

Message:
Logged In: YES 
user_id=496139
Originator: NO

(Hope this one gets through, SF is read-only)

Two errors in your comment, but maybe these are just typos :-)

  - should be 2>@ $pw, not $pr
  - should be 2>@1 ,not 2@>1

Second, can you really try with TclX instead of 304 (to be sure) ?

Other things to try too:

  - exec {*}$cmd 2>@ $pw &
  - exec {*}$cmd >@ $pw &
  - exec {*}$cmd <@ $pr &
  - combinations

Also, once locked, can you attach to both parent and child with a debugger
?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1997007&group_id=10894