[Bug 82683] Segfault in glBufferSubData

[bugzilla-daemon at freedesktop.org]

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

--- Comment #6 from Kenneth Graunke <kenneth at whitecape.org> ---
There's no need to delete the code you highlighted.  It's simply failing to
check whether the mapping succeeded, which is a ~2 line fix, which I've posted
to the mailing list for review:

http://lists.freedesktop.org/archives/mesa-dev/2014-September/067665.html

That said, this is a dangerous game to play - there are a variety of other
places where we rely on the ability to map buffers for writing (including GPU
command submission).  If you keep looking, you're likely to find more similar
breakage, and not all of them are as easy to fix.

Frankly, I'm a bit loathe to fix these, as it adds overhead (even if not much)
to well behaved applications, to try and provide a better error report to
applications which are clearly broken.  Most applications don't even try to
handle GL_OUT_OF_MEMORY, because in order to notice, they'd have to call
glGetError() after virtually every API call...which is a widely known way to
make your application horribly slow.  Without doing that, you don't know what
API calls actually failed, so how can you recover from it?  And even if you
know exactly what failed...you still have to be able to stop what you're doing,
delete a bunch of things, and recover sensibly...which is a pretty heroic task.

On top of that, the most likely reason the application ran out of memory in the
first place is due to a resource leak like this.  If an application can't
properly delete buffers under normal circumstances, I have a hard time
believing that it properly cleans them up in error handling code triggered when
it receives GL_OUT_OF_MEMORY at a random point in time.

I haven't seen a single non-trivial application get this right.  Even if we
properly report errors, they either fail to notice, or crash when trying to
handle it.  At which point, I wonder why we bother...

-- 
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/fad8c9a1/attachment-0001.html>