summaryrefslogtreecommitdiffstats
path: root/acinclude.m4
diff options
context:
space:
mode:
authorCarl Worth <[email protected]>2012-02-02 11:29:51 -0800
committerCarl Worth <[email protected]>2012-02-02 12:05:21 -0800
commitcd2e2187cb45accb13bf89ef297324332c46f379 (patch)
treee5df2274552afc5bf6a277149b746a0b51275132 /acinclude.m4
parent64fd26a8a812f66f1291d897df7953b8ac9e2f1b (diff)
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 <[email protected]> NOTE: This is a candidate for stable release branches.
Diffstat (limited to 'acinclude.m4')
0 files changed, 0 insertions, 0 deletions