Bug 22540 - VBO is still mapped after drawing, therefore glMapBuffer fails
VBO is still mapped after drawing, therefore glMapBuffer fails
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915
git
Other All
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-29 12:32 UTC by David Henry
Modified: 2009-08-24 12:32 UTC (History)
0 users

See Also:


Attachments
Test case : if it segfault, then it failed! (5.64 KB, text/plain)
2009-06-29 12:32 UTC, David Henry
Details
Xorg.0.log (55.00 KB, text/plain)
2009-06-29 13:01 UTC, David Henry
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Henry 2009-06-29 12:32:44 UTC
Created attachment 27231 [details]
Test case : if it segfault, then it failed!

After having mapped a VBO once with glMapBuffer for data initialization and drawn it, the buffer seems not to be unmapped as expected. This cause the next call to glMapBuffer to always return NULL.

The attached program show a test case. It should draw a rotating cube. After the first frame is drawn, it segfaults.

Expected output:

[...]
Before copying data, buffer is not mapped
Mapping frame 18
Before drawing, buffer is not mapped
After drawing, buffer is not mapped
Frame 18 finished...
----------
Before copying data, buffer is not mapped
Mapping frame 19
Before drawing, buffer is not mapped
After drawing, buffer is not mapped
Frame 19 finished...
----------
Before copying data, buffer is not mapped
Mapping frame 20
Before drawing, buffer is not mapped
After drawing, buffer is not mapped
Frame 20 finished...
[...]

Current output:

Before copying data, buffer is not mapped
Mapping frame 1
Before drawing, buffer is not mapped
After drawing, buffer is mapped
Frame 1 finished...
----------
Before copying data, buffer is mapped
Mapping frame 2
Segmentation Fault

NOTES:

* it works in software mode (LIBGL_ALWAYS_SOFTWARE=1),
* it works with Mesa 7.3 in Ubuntu Jaunty (9.04),
* it works with NVIDIA 177.82 and 180.44 proprietary drivers,
* it fails for me with mesa 7.5 up to date from git, but it has been reported to me that it fails with mesa 7.6 (up do date from git) too.
Comment 1 David Henry 2009-06-29 13:00:30 UTC
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090114 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.5-rc4
Comment 2 David Henry 2009-06-29 13:01:23 UTC
Created attachment 27232 [details]
Xorg.0.log
Comment 3 Robert Hooker (Sarvatt) 2009-06-30 16:00:20 UTC
(In reply to comment #0)
> * it fails for me with mesa 7.5 up to date from git, but it has been reported
> to me that it fails with mesa 7.6 (up do date from git) too.
> 

I was the one he mentioned that was having it fail in 7.6, and the problem was fixed by some commit in master between:

57a06d3a48c9af1067ec05e3ad96c58f4b9b99be (works as intended)
and
1f070125e365dadf97797785fdeef1ccb1431f21 (failed)
Comment 4 Eric Anholt 2009-06-30 16:21:49 UTC
Yeah, should be covered by:

commit 57a06d3a48c9af1067ec05e3ad96c58f4b9b99be
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Jun 29 18:48:27 2009 -0700

    i915: Fix assertion failure on remapping a non-BO-backed VBO.
    
    Failure to set the obj->Pointer back to null tripped up the assertion.
    Bug #22428.
Comment 5 David Henry 2009-06-30 21:55:30 UTC
Yes, it works now. Thank you.
Comment 6 ajax at nwnk dot net 2009-08-24 12:32:41 UTC
Mass version move, cvs -> git