This is the mail archive of the
cygwin@sources.redhat.com
mailing list for the Cygwin project.
patch for ash mem fault
- To: "'cygwin at sourceware dot cygnus dot com'" <cygwin at sourceware dot cygnus dot com>
- Subject: patch for ash mem fault
- From: "Mortimer, Andy" <Andy dot Mortimer at software dot aeat dot com>
- Date: Wed, 27 Sep 2000 10:51:34 -0600
Hi all,
(I'm not sure who to send this to, because I can't quite work
out where ash comes from! Hopefully this is a reasonable
first try ...)
I think I've found and fixed a segfault in ash 20000823 (from
Cygwin). I have a feeling that this has been around since b20
or before -- I definitely saw a similar one there, which I fixed
by changing to bash for this particular script -- but I don't
have that installed any more to confirm that it's the same one.
The problem occurs infrequently, when a large string value
(>504 chars, I think!) is assigned to a variable. In ash-
source-speak, what happens is that the current stack
position is saved via a call to setstackmark, but then before
it is freed again in popstackmark, a call to growstackblock
moves the stack block which has been saved. Then when
the time comes to free it, the free is passed an invalid
pointer, and basically, it all goes horribly wrong. (All these
routines are in memalloc.c)
The attached patch adds a new member to the stack_block
structure which is initially set to zero, but is incremented if
setstackmark is called on a particular stack_block. If this
member is non-zero in growstackblock, even if no data is
actually allocated in that block, it will still go ahead and
create another one and leave the previous one in place.
This is all at the cost of an extra 4 bytes in a stack_block,
but looking at the average length of the block chain for the
sorts of runs I've been doing (about 4 or 5 for most of the
time, I think), I don't expect that this is a problem. Wiser
minds than mine may prevail, however.
I've checked that this fixes the problem I was having;
however, I haven't done much more testing than that single
(admittedly many thousand line) script.
Have fun!
Andy
--
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com
memalloc.diff
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com