diff options
author | Carl Worth <[email protected]> | 2012-02-02 11:29:51 -0800 |
---|---|---|
committer | Carl Worth <[email protected]> | 2012-02-02 12:05:21 -0800 |
commit | cd2e2187cb45accb13bf89ef297324332c46f379 (patch) | |
tree | e5df2274552afc5bf6a277149b746a0b51275132 /acinclude.m4 | |
parent | 64fd26a8a812f66f1291d897df7953b8ac9e2f1b (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