[Mesa-dev] glsl: memory leak in parsing extension statements?

[Paul Berry]

On 28 August 2013 05:26, Aras Pranckevicius <aras at 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?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130830/d7624db6/attachment.html>