|
From: Ashley P. <as...@qu...> - 2005-08-26 09:18:32
|
On Thu, 2005-08-25 at 22:23 -0500, Nicholas Nethercote wrote: > On Thu, 25 Aug 2005, Ashley Pittman wrote: > > > This is key, it turns out I've been fooled by the RHEL4 > > prelinking/address space randomisation code again. Although the > > library's are the "same" to the extent that they come from the same rpm > > and the rpm passes a verify test the installed ones have been noodled in > > some way (not simply stripped). > > [...] > > My best guess is that in the prelinked library the "real" static symbols > > are being used where as in the non prelinked library the relocation > > table is being used and without having a handle on the relocation table > > valgrind isn't able to correlate the address with the source file. This > > isn't really my area of expertise though. > > So it sounds like this isn't really a problem with Valgrind, but an issue > with the environment? Maybe, I *thought* that prelinking worked my modifying the load base address of the library and when you did prelink -u (undo) it reverted it's changes to the file in place, this would imply that when the library is in a prelinked state debugging is there but valgrind can't extract it. It is possible however that the undo operation just copys a origional back over the top. If the former it's likely a valgrind bug, if the latter it's probably a prelink bug/feature. Now I know what's causing it I'm less concerned, I know a workaround and I'll try playing around with prelink a bit more to see if I can understand it properly. Ashley, |