On Tue, Jul 27, 2010 at 4:36 AM, Aurelien Jarno <aurel...@aurel32.net> wrote: >> >> The problem is that parts of the dynamic linker code are executing >> branch instructions which depend on the value of data (e.g. variables) >> which have not been initialised. That's precisely the kind of problem >> that Valgrind detects. >> >> We have a choice of (at least) two options: >> 1. Fix the bug in the dynamic linker >> 2. Shrug and configure valgrind to ignore the problem so that valgrind is >> still useful for people's programs. >> >> Clearly (1) is better but (2) is available for the case where we can't >> fix the bug in the dynamic linker (or upstream refuses the patch, >> etc.) > > Looking more in details, it doesn't seems to be any problem in the > dynamic linker. The errors reported are in string comparisons function, > which are optimized. They access data further than the size of the data, > in order to do parallel comparisons, however they always make sure not > to cross a page boundary. Valgrind is not clever enough to understand > this method, so it report the error. > > I am therefore reassigning this bug to this package, so that this > problem can be ignored.
That seems an unlikely explanation to me because it doesn't seem to be consistent with what Valgrind actually does. Valgrind is complaining not because the data being accessed is not mapped. It is complaining because 1. the initial state of some bits is indeterminate (this is allowed, it's fine and does not generate a diagnostic) AND 2. the flow control in the code depends on the state of those uninitialised bits If you're saying that Valgrind is mis-repoting, are you saying that the relevant bits are in fact initialised, or are you saying that the result of the function *does not depend* on the state of those bits, even though a branch is taken-or-not depending on their state? Thanks, James. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
