emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#31439: closed (Possible memory leak in fts.c)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#31439: closed (Possible memory leak in fts.c)
Date: Mon, 14 May 2018 01:52:01 +0000

Your message dated Sun, 13 May 2018 18:51:02 -0700
with message-id <address@hidden>
and subject line [PATCH] fts: avoid a memory leak edge case
has caused the debbugs.gnu.org bug report #31439,
regarding Possible memory leak in fts.c
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
31439: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31439
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Possible memory leak in fts.c Date: Sun, 13 May 2018 02:50:34 +0100
Hi,

I may be wrong but I suspect there is a corner case where fts_close()
will not free the FTSENT structures correctly if called immediately
after fts_open().

After fts_open(), the current entry is a dummy entry created as
follows:

if ((sp->fts_cur = fts_alloc(sp, "", 0)) == NULL)
        goto mem3;
sp->fts_cur->fts_link = root;
sp->fts_cur->fts_info = FTS_INIT;

It would normally be freed during the first invocation of fts_read().

In fts_close():

if (sp->fts_cur) {
        for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) {
                freep = p;
                p = p->fts_link != NULL ? p->fts_link : p->fts_parent;
                free(freep);
        }
        free(p);
}

However, fts_alloc() does not clear or set fts_level, nor does it zero
the entire FTSENT structure.

So as far as I can figure, it is possible for the fts_level of the
dummy entry to be negative after fts_open() causing fts_close() not to
free the actual root level entries.

-- isedev



--- End Message ---
--- Begin Message --- Subject: [PATCH] fts: avoid a memory leak edge case Date: Sun, 13 May 2018 18:51:02 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 12/05/18 18:50, ISE Development wrote:
> Hi,
> 
> I may be wrong but I suspect there is a corner case where fts_close()
> will not free the FTSENT structures correctly if called immediately
> after fts_open().
> 
> After fts_open(), the current entry is a dummy entry created as
> follows:
> 
> if ((sp->fts_cur = fts_alloc(sp, "", 0)) == NULL)
>         goto mem3;
> sp->fts_cur->fts_link = root;
> sp->fts_cur->fts_info = FTS_INIT;
> 
> It would normally be freed during the first invocation of fts_read().
> 
> In fts_close():
> 
> if (sp->fts_cur) {
>         for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) {
>                 freep = p;
>                 p = p->fts_link != NULL ? p->fts_link : p->fts_parent;
>                 free(freep);
>         }
>         free(p);
> }
> 
> However, fts_alloc() does not clear or set fts_level, nor does it zero
> the entire FTSENT structure.
> 
> So as far as I can figure, it is possible for the fts_level of the
> dummy entry to be negative after fts_open() causing fts_close() not to
> free the actual root level entries.

Yes valgrind indicates that fts_level is uninitialized if you
fts_close() right after fts_open().
The attached should fix it up.

thanks!
Pádraig

Attachment: fts-dealloc.patch
Description: Text Data


--- End Message ---

reply via email to

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