On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> >>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
> >>
> >> It's not a leak because the memory can be re-used during the next
> >> command.
>
> > I may be blind, but I don't see any static variables there.
>
> Sorry, I was confusing bison with flex --- there are static variables
> pointing at buffers within a flex scanner.
>
> For bison it looks like defining YYSTACK_ALLOC/YYSTACK_FREE as
> palloc/pfree might be a sane thing to do, but I haven't tested it.
Ok, so parser.y is now fine.
Now I must admit I do the same hack in scanner.l, but because it keeps
static references, there is always call to plproxy_yylex_destroy() in
places that throw exceptions (all of flex/bison/plproxy exceptions
go through single function).
Reason for that is again the fact that I could not wrap my brain around
flex memory handling. And the hacks in src/backend/parser/scan.l are also
somethat mystery to me. When using palloc() I can be sure of the flow,
and if something goes wrong it crashes instead leaking, so it can
be fixed immidately.
But now that I think about it, the scheme fails if palloc() itself
throws exception. It can be fixed by calling following function
on parser entry:
void plproxy_yylex_startup(void)
{
#if FLXVER < 2005031
(YY_CURRENT_BUFFER) = NULL;
#else
(yy_buffer_stack) = NULL;
#endif
plproxy_yylex_destroy();
}
This is pretty hairy, but anything near flex is hairy. Such function
also would drop the requirement that plproxy_yylex_destroy() must always
be called. Then we could keep current simple always-from-scratch allocation
pattern but more robust.
Or we could go back to default malloc usage. I somewhat doubt it will
be much cleaner, it needs lot more faith in sanity of flex which I dont
have.
OTOH, considering that now here the possibility of others reviewing the
result is lot higher than before it can be attempted.
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
