X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: 4355 pipe handlers open at once - is this to be 'expect'ed? Date: Tue, 21 Mar 2006 12:21:05 -0000 Message-ID: <007401c64ce1$ed181990$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com :) Sorry for the terrible pun[*], but I just saw this error message scroll past in the middle of a gcc (simulator-based) testsuite run: -------------------------------------------------------------- doing compile pid is 2892 -2892 output is PASS: gcc.c-torture/execute/921117-1.c compilation, -O2 Simulator: rc 0, '' 1896 [main] expect 4872! _pinfo::dup_proc_pipe: DuplicateHandle failed, pid 4872, hProcess 0x46FC, Win32 error 5 2186 [main] expect 4872! _pinfo::dup_proc_pipe: DuplicateHandle failed, pid 4872, hProcess 0x46FC, Win32 error 5 2323 [main] expect 4872! pinfo::wait: Couldn't duplicate pipe topid 4872(0x46FC), Win32 error 5 PASS: gcc.c-torture/execute/921117-1.c execution, -O2 Testing gcc.c-torture/execute/921117-1.c, -O3 -fomit-frame-pointer -------------------------------------------------------------- I thought the value for hProcess looked a little suspiciously high, but on digging through it with Process Explorer (which appears to be playing nicely with cygwin programs these days) discovered that it was a real process handle value, because expect.exe had over four thousand anonymous pipes open: -------------------------------------------------------------- Process: expect.exe Pid: 2532 Type Name Handle Access Object Address Share Flags File \Device\NamedPipe\Win32Pipes.000009e4.00000685 0x4 0x00120189 0x888DE5D8 --- File \Device\NamedPipe\Win32Pipes.000009e4.0000071b 0x8 0x00120189 0x89ADE750 --- File \Device\NamedPipe\Win32Pipes.000009e4.00000688 0xC 0x00120189 0x86B40118 --- File \Device\NamedPipe\Win32Pipes.000009e4.000006db 0x10 0x00120196 0x877A30F0 --- File \Device\NamedPipe\Win32Pipes.000009e4.000006da 0x14 0x00120189 0x86736AF0 --- File \Device\NamedPipe\Win32Pipes.000009e4.00000709 0x18 0x00120189 0x880ACEF8 --- [.... many thousands of similar lines snipped! ....] File \Device\NamedPipe\Win32Pipes.000009e4.0000457d 0x4668 0x00120189 0x8875EB68 --- File \Device\NamedPipe\Win32Pipes.000009e4.0000457e 0x466C 0x00120196 0x869F64C8 --- File \Device\NamedPipe\Win32Pipes.000009e4.00004590 0x467C 0x00120196 0x881899B0 --- File \Device\NamedPipe\Win32Pipes.000009e4.000045ab 0x4684 0x00120196 0x88D2A2F0 --- File \Device\NamedPipe\Win32Pipes.000009e4.000045a2 0x4688 0x00120196 0x8844EA70 --- File \Device\NamedPipe\Win32Pipes.000009e4.000045b4 0x469C 0x00120196 0x87F90F90 --- -------------------------------------------------------------- As you know, most of what expect does involves invoking child processes and talking to them via their stdio channels. It strikes me that something may be leaking pipe handles to a popen'd child process (or similar), but before I investigate in depth I'd just like to know if it's perhaps an expected behaviour that these pipe handles should be kept lying around until the expect process exist. The child processes have all definitely exited, but is this what I'd see if the parent expect wasn't fully draining them in some way? cheers, DaveK [*] - Oh no I'm not! Not in the slightest, heh! -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/