Summary: | X session lock using ATI libGL.so | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Mathieu Malaterre <mmalater> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Mathieu Malaterre
2004-02-07 22:54:29 UTC
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 ***. |