Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: Bash 3.0-2 and kill
Date: Fri, 1 Jul 2005 21:08:52 +0000 (UTC)
Lines: 32
Message-ID:  <loom.20050701T230053-874@post.gmane.org>
References:  <Pine DOT OSF DOT 4 DOT 21 DOT 0506242313310 DOT 4860-100000 AT ax0rm1 DOT roma1 DOT infn DOT it> <42BFF786 DOT 40306 AT byu DOT net>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes

Eric Blake <ebb9 <at> byu.net> writes:
> 
> I have gotten to the point where I am seeing reproducible crashes in a
> plain debugging version of bash inside gdb, but that the problem appears
> to be malloc'd memory corruption (I hate those bugs - they are so hard to
> pinpoint).  I now have to attempt to build a malloc-debugging version of
> bash, and see where bash is corrupting the heap.

Well don't I feel stupid.  I finally found it - I was freeing an uninitialized 
stack variable in jobs.c::j_strsignal, in my attempt to clean up the compiler 
warning about the implicit cast from const char* to char* on the return value 
of strsignal.  Heap corruption was occuring every time bash tried to print the 
status of a job terminated by signal.  Look for bash-3.0-3 to come out RSN 
(along with coreutils-5.3.0-7, where I have solved the recent mv and ls 
complaints, and have isolated the code causing the ln complaints but have not 
yet finished that part of my patch).

As to the recent complaints about "bash: fork: Resource temporarily 
unavailable", it is usually caused by low memory in the system such that fork() 
fails, rather than something specific to bash, so I don't know of anything I 
can change in bash to make it appear less often.  It's just that bash forks so 
often and is so central to a user's experience that it is often the first 
process to notice when cygwin has run out of memory for another fork.

--
Life is short - so eat dessert first!

Eric Blake             ebb9 <at> byu.net
cygwin bash maintainer





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