summaryrefslogtreecommitdiffstats
path: root/wscript_build.py
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-11-29 20:23:27 +0100
committerwm4 <wm4@nowhere>2019-11-29 20:23:27 +0100
commit053297b1ca15d7e94f746e94ea46c7399a6b097a (patch)
treeaec8fdc52947e737532f2b8f5136b0e30b1393b5 /wscript_build.py
parent1ccb049d3b70e80ee60283b7302297a1fc669090 (diff)
downloadmpv-053297b1ca15d7e94f746e94ea46c7399a6b097a.tar.bz2
mpv-053297b1ca15d7e94f746e94ea46c7399a6b097a.tar.xz
vo_gpu: opengl: do not free "GL" sub-allocations
This function always expects the GL struct pointer to be a talloc allocation. So far so bad. But the terrible thing is that _lots_ of code in mpv didn't quite get this (including the code which introduced the way it is used this way). For example, in context_glx.c you see this: struct priv { GL gl; ... GL is not a talloc allocation, but since it's at the start of a talloc allocation, it works anyway. So far so bad. But the really terrible thing is that mpgl_load_functions2() calls talloc_free_children() on the GL pointer, which means that all of priv's. This would be unintentional and could create dangling pointers. And this happens at the about 1 dozen of callers. I'm amazed it didn't broke yet anywhere. Removing this anti-pattern with making GL "implicitly" a talloc allocation would be too much effort at this point. So just manually free the only allocation that the function attached to GL.
Diffstat (limited to 'wscript_build.py')
0 files changed, 0 insertions, 0 deletions