Re: Win2k and cygwin memory leak

[Luc Hermitte <hermitte at free dot fr>]

* On Thu, Aug 07, 2003 at 08:42:57PM -0700, Andrew DeFaria <Andrew@DeFaria.com> wrote:
> Brian.Kelly@Empireblue.com wrote:
[You weren't responding to Brian message, but mine.]

> >>It has already been acknowledged several times over that it is not a
> >>problem of Cygwin's rather a problem of Windows.
> >I think we all agree to that. But unfortunatelly, so far, only Cygwin
> >seems affected by that problem.
> 
> Funny I don't see the problem. (Anybody else?)

May be I was mistaken and I was thinhing to another problem, but I'm
definitively not the only person who have notice a problem when running
cygwin.
Check the threads around:
    http://www.cygwin.com/ml/cygwin/2003-03/threads.html#01510
(about fork and ressources unavailable and jamming cygwin in 10 minutes)


Why are you playing dumb and denying some of us see the problem only
with cygwin ?

BTW, I respond to a remark from Christopher. Yes, probably other
programs are affected by this bug from Windows (/some of its functions).
But I haven't noticed any clear indication in this direction. 
However I have no doubt there is a problem the 100th time I run my
bash-wrapper (that launches gVim), or when I try to compile GNU program
like mutt -- I need to reboot three times and delete lines already
executed if I want to have mutt-1.5 with some specific patches.
So far, cygwin is the ultimate "developer" for this bug.

> >I guess cygwin is using a library not always correctly implemented. 
> >"Isn't there any workaround cygwin could use ? " is a typical question 
> >for many of us.
> Your asking for workarounds to another party's code. Personally I would 
> rather Cygwin folks focus more on functionality and genuine Cygwin 
> problems than fixing somebody else's problem.

I'm asking a workaround to another party code used by cygwin. If I know
that a particular function (from a third) is buggy/non portable, I won't
use it in my code, or at least, I'll try to be sure I use it under the
best conditions.
Unfortunatelly, it seems nobody knows which third party function is
buggy in that particular case.

> >>What else do you want?
> >Personnally, I hope, as the question will be raised again and again, 
> >that an expertise will emerge. Just knowing why there is a problem 
> >will be a big step ahead -- ie: which library/service pack/... is faulty.
> 
> And what are you doing to help identify the problem (seeing as YOU are 
> seeing the problem, YOU have the code and others have no clue what you 
> are doing exactly that might even cause your problem)?

I'm doing approximatelly:

tar xvf mutt-1.5.1.tar.gz | gzip -cd -
cd mutt-1.5.1
./configure
make

But what will be more interresting is: what is installed on the
system/how the system was installed. Because if some people are not
seeing the problem, it means THERE IS a solution.

> >This time, someone told us about a freeware that collects "forgotten"
> >memory. 
> Who "forgot" the memory? Right Windows - not Cygwin.

Did I said the contrary ?
I can also play dumb: "do you call buggy functions in your code ?"

> Is THAT the memory intensive process that you are running every 5
> minutes?!? Again, others do not have the problems that you have. I run
> Cygwin processes on Windows 2000 Servers and they stay up for months
> (Unfortunately sometimes one still needs to reboot servers for service
> packs, security fixes, etc).

I'm not Brian. My intentive process is named bash, and I don't run it
every 5 minutes.

> >BTW, if this program is an effective workaround, I think this will 
> >merit a topic in the FAQ.
> You speak as if everybody is experiencing this problem - we aren't!

If ten people are experiencing the problem, it worths fix it. Because
what the ten people will first think is: "damn! cygwin is buggy and
cannnot fork anymore". You and I know it's untrue. The unfortunate new
user of Cygwin won't.

> >Could we say that cygwin relies on a faulty library developped by
> >Microsoft? And that nobody has identified the faulty library?
> You could - but that would be a guess. And it is not Cygwin developers
> responsibility to figure out which library that is.

We don't feel the same. When I program a() that uses b(). If b() is
buggy under certain condition, i usually try to find/program b'() that
will ensure that my a() will always work as expected. That's _my_
responsability to use 3rd party code/library/API that works correclty.

May be there is a b'() in that case, may be not. I don't know yet. In a
month or two, I'll try to remember how gdb works and check this out --
I'll probably need assitance from people not having the problem as I'm
not able to compile big program.

By the mean, time I have some open-source stuff I've developped to fix
before unhappy users ask for refund.
And by an hour or two, i'll check if RAMpage is of any help.

> With this, and all other open source software, I suggest that if you are 
> unhappy with the product then return it and demand a fully refund :-) ! 
> Good luck!
-- 
Luc Hermitte

--
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/