Created attachment 41468 [details] Typescript protocolling details of the system/crash spotted originally on Debian box while testing pyglet. Rebuilt from git: snb-magic-851-gb7a73c7 -- the same top backtrace (more information is included in the attached typescript log of the session) #0 0x00007ffff3af70c6 in run_vp (ctx=0x1116450, stage=<value optimized out>) at tnl/t_vb_program.c:377^M #1 0x00007ffff3af423a in _tnl_run_pipeline (ctx=0x1116450) at tnl/t_pipeline.c:153^M #2 0x00007ffff3af503d in _tnl_draw_prims (ctx=<value optimized out>, arrays=<value optimized out>, prim=<value optimized out>, nr_prims=<value optimized out>, ib=0x3f800000, min_index=<value optimized out>, max_index=0)^M at tnl/t_draw.c:478^M #3 0x00007ffff3af53d6 in _tnl_vbo_draw_prims (ctx=0x1116450, arrays=0x7fffffffa730, prim=0x7fffffffab90, nr_prims=1, ib=0x7fffffffa830, index_bounds_valid=<value optimized out>, min_index=0, max_index=0)^M at tnl/t_draw.c:384^M #4 0x00007ffff3aec248 in vbo_rebase_prims (ctx=0x1116450, arrays=0x1160a40, prim=0x7fffffffab90, nr_prims=17917008, ib=0x7fffffffa830, min_index=4294967295, max_index=<value optimized out>, ^M draw=0x7ffff3af5370 <_tnl_vbo_draw_prims>) at vbo/vbo_rebase.c:234^M to reproduce: hg clone https://pyglet.googlecode.com/hg/ pyglet cd pyglet PYTHONPATH=$PWD tests/test.py This will run unittests against current tip of pyglet development, so it would be different from what reported above (version 1.1.4) but failure seems to occur there as well Please let me know if I could more more helpful
Please use INTEL_DEBUG=fall to figure out why there was a software fallback happening -- we don't really have anything testing software fallbacks much, because nobody should be hitting them.
Oh, we'll also want the info on your system from http://intellinuxgraphics.org/how_to_report_bug.html
% INTEL_DEBUG=fall LIBGL_DRIVERS_PATH=/home/yoh/deb/debug/libgl1-mesa-dri/mesa/lib tests/test.py Running Test: top.IMPORT Running Test: graphics.GRAPHICS_ALLOCATION Running Test: graphics.IMMEDIATE FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode Running Test: graphics.IMMEDIATE_INDEXED FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode Running Test: graphics.RETAINED FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode FALLBACK: render mode Running Test: graphics.RETAINED_INDEXED FALLBACK: render mode zsh: segmentation fault INTEL_DEBUG=fall LIBGL_DRIVERS_PATH= tests/test.py I am attaching another typescript with dmesg/lspci etc outputs. From original Debian report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608073 versions of externals: -- System Information: Debian Release: squeeze/sid APT prefers experimental APT policy: (990, 'experimental'), (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgl1-mesa-dri depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libdrm-intel1 2.4.22-2 Userspace interface to intel-speci ii libdrm-radeon1 2.4.21-1~squeeze3 Userspace interface to radeon-spec ii libdrm2 2.4.21-1~squeeze3 Userspace interface to kernel DRM ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libtalloc2 2.0.1-1 hierarchical pool based memory all libgl1-mesa-dri recommends no packages. Versions of packages libgl1-mesa-dri suggests: ii libglide3 2002.04.10ds1-5 graphics library for 3Dfx Voodoo b
Created attachment 41480 [details] protocol of running with INTEL_DEBUG=fall + lspci + dmesg + Xorg.log
Clearing NEEDINFO.
Wow, it's trying to use non-GL_RENDER mode? Really? I'm not surprised that would be a pile of failure.
Reproduced the failure.
Scratch that, now I can't reproduce it any more.
Still reproducible?
(In reply to comment #9) > Still reproducible? Seems to work fine on Sandy Bridge at least, I don't see any crashes.
Dear Reporter, This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested. Thank you.
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.