Re: [PATCH] Make gram.y use palloc/pfree for memory management

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Make gram.y use palloc/pfree for memory management
Date: 2008-09-01 13:33:53
Message-ID: e51f66da0809010633q5d0f999br72fe9dedf3b47760@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

First a correction, overriding malloc/free seems dangerous they
seems to leak out, so correct would be to use YYMALLOC/YYFREE.
This leaves 1.875 potentially leaking, but danger seems small.

On 9/1/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > This means gram.y can leak memory if error is throws in
> > the middle of parsing.
>
> Please offer some evidence for that claim.

The leak occurs when
1. bison does allocation.
2. error is thrown.

Now, normally bison does not do allocation as it has initially 200-item
stack allocated in stack. When this is full it does allocate.

But I'm not familial enough with bison internals and Postgres parser
structure, on how cause the stack fill up. It may be that Postgres
parser avoids recursive stack allocations, thus in practice the
leak cannot occur.

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Kreen 2008-09-01 13:37:58 Re: [PATCH] Cleanup of GUC units code
Previous Message Alvaro Herrera 2008-09-01 13:26:52 Re: libpq does not manage SSL callbacks properly when other libraries are involved.