MapBufferRange/GL Feature Detection
While compiling GStreamer on the Raspbery Pi 4 Bulleye x64, the gst-plugins-base / libs_gstglmemory
test failed with a segfault. Debugging showed that the offending line of code is gstglbuffer.c:195:
mem->mem.data = gl->MapBufferRange (mem->target, 0, size, gl_map_flags);
since gl->MapBufferRange
is null
.
Interestingly, gstglbuffer.c
is the only file that uses this function, three times in total. And the other two times, the call is protected by a query that checks whether the function actually exists, only this one time it does not do so - so this is an inconsistency here.
Then, I also checked why MapBufferRange
is not populated with the proper address, since nm -D /usr/lib/aarch64-linux-gnu/libGLESv2.so
happily lists 0000000000016880 T glMapBufferRange
. Perhaps, being new to all the different GL APIs, I confuse things here. But glMapBufferRange
is part of OpenGL starting from version 3, and since on Raspberry, we only have version 2.1 supported, the feature set gl3
is not available. In fact, this is what happens in _gst_gl_feature_check
: The responsible GstGLFeatureData
looks like
{feature_name = 0x7ff7cab090 "gl3", gl_availability = 65539, min_gl_major = 3, min_gl_minor = 0, min_gles_major = 3, min_gles_minor = 0, namespaces = 0x7ff7cb7c10 "", extension_names = 0x7ff7cb7c10 "", functions = 0x7ff7cd8eb0 <gst_gl_ext_gl3_funcs>}
and then gst_gl_context_check_gl_version
, called with the correctly determined version 2.1
, says that this function is not directly provided by GL; however, as there is no namespace available, it also cannot be attributed to an extension. Therefore, all functions in the whole feature set are skipped, even if some of them were available.
But... glMapBufferRange
is also part of OpenGL ES starting from version 3, and on the Raspberry, we have compliance with version 3; in fact, this is where the function was found. So using this function should be perfectly legal. I decided to give it a try populated the function address anyway. And the offending code went through without issues. Now FlushMappedBufferRange
(line 314 of same file) was not found... To take things to the extreme, I disabled the version checking in gst_gl_context_check_gl_version
and only left the API check to properly select a suffix. And I disabled the sections in _gst_gl_feature_check
that led to all functions of the same feature set being always set to NULL if even a single function did not exist. Probably this is dangerous, if somewhere the presence of a whole feature set is determined by querying only a single function - but perhaps it is also overly restrictive... Anyway: Now the test passes and none of the other tests raises a SEGFAULT, so the fear that some existence tests may have been invalidated was not true at least in all of gstreamer's tests.
So, apart from the specific bug related to (at least) MapBufferRange
and FlushMappedBufferRange
: Is this kind of very conservative existence check really necessary or can't we just be happy about any function that exists and use it?