Mail Archives: cygwin/2005/07/01/17:17:13
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/
- Raw text -