bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory leak changing IGNORECASE (gawk 3.1.1)


From: Aharon Robbins
Subject: Re: memory leak changing IGNORECASE (gawk 3.1.1)
Date: Mon, 14 Oct 2002 11:22:08 +0200

Ian,

Greetings!  Re this:

> From: "Ian Duplisse" <address@hidden>
> To: "Aharon Robbins" <address@hidden>
> Subject: Re: memory leak changing IGNORECASE (gawk 3.1.1)
> Date: Sun, 13 Oct 2002 21:55:34 -0600
>
> Arnold, I have something that is reproducable!  For this test, /tmp/gawk is
> gawk 3.1.1, built on sunos 5.8 using gcc 2.8.1.  If you run it, memory grows
> unbounded.  Here is a ps:
> ian       7511  3.7  6.02932028832 pts/19   S 21:49:17  0:04 [ gawk ]
>
> If you comment out IGNORECASE=0, then it is static:
> ian       6159  0.4  0.4 2104 1616 pts/19   S 21:48:55  0:00 [ gawk ]
>
> Here is the code.  I have removed most of the code, so it doesn't appear to
> do much, but this is the basic engine that represents my problem.
>
> -------cut here-------
> #! /bin/sh
>
> yes () {
>         while /bin/true ; do
>                 echo yes
>         done
> }
>
> yes | /tmp/gawk --re-interval '
> BEGIN {
>         FS="[ \t]+"
>         parse_rules()
> }
> {
>         for (i=0; i<pc; i++) {
>                 fieldok=1
>                 for (f=0; f<fldcnt[i]; f++) {
>                         fnum=fldtest[i,f,"num"]
>                         fpatt=fldtest[i,f,"patt"]
>                         fnot=fldtest[i,f,"not"]
>                         #IGNORECASE=fldtest[i,f,"icase"]
>                         fieldok=fnot ? ($fnum !~ fpatt) : ($fnum ~ fpatt)
>                         IGNORECASE=0
>                         if (!fieldok) { break }
>                 }
>         }
> }
>
> func parse_rules() {
>         pc=1
>         fldtest[0,0,"num"]=4
>         fldtest[0,0,"patt"]="ondar"
>         fldtest[0,0,"not"]=0
>         fldtest[0,0,"icase"]=0
>         fldcnt[0]=1
> } ' >/dev/null
> -------cut here-------
>
> Thanks,
> Ian

Much thanks for the bug report.  This allowed me to track it down.

Here is the official patch.  You already have the field.c one in
private mail, but this is cc'ed to the bug list.  It turns out there
were not one but two places contributing to the leak you observed.
I wouldn't have found the second one without having a test case.

I applied these to a clean copy of 3.1.1, and with both in place,
there was no memory growth.

I hope this does the trick for you; let me know if it doesn't.

Thanks,

Arnold
-----------------------------------------------------------------
*** field.c.save        Tue Apr 16 14:57:25 2002
--- field.c     Mon Oct 14 11:15:07 2002
***************
*** 1024,1029 ****
--- 1024,1031 ----
                                sprintf(buf, "[%c]", fs->stptr[0]);
                }
        }
+       if (FS_regexp)          /* don't leak memory */
+               refree(FS_regexp);
        if (buf[0] != '\0') {
                FS_regexp = make_regexp(buf, strlen(buf), IGNORECASE, TRUE);
                parse_field = re_parse_field;
*** re.c.save   Tue Apr 16 14:58:58 2002
--- re.c        Mon Oct 14 11:13:39 2002
***************
*** 221,228 ****
  void
  refree(Regexp *rp)
  {
!       free(rp->pat.buffer);
!       free(rp->pat.fastmap);
        if (rp->regs.start)
                free(rp->regs.start);
        if (rp->regs.end)
--- 221,227 ----
  void
  refree(Regexp *rp)
  {
!       regfree(& rp->pat);
        if (rp->regs.start)
                free(rp->regs.start);
        if (rp->regs.end)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]