diff options
author | wm4 <wm4@nowhere> | 2019-11-29 20:23:27 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-11-29 20:23:27 +0100 |
commit | 053297b1ca15d7e94f746e94ea46c7399a6b097a (patch) | |
tree | aec8fdc52947e737532f2b8f5136b0e30b1393b5 /video/out/drm_common.c | |
parent | 1ccb049d3b70e80ee60283b7302297a1fc669090 (diff) | |
download | mpv-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 'video/out/drm_common.c')
0 files changed, 0 insertions, 0 deletions