This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: cygserver handle leak problem


On 20 January 2008 15:20, Huang Bambo wrote:

> To duplicate the problem,
> 1. Run windows task manager , show handles of cygserver.
> 2. Run my program, it will create a message que, you will find the
> cygserver process's handle increased by 4
> 3. Run ipcs command, you will find the que.
> 4. Run ipcrm command to remove this command, you will find the
> cygserver's handles will only decrease by 2
> 5, go to 2 ,repeat the operation, you will find the handles owned by
> cygserver will only increase.

  You are seeing the cache growing after cygserver initial startup, but it
bottoms out quickly.  I ran this command to generate a script file:

$ for (( x = 1 ; x < 40 ; x++ )) ; do echo -e "./OceProxy.exe\nipcs\nipcrm-q
$(( $x * 65536 )) " ; done | tee foosh

then cut and pasted the content into a console, while running 

$ /usr/sbin/cygserver.exe --debug 2>&1  | tee cs5.log

in a separate console (CYGWIN=server in both).  The effect was to repeatedly
run your test, deleting the newly created queue after each run.  Each time it
got to OceProxy.exe, it paused, and I noted the number of handles in cygserver
using sysinternals' process explorer; then pressed Ctrl+C to kill OceProxy and
let the loop delete the queue and repeat.  Here are the numbers of handles I
observed each time OceProxy.exe was in the running state:

88
95
97
99
101
103
105
107
109
111
113
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
109

  The last 109 is after the entire script finished; it's the resting level at
that point, and each further time you run and then kill OceProxy.exe you see
the number of handles rise and fall 109 -> 115 -> 109.

  I'm guessing there's some kind of handle caching going on.  I saved a dump
of the handles on two successive goes round the loop and diffed them:

/win/i/xtool/attatchs/OceProxyFrameworkDemo $ grep ^- a-vs-b.txt
-0x168  Event           0x001F0003      0x8213F7A0
-0x16C  Event           0x001F0003      0x81B24140
-0x160  File    \Device\NamedPipe\cygwin_lpc    0x0012019F      0x82256F88
-0x180  File    \Device\NamedPipe\cygwin_lpc    0x0012019F      0x8214A1C8
-0x144  Process OceProxy.exe(324)       0x001F0FFF      0x81D28BA0
-0x178  Process OceProxy.exe(2064)      0x001F0FFF      0x81DE0020
/win/i/xtool/attatchs/OceProxyFrameworkDemo $ grep ^\+ a-vs-b.txt
+0x160  Event           0x001F0003      0x821666C0
+0x17C  Event           0x001F0003      0x81E64520
+0x180  Event           0x001F0003      0x8225DCA0
+0x16C  File    \Device\NamedPipe\cygwin_lpc    0x0012019F      0x81416028
+0x184  File    \Device\NamedPipe\cygwin_lpc    0x0012019F      0x81662AA8
+0x144  Process OceProxy.exe(508)       0x001F0FFF      0x818C8020
+0x18C  Process OceProxy.exe(2084)      0x001F0FFF      0x81DA3920
+0x178  Thread  cygserver.exe(1516): 2008       0x001F03FF      0x814891A0

  So, each time we run the test, then stop it and delete the queue, it opens
and closes two events, two files and two process handles; and at least to
start with, it gains a thread and an event each time round.  Perhaps there's
some kind of cache of worker threads in cygserver, each of which has a
shutdown event associated with it?  It may be that it's firing up new threads
more often than it needs considering that the old queue has gone away.  We'll
need to take a look at the source - I've no idea how cygserver works
internally.


    cheers,
      DaveK
-- 
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]