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
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. |