[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Brian Paul <brianp at vmware.com> ---
(In reply to David Lonie from comment #0)
> Created attachment 122975 [details]
> apitrace
> 
> There are some uninitialized variables in current master that are causing
> some of the VTK unit tests to segfault randomly, or just not produce any
> output. I've included as much information as I can think of below.
> 
> Feel free to ping me if more info is needed.
> 
> --------------------------------------------
> Configure options:
> 
>     ./autogen.sh \
>       --enable-debug \
>       --prefix="$prefix" \
>       --disable-dri \
>       --disable-egl \
>       --disable-gles1 \
>       --disable-gles2 \
>       --disable-shared-glapi \
>       --enable-xlib-glx \
>       --enable-gallium-osmesa \
>       --with-gallium-drivers=swrast \
>       --enable-gallium-llvm=yes \
>         LLVM_CONFIG=/usr/bin/llvm-config-3.6 \
>       --enable-llvm-shared-libs \
>       --with-gl-lib-name=MesaGL \
>       --with-osmesa-lib-name=MesaOSMesa
> 
> ---------------------------------------------
> Install with:
> 
> make install-data
> cd src/gallium
> make install-exec
> 
> (Regular 'make install' does this in the install dir for some reason:
> 
> $ ls mesa-master-install/lib/libMesaGL.so* -lh                              
> 
> mesa-master-install/lib/libMesaGL.so -> libMesaGL.so.1.5.0                  
> 
> mesa-master-install/lib/libMesaGL.so.1 -> libMesaGL.so.1.6.0
> mesa-master-install/lib/libMesaGL.so.1.5.0
> mesa-master-install/lib/libMesaGL.so.1.6.0
> 
> which confuses my linker/loader ;) Another bug?)
> 
> ---------------------------------------------
> memcheck the attached apitrace with (obviously change paths as needed):
> 
>     MESA_GL_VERSION_OVERRIDE=4.5 \
>     LD_LIBRARY_PATH=/ssd/src/llvm-3.8.0.install/lib \
>     LD_PRELOAD=/ssd/src/mesa-master-install/lib/libMesaGL.so \
>     valgrind --tool=memcheck \
>         glretrace vtkRenderingOpenGL2CxxTests.4075.trim.trace
> 
> ---------------------------------------------
> Sample valgrind stacks:
> ==32054== Conditional jump or move depends on uninitialised value(s)
> ==32054==    at 0x5367CF7: util_framebuffer_state_equal (u_framebuffer.c:58)
> ==32054==    by 0x5444AFE: llvmpipe_set_framebuffer_state
> (lp_state_surface.c:54)
> ==32054==    by 0x53561DA: util_blitter_blit_generic (u_blitter.c:1694)
> ==32054==    by 0x5356819: util_blitter_blit (u_blitter.c:1813)
> ==32054==    by 0x544602C: lp_blit (lp_surface.c:117)
> ==32054==    by 0x51705F7: st_CopyTexSubImage (st_cb_texture.c:2672)
> ==32054==    by 0x50B2B03: copytexsubimage_by_slice (teximage.c:3459)
> ==32054==    by 0x50B330D: copyteximage (teximage.c:3644)
> ==32054==    by 0x50B3476: _mesa_CopyTexImage2D (teximage.c:3680)
> ==32054==    by 0x4D340E: ??? (in /usr/bin/glretrace)
> ==32054==    by 0x40CCCC: ??? (in /usr/bin/glretrace)
> ==32054==    by 0x40D2A7: ??? (in /usr/bin/glretrace)

This one looks easy to fix.  Though, I wasn't able to reproduce the valgrind
warning here with piglit's copytexsubimage test which definitely hits the same
code path.


> ==32054== Conditional jump or move depends on uninitialised value(s)
> ==32054==    at 0x5409DEE: lp_build_blend_factor_unswizzled
> (lp_bld_blend_aos.c:98)
> ==32054==    by 0x540A2A5: lp_build_blend_factor (lp_bld_blend_aos.c:262)
> ==32054==    by 0x540A53C: lp_build_blend_aos (lp_bld_blend_aos.c:352)
> ==32054==    by 0x543C200: generate_unswizzled_blend (lp_state_fs.c:2094)
> ==32054==    by 0x543D32D: generate_fragment (lp_state_fs.c:2434)
> ==32054==    by 0x543DEAC: generate_variant (lp_state_fs.c:2619)
> ==32054==    by 0x543F464: llvmpipe_update_fs (lp_state_fs.c:3171)
> ==32054==    by 0x5435D35: llvmpipe_update_derived (lp_state_derived.c:209)
> ==32054==    by 0x5410AC0: llvmpipe_draw_vbo (lp_draw_arrays.c:70)
> ==32054==    by 0x52E28C4: cso_draw_vbo (cso_context.c:1629)
> ==32054==    by 0x5174712: st_draw_vbo (st_draw.c:251)
> ==32054==    by 0x511BE24: vbo_validated_drawrangeelements
> (vbo_exec_array.c:844)

I don't see what's wrong here.  At lp_bld_blend_aos.c:98 we're examining fields
of the bld object.  But the whole bld object is initialized to zeros at line
321.


> 
> ==32054== Conditional jump or move depends on uninitialised value(s)
> ==32054==    at 0x404002D: ???
> ==32054==    by 0x5415736: lp_rast_shade_quads_mask (lp_rast.c:457)
> ==32054==    by 0x541999F: lp_rast_triangle_32_3_16 (lp_rast_tri.c:346)
> ==32054==    by 0x5415A81: do_rasterize_bin (lp_rast.c:609)
> ==32054==    by 0x5415AEF: rasterize_bin (lp_rast.c:628)
> ==32054==    by 0x5415BFE: rasterize_scene (lp_rast.c:688)
> ==32054==    by 0x5415EE3: thread_function (lp_rast.c:828)
> ==32054==    by 0x5413C4A: impl_thrd_routine (threads_posix.h:87)
> ==32054==    by 0x5BF6423: start_thread (in /usr/lib/libpthread-2.23.so)
> ==32054==    by 0x720CCBC: clone (in /usr/lib/libc-2.23.so)

Not sure about this one.  I suspect our jitted code does some vector ops on
some unused elements and that triggers the valgrind warning, but that should be
harmless.  Roland??

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160415/285ee5f8/attachment-0001.html>