Re: [bash or DLL] Memory leak in childs
On Jul 18 06:52, Mark Geisert wrote: > Heiko Elger writes: > > I just can confirm the same problem with latest cygwin1.dll > > (cygwin1-20110713.dll.bz2) on Windows 7/64 (fast XEON CPU). > > I've seen this problem while testing other "exiter" - problem > > with the following script. > [...] > > #!/bin/sh > > set -e > > while true; do > >./exiter.exe > > echo -n $? > > done > [...] > > The virtual memory (windows task manager) grows and grows over the time. > > > > The cygwin eats all memory til no more available. > > But after alle cygwin processes are closed the memory is freed. > > With respect, what you and the OP are seeing happens to be one of the primary > manifestations of BLODA. Please show that you have ruled that out as a > possible cause; after that we can consider other explanations. > > For example, run 'cygcheck -svr' and post its output, *as an attachment*, in > a followup post. cygcheck checks for evidence of BLODA installations and is > the first step towards ruling out this possibility. You could also visually > scan the list of apps in the link I posted earlier in this thread, just to > make sure you don't have one of these dodgy apps installed. > > I believe my first problem report to this list several years ago was this > very observation about increasing virtual memory consumption for no good > reason. > In my case it was BLODA, an anti-virus program that I was luckily > able to configure to not scan the Cygwin installation tree. > HTH, For completeness, I tested both testcases, the one from the OP and the one from Heiko (albeit the one using only Cygwin executables) with the latest Cygwin from CVS. I couldn't observer any raise in memory consumption over 15 minutes of runtime of both scripts. The OP also wrote: > Once Cygwin closed, memory is still used, not released. This is definitely not a feat of Cygwin. Cygwin is just a user-space DLL. It's not a standalone application nor is it a part of the system. All memory reserved by the application is free'd as soon as the application exits. All (shared) memory reserved by the Cygwin DLL is free'd as soon as the last process using it exits. If all Cygwin processes exited, it must be a non-Cygwin process holding on to the memory. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: please fix heap_init
On Jul 18 05:20, jojelino wrote: > this is following of 'infinite recursion in git-svn' > #to reproduce this problem, > #1. please use latest cvs trunk > #2. set HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\heap_chunk_in_mb=0x400 > Starting program: /usr/bin/perl.exe /usr/lib/git-core/git-svn clone > -rHEAD http://google-perftools.googlecode.com/svn/trunk/ > [New Thread 5352.0x9c4] > warning: section .gnu_debuglink not found in > /cygdrive/d/cygwin/bin/cygwin1.dbg > > Breakpoint 1, heap_init () at /tmp/winsup/winsup/cygwin/heap.cc:81 > 81start_address = roundup2 (start_address + > mbi.RegionSize, > 2: largest_found_size = 0x3568 > 1: start_address = 0x5569 > (gdb) i b > Num Type Disp Enb AddressWhat > 1 breakpoint keep y 0x61078875 in heap_init() >at > /tmp/winsup/winsup/cygwin/heap.cc:81 > breakpoint already hit 1 time > (gdb) > > start_address continues to grow, and in heap.cc:94 it is used as > base address. > which is not we wanted. and sbrk could fail if it used up MINHEAP_SIZE. This is what we want. Did you compare the behaviour of the code with the comments in the code? Can you please *explain* what is wrong with the code? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: please fix heap_init
On Jul 18 09:11, Corinna Vinschen wrote: > On Jul 18 05:20, jojelino wrote: > > this is following of 'infinite recursion in git-svn' > > #to reproduce this problem, > > #1. please use latest cvs trunk > > #2. set HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\heap_chunk_in_mb=0x400 > > Starting program: /usr/bin/perl.exe /usr/lib/git-core/git-svn clone > > -rHEAD http://google-perftools.googlecode.com/svn/trunk/ > > [New Thread 5352.0x9c4] > > warning: section .gnu_debuglink not found in > > /cygdrive/d/cygwin/bin/cygwin1.dbg > > > > Breakpoint 1, heap_init () at /tmp/winsup/winsup/cygwin/heap.cc:81 > > 81start_address = roundup2 (start_address + > > mbi.RegionSize, > > 2: largest_found_size = 0x3568 > > 1: start_address = 0x5569 > > (gdb) i b > > Num Type Disp Enb AddressWhat > > 1 breakpoint keep y 0x61078875 in heap_init() > >at > > /tmp/winsup/winsup/cygwin/heap.cc:81 > > breakpoint already hit 1 time > > (gdb) > > > > start_address continues to grow, and in heap.cc:94 it is used as > > base address. > > which is not we wanted. and sbrk could fail if it used up MINHEAP_SIZE. > > This is what we want. Did you compare the behaviour of the code with > the comments in the code? Can you please *explain* what is wrong with > the code? I had a closer look and I found a bug in the code. When no memory area has been found which is bigger than the requested memory area, the code was supposed to allocate the largest memory area found. At this point the code used start_address accidentally, rather than largest_found. Is that what you were refering to? If so, that should be fixed now in CVS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: please fix heap_init
On 2011-07-18 오후 5:45, Corinna Vinschen wrote: I had a closer look and I found a bug in the code. When no memory area has been found which is bigger than the requested memory area, the code was supposed to allocate the largest memory area found. At this point the code used start_address accidentally, rather than largest_found. Is that what you were refering to? If so, that should be fixed now in CVS. Corinna Maybe I should have added your quote from the start. Thank you for the fix. -- 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
Re: Error when Perl calling shell scipt using Cygwin >>> c:\cygwin\bin\sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487
2011/7/15 Gaurav Chhabra: > Sorry, i forgot mentioning that i have attached the log files > (perlrebase and main error that i am getting) for reference in my > last post. The perlrebase log looks good, but the other log indicates that you need to do a rebaseall. -- Reini -- 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
Random Crashes
For some time now, I've been getting random crashes from different applications. Mostly, gvim, but zsh sometimes crashes too. In fact, I've got a zsh script that if I add a blank line in a particular place, it triggers a crash. For zsh, it seems to happen fairly deterministically; if it's crashing, it keeps crashing. If I add an empty line in the right spot, it works and keeps working. For gvim, it seems to happen randomly; often times even if gvim starts successfully, it fails I assume after forking but before exec. I've pasted the error printed when it fails below. 0 [main] gvim 3008 exception::handle: Exception: STATUS_ACCESS_VIOLATION *** starting debugger for pid 3008, tid 6748 Coredumps for both zsh and gvim can be found at http://files.eatnumber1.com/zsh.exe.core http://files.eatnumber1.com/gvim.exe.core These coredumps however weren't helpful to me. I've pasted my interaction with gdb below so you can see why. $ gdb -q -core gvim.exe.core [New process 1] [New process 0] [New process 0] #0 0x777efb8a in ?? () (gdb) bt #0 0x777efb8a in ?? () (gdb) quit Any thoughts on how I can debug this problem? -- Russell Harmon -- 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
Re: Random Crashes
On Tue, 19 Jul 2011, Russell Harmon wrote: Greetings, Russell, For some time now, I've been getting random crashes from different applications. Mostly, gvim, but zsh sometimes crashes too. In fact, I've got a zsh script that if I add a blank line in a particular place, it triggers a crash. Have you tried using bash for your initial shell instead of zsh? Under this scenario, does gvim still crash? For zsh, it seems to happen fairly deterministically; if it's crashing, it keeps crashing. If I add an empty line in the right spot, it works and keeps working. Hmm...that sounds suspiciously line-termination related. For gvim, it seems to happen randomly; often times even if gvim starts successfully, it fails I assume after forking but before exec. I've pasted the error printed when it fails below. 0 [main] gvim 3008 exception::handle: Exception: STATUS_ACCESS_VIOLATION *** starting debugger for pid 3008, tid 6748 Coredumps for both zsh and gvim can be found at http://files.eatnumber1.com/zsh.exe.core http://files.eatnumber1.com/gvim.exe.core These coredumps however weren't helpful to me. I've pasted my interaction with gdb below so you can see why. $ gdb -q -core gvim.exe.core [New process 1] [New process 0] [New process 0] #0 0x777efb8a in ?? () (gdb) bt #0 0x777efb8a in ?? () (gdb) quit Any thoughts on how I can debug this problem? Switch shells to bash and see if the gvim failure still occurs. If not, then it's likely zsh internals related. As with most problems, please collect the information as per: http://cygwin.com/problems.html But, before that, are you on a fairly recent version of all (or most) packages? -- Russell Harmon -- Peter A. Castro or "Cats are just autistic Dogs" -- Dr. Tony Attwood -- 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
