| Summary: | memcheck doesn't work with Mesa OpenGL/ATI on Suse 9.1 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Tom Teixeira <tjt> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 2.1.2 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Tom Teixeira
2004-08-05 17:35:10 UTC
This looks like a bug in the OpenGL DRI module rather than a bug in valgrind to me - what makes you think it is a bug in valgrind? Because glxgears runs without a segmentation fault run without valgrind. But I'm able to use valgrind on programs which don't use opengl. That doesn't actually prove anything - the environment under valgrind is radically different, so an uninitialised read that you might "get away with" normally may well cause a segmentation fault under valgrind. The fact is that valgrind is reporting uninitialised memory reads, followed by a segmentation fault at the same address. That looks pretty clear to me - valgrind has done it's job and found an error in the client program. It's just possible that there's something about that ioctl that is confusing valgrind - the ioctl has been handled by the generic code so if it has wierd side effects then that might lead to problems later. I thought the environment wasn't supposed to be radically different -- I have no problem with it reporting an uninitialized read, thereby uncovering a latent bug, but by altering the program flow at that point, it's hiding more interesting bugs. I'll admit that "more interesting" means somewhere in my code as opposed to latent bugs in library code. It isn't a question of altering program flow - it's a question of what data you happen to get when you read from an uninitialised location. Among other differences valgrind has a different malloc which can easily change what data an uninitialised location contains, especially since the valgrind malloc tries to delay reusing memory in order to give better reports. One other thing that just occurred to me (given that this is in a SIGFPE handler) is that it might be trying to look at the FP state in the signal context, which valgrind doesn't fill in at the moment. Do you know where to get the source for that DRI module? I'll go hunting around to see if I can find the exact source SuSE uses. The DRI source is otherwise at http://dri.sourceforge.net, but doesn't seem to identify any releases: just access to the CVS tree. I think the code that causes the FPE is part of the Mesa source (http://www.mesa3d.org), and is related to exception handling for SSE. FWIW, if I run glxgears under GDB, the backtrace is shown below. tjt@linux:~> gdb `which glxgears` GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /usr/X11R6/bin/glxgears (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread 1076954912 (LWP 16702)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1076954912 (LWP 16702)] 0x4044c8c4 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) bt #0 0x4044c8c4 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x4044c725 in _mesa_init_all_x86_transform_asm () from /usr/X11R6/lib/modules/dri/r200_dri.so #2 0x403c95cb in _math_init () from /usr/X11R6/lib/modules/dri/r200_dri.so #3 0x4034aada in _mesa_initialize_context () from /usr/X11R6/lib/modules/dri/r200_dri.so #4 0x4034b9f7 in _mesa_create_context () from /usr/X11R6/lib/modules/dri/r200_dri.so #5 0x40452556 in r200CreateContext () from /usr/X11R6/lib/modules/dri/r200_dri.so #6 0x40336044 in driCreateContext () from /usr/X11R6/lib/modules/dri/r200_dri.so #7 0x40091204 in CreateContext () from /usr/lib/libGL.so.1 #8 0x40091732 in glXCreateContext () from /usr/lib/libGL.so.1 #9 0x08049f6c in main () (gdb) |