[Mesa-dev] [PATCH] svga: Check vs and fs pointer when updating states.

Vic Lee llyzs.vic at gmail.com
Thu Mar 8 07:16:04 PST 2012


Hi Brian,

Please the the gdb backtrace if I only add vs check. Maybe you have a 
better idea on this issue. I am using the git 8.0 branch.

********************************
vic at debian:~/mesa/src/gallium$ git diff
diff --git a/src/gallium/drivers/svga/svga_state_need_swtnl.c 
b/src/gallium/drivers/svga/svga_state_need_swtnl.c
index 8c39a4b..3b193c0 100644
--- a/src/gallium/drivers/svga/svga_state_need_swtnl.c
+++ b/src/gallium/drivers/svga/svga_state_need_swtnl.c
@@ -136,7 +136,7 @@ update_need_pipeline( struct svga_context *svga,

     /* EDGEFLAGS
      */
-    if (vs->base.info.writes_edgeflag) {
+   if (vs && vs->base.info.writes_edgeflag) {
        SVGA_DBG(DEBUG_SWTNL, "%s: edgeflags\n", __FUNCTION__);
        need_pipeline = TRUE;
     }
vic at debian:~/mesa/src/gallium$ gdb ./test
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/vic/mesa/src/gallium/test...done.
(gdb) r
Starting program: /home/vic/mesa/src/gallium/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00000000004476e0 in update_need_pipeline (svga=0x124eed0, 
dirty=4294967295) at svga_state_need_swtnl.c:148
148	      unsigned generic_inputs = svga->curr.fs->generic_inputs;
(gdb) bt
#0  0x00000000004476e0 in update_need_pipeline (svga=0x124eed0, 
dirty=4294967295) at svga_state_need_swtnl.c:148
#1  0x0000000000446f37 in update_state (svga=0x124eed0, atoms=0x118ab80, 
state=0x12534d8) at svga_state.c:154
#2  0x000000000044715d in svga_update_state (svga=0x124eed0, 
max_level=1) at svga_state.c:209
#3  0x0000000000441fc0 in try_clear (svga=0x124eed0, buffers=1, 
color=0x7fffffffe500, depth=0, stencil=1) at svga_pipe_clear.c:51
#4  0x000000000044221f in svga_clear (pipe=0x124eed0, buffers=1, 
color=0x7fffffffe500, depth=0, stencil=1) at svga_pipe_clear.c:118
#5  0x000000000042dd0e in main (argc=1, argv=0x7fffffffe718) at test.c:97
(gdb)

On 03/08/2012 01:34 AM, Brian Paul wrote:
> On 03/07/2012 10:01 AM, Vic Lee wrote:
>> Hi Brian,
>>
>> On 03/07/2012 11:44 PM, Brian Paul wrote:
>>> On 03/07/2012 01:08 AM, Vic Lee wrote:
>>>> Hi Brian,
>>>>
>>>> I created a smallest possible test case to reproduce the segfault, as
>>>> attached.
>>>
>>> OK, I was assuming that you found this with an OpenGL program, not with
>>> a custom direct-to-gallium program.
>> Right, we are experimenting our custom application on VMware platform
>> which communicates to the driver directly through gallium interface.
>>
>>>> Please see file header on how I compile it. vs and fs both
>>>> needs to be checked to avoid the segfault.
>>>
>>> Hmmm, I only needed to add the null vs check to prevent the segfault.
>>> Are you sure about the fs check? We only use svga->curr.fs when
>>> assigning to the generic_inputs var and we check for a null pointer
>>> there.
>> Yes, I tried the test case I sent. Without the fs check it will still
>> segfaults.
>
> Where exactly is the segfault? I'd like to fully understand this before
> making the change.
>
> -Brian



More information about the mesa-dev mailing list