Bug 99631 - segfault with OSVRTrackerView and openscenegraph git master
Summary: segfault with OSVRTrackerView and openscenegraph git master
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-01 19:57 UTC by Christoph Haag
Modified: 2017-02-03 01:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
trace that segfaults (57.23 KB, application/octet-stream)
2017-02-01 19:57 UTC, Christoph Haag
Details

Description Christoph Haag 2017-02-01 19:57:34 UTC
Created attachment 129276 [details]
trace that segfaults

It's a very small demo application: https://github.com/OSVR/OSVR-Tracker-Viewer

If you want to reproduce it for debugging, you don't need any OSVR hardware, just openscenegraph from git (currently 2a7d72c203104275462a5c0871257383ffbcf6a5) and then starting OSVRTrackerView.

What works:

OSVRTrackerView with openscenegraph 3.4
osgviewer that comes with openscenegraph git master

OSVRTrackerView with openscenegraph git master however segfaults immediately:

0xb5652bf4 in _save_Vertex3fv (v=0x0) at vbo/vbo_attrib_tmp.h:275
275        ATTR3FV(VBO_ATTRIB_POS, v);
(gdb) bt full
#0  0xb5652bf4 in _save_Vertex3fv (v=0x0) at vbo/vbo_attrib_tmp.h:275
        dest = 0x930cc
        save = 0x92490
        ctx = 0x95b08
#1  0xb53fc8a0 in _ae_ArrayElement (elt=0) at main/api_arrayelt.c:1796
        src = 0x0
        ctx = 0x95b08
        actx = 0x93e50
        aa = 0x93e50
        at = 0x93fd0
        disp = 0x8c070
        do_map = 0 '\000'
#2  0xb566edf8 in _save_OBE_DrawArrays (mode=1, start=0, count=16) at vbo/vbo_save_api.c:1168
        ctx = 0x95b08
        save = 0x92490
        i = 0
#3  0xb6352c50 in glDrawArrays (mode=1, first=0, count=16) at glapi/glapi_mapi_tmp.h:3847
        _tbl = 0x8c070
        _func = 0xb566ece8 <_save_OBE_DrawArrays>

trace attached.
Comment 1 Ilia Mirkin 2017-02-01 20:44:22 UTC
The issue appears that the right buffer object isn't mapped. The fact that the ARRAY_BUFFER is modified doesn't appear to make it into the actx->NewState bit. The following "fixes" the trace:

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 46175e4..fa78edb 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1707,7 +1707,7 @@ _ae_map_vbos(struct gl_context *ctx)
    if (actx->mapped_vbos)
       return;
 
-   if (actx->NewState)
+   if (actx->NewState || 1)
       _ae_update_state(ctx);
 
    for (i = 0; i < actx->nr_vbos; i++)

Now just need to figure out where NewState is not being updated when it should be.
Comment 2 Brian Paul 2017-02-01 21:06:45 UTC
Thanks for looking into this, Ilia.  If you get stuck, I'll try to look at it in a few days.

BTW, we should probably create a piglit test for this issue.
Comment 3 Ilia Mirkin 2017-02-01 21:14:44 UTC
Candidate patch sent as https://patchwork.freedesktop.org/patch/136383/

Not sure if it's too heavy.
Comment 4 Ilia Mirkin 2017-02-03 01:33:09 UTC
Patch pushed as:

commit e73f87fcbdcb12b0b8d28c4ca3444bfb7669bca5
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Feb 1 16:11:41 2017 -0500

    vbo: process buffer binding state changes on draw when recording
    
    The VBO module keeps track of any vbo buffers. It updates this list when
    receiving an InvalidateState call, however this never happens when
    recording draws right now. Make sure that we do all the usual state
    updates when recording draws so that the VBO list may be kept up to
    date.
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99631
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org>


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.