[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31439: [PATCH] fts: avoid a memory leak edge case
From: |
Pádraig Brady |
Subject: |
bug#31439: [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
fts-dealloc.patch
Description: Text Data