RE: patch for ash mem fault

RE: patch for ash mem fault

[Mortimer, Andy]

Hi,

> > 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.
> 
> Would you mind to send an example which allows me to test
> that? I never saw that problem, so...

Unfortunately, I never managed to get it down to a simple reproducible testcase.  I managed to get a reproducible case, but unfortunately (as I mentioned above) that's a major script, and it only
happens for some inputs anyway.  Erm.  If there's somebody around who really knows the ash internals it might be possible for them to cook up an example with a more complete description of the
symptoms, but I'm afraid that doesn't describe me! :-(

All I can think of to say is that the error was occurring in a line:
  PROBLIST=`cat $PROBFILE`
and that, by controlling the size of $PROBFILE (around 504 bytes is the magic number) I could make it either fault or not.  Obviously the above statement works most of the time, though; it's something
to do with ash's internal memory tracking, and I really can't find a way to decompose it.

Sorry, I know it's not very useful!  I'll certainly pass it on if I can come up with a test case.

Regards,

Andy

-- 
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: patch for ash mem fault

[Corinna Vinschen]

"Mortimer, Andy" wrote:
> 
> Hi all,
> 
> 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.

Would you mind to send an example which allows me to test
that? I never saw that problem, so...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                        mailto:cygwin@sources.redhat.com
Red Hat, Inc.
mailto:vinschen@cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

patch for ash mem fault

[Mortimer, Andy]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

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


[-- Attachment #2: memalloc.diff --]
[-- Type: text/x-diff, Size: 1881 bytes --]

*** memalloc.c.orig	Wed Sep 27 17:43:39 2000
--- memalloc.c	Wed Sep 27 17:21:57 2000
***************
*** 106,118 ****
   *
   * The size 504 was chosen because the Ultrix malloc handles that size
   * well.
   */
  
! #define MINSIZE 504		/* minimum size of a block */
  
  
  struct stack_block {
  	struct stack_block *prev;
  	char space[MINSIZE];
  };
  
--- 106,121 ----
   *
   * The size 504 was chosen because the Ultrix malloc handles that size
   * well.
+  *
+  * Reduced to 500 now I've added an extra int -- andy.mortimer@zetnet.co.uk
   */
  
! #define MINSIZE 500		/* minimum size of a block */
  
  
  struct stack_block {
  	struct stack_block *prev;
+ 	int refcnt;
  	char space[MINSIZE];
  };
  
***************
*** 143,148 ****
--- 146,152 ----
  		sp = ckmalloc(sizeof(struct stack_block) - MINSIZE + 
  		    blocksize);
  		sp->prev = stackp;
+ 		sp->refcnt = 0;
  		stacknxt = sp->space;
  		stacknleft = blocksize;
  		stackp = sp;
***************
*** 176,183 ****
  	mark->stackp = stackp;
  	mark->stacknxt = stacknxt;
  	mark->stacknleft = stacknleft;
- }
  
  
  void
  popstackmark(mark)
--- 180,188 ----
  	mark->stackp = stackp;
  	mark->stacknxt = stacknxt;
  	mark->stacknleft = stacknleft;
  
+ 	stackp->refcnt++;
+ }
  
  void
  popstackmark(mark)
***************
*** 186,191 ****
--- 191,197 ----
  	struct stack_block *sp;
  
  	INTOFF;
+ 	mark->stackp->refcnt--;
  	while (stackp != mark->stackp) {
  		sp = stackp;
  		stackp = sp->prev;
***************
*** 220,226 ****
  	oldspace = stacknxt;
  	oldlen = stacknleft;
  
! 	if (stacknxt == stackp->space && stackp != &stackbase) {
  		INTOFF;
  		sp = stackp;
  		stackp = sp->prev;
--- 226,233 ----
  	oldspace = stacknxt;
  	oldlen = stacknleft;
  
! 	if (stacknxt == stackp->space && stackp != &stackbase
! 	    && !stackp->refcnt) {
  		INTOFF;
  		sp = stackp;
  		stackp = sp->prev;