glsl: Avoid ralloc_stealing a long-lived object to a short-lived parent
authorCarl Worth <cworth@cworth.org>
Thu, 2 Feb 2012 19:29:51 +0000 (11:29 -0800)
committerCarl Worth <cworth@cworth.org>
Thu, 2 Feb 2012 20:05:21 +0000 (12:05 -0800)
commitcd2e2187cb45accb13bf89ef297324332c46f379
treee5df2274552afc5bf6a277149b746a0b51275132
parent64fd26a8a812f66f1291d897df7953b8ac9e2f1b
glsl: Avoid ralloc_stealing a long-lived object to a short-lived parent

In commit 6ecee54a9aecc120cb68b02f7e14dcac86b9eca2 a call to
talloc_reference was replaced with a call to talloc_steal. This was in
preparation for moving to ralloc which doesn't support reference
counting.

The justification for talloc_steal within token_list_append in that
commit is that the tokens are being copied already. But the copies are
shallow, so this does not work.

Fortunately, the lifetime of these tokens is easy to understand. A
token list for "replacements" is created and stored in a hash table
when a function-like macro is defined. This list will live until the
macro is #undefed (if ever).

Meanwhile, a shallow copy of the list is created when the macro is
used and the list expanded. This copy is short-lived, so is unsuitable
as a new parent.

So we can just let the original, longer-lived owner continue to own
the underlying objects and things will work.

This fixes bug #45082:

"ralloc.c:78: get_header: Assertion `info->canary == 0x5A1106'
failed." when using a macro in GLSL
https://bugs.freedesktop.org/show_bug.cgi?id=45082

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable release branches.
src/glsl/glcpp/glcpp-parse.y