On 28 August 2013 05:26, Aras Pranckevicius <a...@unity3d.com> wrote:
> Hi,
>
> Looking at the code, is there a potential memory leak in GLSL parser wrt
> extension statements?
>
> glsl_lexer.ll has:
> <PP>[_a-zA-Z][_a-zA-Z0-9]* {
> yylval->identifier = strdup(yytext);
> return IDENTIFIER;
> }
>
> i.e. calls strdup on the token (there's one other place that calls strdup;
> whereas most regular identifiers use ralloc_strdup for easier memory
> management.
>
>
> glsl_parser.yy has this:
>
> extension_statement:
> EXTENSION any_identifier COLON any_identifier EOL
>
> {
> if (!_mesa_glsl_process_extension($2, & @2, $4, & @4, state)) {
> YYERROR;
> }
> }
> ;
>
>
> which looks like it processes the extension identifiers, but never frees the
> memory.
>
>
>
>
I'm not terribly familiar with how memory management is done in the GLSL
lexer and parser, but I agree this looks suspicious.
I'm also suspicious of the other calls to strdup() in glsl_lexer.ll (in the
KEYWORD_WITH_ALT macro, and the handling of the "layout" keyword. It seems
like all of these should be using ralloc_strdup(). Otherwise, if an
identifier gets lexed but not parsed (which could happen if there's a parse
error), the memory will never be freed.
Anyone more familiar with this code want to comment? (Ken, perhaps?)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
