Version: 2.1.0 (using KDE KDE 3.1.4) Installed from: Unlisted Binary Package Compiler: gcc 3.3.2 (binary from fedora) OS: Linux First of all thank you for providing such a great tool ! You really deserve the OSA award ! Now for the bug report, please first have a look at the first report: http://article.gmane.org/gmane.comp.debugging.valgrind/751 or http://sourceforge.net/mailarchive/forum.php?thread_id=3854537&forum_id=32038 As mentioned I am (so does Leonard mckinley) experiencing X session lock when using valgrind in combination with the official closed source binary libGL.so from ATI (3.7.0) on XFree 4.3.0 I am using valgrind from CVS (because I need instruction 0xF3 0xF 0x52 0xE3). I played a bit with the program and the display + valgrind is fine until I press a key. I understand this is not reproducable on your side unless you have an ATI card. So please direct me on what to do next to try tracking this bug. Thanks Mathieu
Can you be a bit clearer? Is just X freezing, or the whole machine? I presume X isn't running Valgrind, but your client is. Does the ATI libGL.so use DRI, or some other mechanism? I have a suspicion this is actually unfixable. If the machine is totally locking up, then it means that something strange has happened to the driver/hardware. If the ATI libGL.so is actually directly poking at the hardware, then Valgrind's presence may be confusing the hardware and causing it to kill the machine. Valgrind promises that the software should appear to be running unchanged from the software's perspective, but it doesn't promise it looks unchanged to an external entity (ie, hardware, or another process looking at a shared memory segment). In particular, things like locked bus cycles won't be happening (I don't know if this is important or an issue). I don't really know how to go about debugging this. I really can't think why pressing a key would trigger a crash. Does mouse activity cause a problem?
A few more details: - This is a machine lock (not a X lock) - I can't reproduce it using Mesa ( using: export LD_PRELOAD=/opt/Mesa/lib/libGL.so) - Also my remark about the keyborad is pretty dumb. In fact I was pressing 'q' wich mean that everything was cleaning up to close the window. Thus valgrind is doing its real job during this time.
I'm using valgrind 2.1.0 with ATI drivers 3.7 and have no lockups at all. 3.2.8 were a lot worse it that matter. I have Athlon XP on NForce2 based motherboard. My options from /etc/X11/XF86Config: Section "Device" Identifier "My Video Card" Driver "fglrx" Option "VideoOverlay" "1" Option "UseFastTLS" "0" Option "BlockSignalsOnLock" "1" Option "UseInternalAGPGART" "0" Option "ForceGenericCPU" "1" EndSection If you also have Athlon CPU, check if you have the 'Halt Disconnect and Stop Grant Disconnect' bit disabled - when it's enabled system becomes very unstable and locks up every few minutes. Google for athcool utility.
Thanks Bartosz, but I am working on it. I was able to write a small piece of code to reproduce the bug. Which by the way get away if I force ATI libGL to do software rendering. I'll post the offending gl call ASAP. BTW this lead me to think it is a hardware related problem, I am using an ATI Radeon 9800.
What's the state of this? Could you try the current CVS head and see if it makes a difference? BTW, are you positive it's a complete machine lockup and not just a X deadlock? Sometimes things can get screwy if Valgrind is trying to print a message to an xterm (or whatever) while the GL driver has some lock held...
Mathieu, can you comment on this -- is it still a problem? Have you tried more recent versions of Valgrind, or the CVS HEAD? I'm going to close this bug because it is more than a year since the original report, and Mathieu hasn't commented since then. Mathieu, if this is still a problem, please reopen this bug. Thanks.
Nicholas, Sorry I did not had any time to further investigate. I switch to a more recent machine with an nvidia card and I am using debian testing with official valgrind (instead of my previous fedora + ATI + CVS valgrind)... So go ahead and close this bug. Thanks anyway.
*** Bug has been marked as fixed ***.