AddressSanitizer reports stack-buffer-overflow in llvmpipe during glTexImage2D call
Before submitting your bug report:
- Check if a new version of Mesa is available which might have fixed the problem.
- If you can, check if the latest development version (git main) works better.
- Check if your bug has already been reported here.
- For any logs, backtraces, etc - use code blocks, GitLab removes line breaks without this.
- Do not paste long logs directly into the description. Use https://gitlab.freedesktop.org/-/snippets/new, attachments, or a pastebin with a long expiration instead.
- As examples of good bug reports you may review one of these - #2598 (closed), #2615 (closed), #2608 (closed)
Otherwise, please fill the requested information below. And please remove anything that doesn't apply to keep things readable :)
The title should effectively distinguish this bug report from others and be specific to issue you encounter. When writing the title of the bug report, include a short description of the issue, the hardware/driver(s) affected and application(s) affected.
System information
Please post inxi -GSC -xx
output (fenced with triple backticks) OR fill information below manually
imxi -GSC -xx output:
System:
Host: localhost.localdomain Kernel: 5.14.21-150500.30-default arch: x86_64
bits: 64 compiler: gcc v: 7.5.0 Desktop: KDE Plasma v: 5.24.4 tk: Qt
v: 5.15.2 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.5 Alpha
CPU:
Info: triple core model: Intel Core i7-8750H bits: 64 type: MCP
arch: Coffee Lake rev: A cache: L1: 192 KiB L2: 768 KiB L3: 27 MiB
Speed (MHz): avg: 2208 min/max: N/A cores: 1: 2208 2: 2208 3: 2208
bogomips: 13248
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.18.1.0 ports:
active: Virtual-1 empty: Virtual-2, Virtual-3, Virtual-4, Virtual-5,
Virtual-6, Virtual-7, Virtual-8
bus-ID: 00:02.0 chip-ID: 15ad:0405
Display: x11 server: X.Org v: 1.20.3 with: Xwayland v: 21.1.4
compositor: kwin_x11 driver: X: loaded: vmware
unloaded: fbdev,modesetting,vesa gpu: vmwgfx display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x975 s-dpi: 96
Monitor-1: Virtual-1 mapped: Virtual1 res: 1920x975 size: N/A
OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 21.2.4
compat-v: 3.1 direct render: Yes
- OS: (
cat /etc/os-release | grep "NAME"
) openSUSE 15.5 in VirtualBox 6.1.40 on Windows 10 - GPU: (
lspci -nn | grep VGA
orlshw -C display -numeric
) GeForce GTX 1060 - Kernel version: (run
uname -a
) - Mesa version: (
glxinfo -B | grep "OpenGL version string"
) Mesa 21.3.9. Issue also present with package Mesa-dri-21.2.4-150400.68.9.1.x86_64 - Xserver version (if applicable): (
sudo X -version
) 1.20.3 - Desktop manager and compositor: KDE
- GCC version: 11.3.0 for Mesa, 7.5.0 for GoOllie/tuxcap
If applicable
- DXVK version:
- Wine/Proton version:
Describe the issue
Please describe what you are doing, what you expect and what you're seeing instead. How frequent is the issue? Is it a one time occurrence? Does it appear multiple times but randomly? Can you easily reproduce it?
"It doesn't work" usually is not a helpful description of an issue. The more detail about how things are going wrong, the better.
I am hacking on an old game, GoOllie, from Charlie Dog Games. I compiled it with GCC 7.5.0. It runs fine with Is3d set to 1 in GoOllie.ini but crashes with Is3D set to zero and AddressSanitizer reports a stack buffer overflow in swrast_dri.so
. The game opens a window and then crashes. Even with Is3d disabled, it uses OpenGL but probably shouldn't. The source code for the game was really hard to find because the website for the game was down (and still is); I tried searching online for the code several times but was unsuccessful. Eventually, I finally found a Mandriva rpm with the source code and then uploaded the game to GitHub.
The buffer overflow is detected every time I run GoOllie with an AddressSanitizer-instrumented libtuxcap with Is3D set to zero in ~/.GoOllie/GoOllie.ini
. With Is3D set to one, the game works just fine.
I compiled Mesa 21.3.9 with GCC 11.3.0 in VirtualBox and was able to get a more detailed backtrace. I had to change one line in vulkan.h because the Wayland headers are in the wayland/ subdirectory instead of being in /usr/include. I can't compile the latest Mesa because the version of libdrm_intel1 that is in 15.5 repos is too old. it's 2.4.107 but latest Mesa requires 2.4.110.
To compile the game, first compile and install tuxcap (popcap for Linux, not the project that takes pictures of penguins).
Dependencies:
- python310-devel
- libSDL2-devel
- libSDL2_mixer-devel
- libSDL2_image-devel
- libMagick++-devel ImageMagick-devel
- OpenGL
- PNG
Steps to compile tuxcap:
- clone https://github.com/Quipyowert2/tuxcap
- checkout python3 branch
- apply the patch in the "Mesa_swrast_stack_buffer_overflow.md" attachment and the InitD3D.patch
- mkdir build
- cd build
cmake -DSOUND_SYSTEM=SDL -DASAN=1 -DCMAKE_BUILD_TYPE=Debug ..
make -j6
make install
mv /usr/local/lib/libtuxcap* /usr/local/lib64/
Steps to compile GoOllie:
- clone https://github.com/Quipyowert2/GoOllie
- mkdir build
- cd build
- In src/main.cpp, change AppResourceFolder to "../data". This way you don't have to install the game to be able to run it.
cmake -DCMAKE_BUILD_TYPE=Debug ..
make -j6
Finally to run GoOllie:
- cd into the build directory
PYTHONPATH=../src ASAN_OPTIONS=abort_on_error=1 gdb -ex 'set env LD_PRELOAD=/usr/lib64/libasan.so.4' ./GoOllie
- Type r and hit enter.
Regression
Did it used to work? It can greatly help to know when the issue started.
Log files as attachment
- Output of
dmesg
- Backtrace
- Gpu hang details
Backtrace and patch for tuxcap: Mesa_swrast_stack_buffer_overflow.md Apitrace: GoOllie.trace Patch for GoOllie: InitD3D.patch Dmesg output: dmesg.log