|
From: Julian S. <js...@ac...> - 2006-06-17 10:26:06
|
On Saturday 17 June 2006 02:34, Michael Poole wrote: > Timothy B. Terriberry writes: > > The thing that makes it odd, and the only reason I'm bothering to report > > it at all was that the problem occurred with 100% reproducibility with > > valgrind 3.1.1, and has never occurred with 2.4.0. > > Similar problems show up with the fglrx driver when debugging OpenGL > apps under gdb: if the debuggee stops at particular places, it locks > up the machine. I haven't tried it with other drivers, so I don't > know if the behavior is specific to fglrx or not, but I doubt valgrind > has any role other than to trigger it. I believe such problems have been seen (with V) in the past. My vague understanding is that they happen if you have some hardware device mmap'd into user space somehow. It can then start to play up if its bit(s) of memory get prodded by the leak checker. 2.4.0 tracks which memory segments belong to devices and so manages to avoid falling in this hole; 3.0.X and above don't, unfortunately. J |