Bug 14575

Summary: [i915 i965] glDeleteBuffers cause assertion failure when map and unmap not paired
Product: Mesa Reporter: Shuang He <shuang.he>
Component: Drivers/DRI/i915Assignee: Eric Anholt <eric>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: high CC: dri-devel
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: test case

Description Shuang He 2008-02-19 23:12:35 UTC
Created attachment 14435 [details]
test case

System Environment:
--------------------------

--Platform: i915 & i965

--Architecture(32-bit,64-bit,compatiblity): all

--2D driver:
commit 4a42b01f5ee5a673716d6959dfe0e693b037eb48 

--3D driver:
commit 15f0015df443025086ae810c0c0d07b4359b9e02 

--Xserver:
commit 06c968acbf6771d5fed4b12ebd400fea791ea498 


--Kernel:
2.6.24-rc5


Bug detailed description:
-------------------------
glDeleteBuffers cause assertion failure when map and unmap of buffer object not paired
this is not in conformance with OpenGL spec:
     'A buffer object's mapped data store is automatically unmapped when the buffer object is deleted or its data store is recreated with glBufferData.'

seems following commit brings this issue in:

commit c51eb3ec401e78dd14ccd95304599909045b17b6
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Feb 14 16:14:00 2008 -0800

    [intel] Bug #13636: Allow recursive buffer mapping in bufmgr_ttm.



Reproduce steps:
----------------
1. start X
2. compile and run attached test case


Current result:
----------------
glDeleteBuffers cause assertion failure when map and unmap of buffer object not paired


Expected result:
----------------
run normally
Comment 1 Gordon Jin 2008-02-20 21:42:30 UTC
increasing priority to high as it blocks glean test.
Comment 2 Eric Anholt 2008-02-28 15:45:12 UTC
Fix committed, and piglit regression test pushed.
Comment 3 Shuang He 2008-02-28 17:50:32 UTC
verified

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.