X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.7 required=5.0 tests=AWL,BAYES_40,RP_MATCHES_RCVD,SPF_HELO_PASS
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Mark Geisert <mark AT maxrnd DOT com>
Subject:	Re: [bash or DLL] Memory leak in childs
Date:	Sun, 24 Jul 2011 03:41:13 +0000 (UTC)
Lines:	48
Message-ID:	<loom.20110724T051134-526@post.gmane.org>
References:	<loom DOT 20110718T073757-2 AT post DOT gmane DOT org> <loom DOT 20110718T083650-815 AT post DOT gmane DOT org> <loom DOT 20110719T064243-907 AT post DOT gmane DOT org> <loom DOT 20110719T092021-102 AT post DOT gmane DOT org> <loom DOT 20110719T101702-272 AT post DOT gmane DOT org> <loom DOT 20110720T032257-444 AT post DOT gmane DOT org> <4E26D160 DOT 8010004 AT valdetaro DOT com> <CANs8wdA2sqpu+bW6k5narrxCvxNF7U2dpYKLQOnJQP6R9C3QFA AT mail DOT gmail DOT com> <4E2871B5 DOT 4000101 AT cygwin DOT com> <CANs8wdBGx0X77dg3VcQfd+h8F-1nk5xnyLFbwjKPJ6O46-V23g AT mail DOT gmail DOT com>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

AZ 9901 writes:
> 2011/7/21 Larry Hall (Cygwin) :
> > Your best bet is to report the problem to the provider of the product

    ^^^^^^^^^^^^^ emphasis mine

> > that's interfering.  You should be able to zero in on the product by
> > booting into safe mode and then turning on, one by one, the services
> > that safe mode omits and running the test.  When you see the problem
> > again, you'll know what product is responsible.
> >
> > Another alternative is to try a snapshot.
> >
> > <http://cygwin.com/snapshots/>
> >
> > There have been some recent changes that could help in your situation.

> The fact is that my scripted tools are deployed on several customers'
> production environments, so it's unfortunately quite difficult (let's
> say impossible) to find for each one of them the responsible product,
> hoping it could be corrected.
> Quite problematic situation :-/
> 
> I tested last DLL snapshot (2011-07-21), problem is still present :
> http://img685.imageshack.us/img685/2394/forkq.jpg

I tried your example on my quad-core Windows XP machine and don't see the
increased memory usage over time.  On your machine it's likely to be BLODA. 
Which BLODA?  We can't tell because you haven't provided the basic debugging
information needed to try to identify it.  As mentioned earlier in this thread,
that would be the output of 'cygcheck -svr', *attached* not appended to your
next post on this topic.

<http://cygwin.com/faq/faq.using.html#faq.using.bloda> is the list of known
dodgy apps (what we call BLODA).  Have you looked at that list to see if you're
running any of those apps on your machine?

Your first post mentioned that the increased memory stayed "used" even when you
closed the Cygwin window.  That is a hallmark of BLODA.  Corinna explained why
Cygwin can't accomplish that feat elsewhere in this thread.

One has to start somewhere.  There is no magic "fix it" button for this issue. 
Please provide the basic debugging info and we'll see what we can do.
Respectfully,

..mark




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -