[Bug 82683] Segfault in glBufferSubData

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82683

--- Comment #4 from Ben Foppa <benjamin.foppa at gmail.com> ---
The intent *was* to allocate many buffers simultaneously without freeing. While
this certainly isn't a good use of VBOs, it does demonstrate some underlying
incorrectness in the code. This behavior should NOT happen, and doesn't happen
if I switch graphics drivers.

This is almost certainly not an OOM issue. I can cut the number of buffers in
half and vastly increase the capacity of each without getting a segfault. It
also starts slowing down once the memory consumption goes past a certain point
(which is expected, since it starts to just use my RAM).

I'm specifically checking for OpenGL errors, including OOM. The error check
code in my sample is wrong, but it's irrelevant anyway because no OpenGL errors
are generated. Moreover, one would expect an out-of-memory error to occur when
the buffer is actually allocated, and if not then, then certainly when it is
read! The segfault only occurs once we're in glBufferSubData.

Like I said, the "patch" I uploaded fixes this issue - the patch only removes a
block of code that, based on the comment surrounding it, I assume is only there
for performance purposes, not correctness. But apparently, it reduces
correctness, because it's causing very ungraceful errors.

Again, the use case isn't good, but it's demonstrative of underlying issues and
false programmer assumptions, and I believe it to be important because I've had
other SIGSEGVs and SIGBUSs show up in glBufferSubData for no real reason. I'm
very inclined to suspect the same tricky optimization block, but that's just my
bias.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140912/bf066057/attachment.html>