|
From: Bryan M. <om...@br...> - 2005-11-12 19:00:34
|
Here we go: . . . --13048-- o_omegaLoadTracker(0xBEBD4350, 0x5F7CAB0) ## Loads from stack --13048-- o_omegaDetector(0x10, 0xBEBD4354) ## Bumps (sim)ESP --13048-- killing range 0x4 bytes from 0xBEBD4350 ## Die Stack --13048-- o_removeMemBlockReference tp=0xBEBD4350, mb=0x5F7CAB0 --13048-- Removing tracked pointer at 0xBEBD4350 pointing to 0x5F7CAB0 ## lose reference on the stack ==13048== Leaking block of 8(0x8) bytes ## last one so we leak ==13048== at 0x401BA2D: operator new(unsigned) (vg_replace_malloc.c:164) ==13048== by 0x502F006: QString::QString(char const*) (in /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== Block at 0x5F7CAB0 allocated ==13048== at 0x401BE32: operator new[](unsigned) (vg_replace_malloc.c:197) ==13048== by 0x502E5DF: (within /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== Final live pointer at 0xBEBD4350 allocated ==13048== at 0x401B974: operator new(unsigned) (vg_replace_malloc.c:164) ==13048== by 0x502F006: QString::QString(char const*) (in /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== --13048-- o_cleanupMemBlock(0x622FCE88) --13048-- o_cleanupMemBlock mb=0x5F7CAB0 --13048-- cleanup shadow pointers --13048-- cleanup tracked pointers --13048-- killing range 0x8 bytes from 0x5F7CAB0 --13048-- killing range 0x8 bytes from 0x5F7CAB0 done. --13048-- killing range 0x4 bytes from 0xBEBD4350 done. --13048-- o_omegaDetector(0x18, 0x5F7CAB0) ## Value read from stack written into (sim)ESI . . . o_omegaDetecor shows address, value. Where address is very small, it is a register offset as used in PUT. On my 32 bit machine: 0x10 - (sim)ESP 0x18 - (sim)ESI o_omegaLoadTracker shows address, value. Nowhere is the value read from the stack at the top visible in the sim cpu until it is finally written into the sim ESI. That's what causes the false leak report - I have no visible references when the stack is invalidated, taking the final in-memory reference with it. If the stack invalidation happened after the load from the stack made it into the (sim) register, I would detect it and prevent the leak report. Tracking the SP for movement was only a hack attempt in order to try to get around the above problem. Hope this helps, Bryan "Brain Murders" Meredith On Saturday 12 Nov 2005 18:24, Julian Seward wrote: > > I'm lost I'm afraid. Can you send a specific example of an x86->IR > translation and point specifically at the IR artefacts that are a problem. > > One thing I do know is you can't assume the SP moves only once per bb -- > there's no constraints requiring the original producer of the code (gcc) > to stick to that. > > J > > > On Saturday 12 November 2005 18:09, Bryan Meredith wrote: > > I can't seem to instrument my way out of it - the (sim)SP update is too > > early but there is no way of knowing just how long to hold off before > > invalidating the stack. There are also multiple die_stack calls occuring > > within a basic block and delaying them is not a good idea - we just end up > > in a mess. > > > > Obviously there is no way that VEX is going to be tweaked this side of 3.1 > > but is making the (sim)SP update occur more in sequence something that > > would be considered in the future (possibly through a command line switch > > or internal function call if the change will break things) ? > > > > There might be a another way of doing this but it eludes me at the moment > > :( > > > > > > Thanks in advance, > > Bryan "Brain Murders" Meredith > > > > On Saturday 12 Nov 2005 14:16, Bryan Meredith wrote: > > > Nope - didn't help - exactly the same behaviour. > > > > > > I'll try something with the instrumentation so I cache the die_stack > > > parameters then act on them just before the jump instruction at the block > > > end. If there is more than one die_stack call, I'll see what the > > > parameters are and if there is a sensible way to handle it. > > > > > > Bryan "Brain Murders" Meredith > > > > > > On Saturday 12 Nov 2005 12:13, Julian Seward wrote: > > > > Try --vex-iropt-precise-memory-exns=no. The flag is mis-named, but it > > > > might do what you want. > > > > > > > > J > > > > > > > > On Saturday 12 November 2005 11:21, Bryan Meredith wrote: > > > > > I have found the problem. > > > > > > > > > > Basically, there is a little bit in the documentation for VEX that > > > > states > > > > > > > that the simulated PC registers are updated lazily, apart from the > > > > > stack pointer which is updated immediately. > > > > > > > > > > The problem I am having is that when the die_stack function is > > > > > called, > > > > the > > > > > > > simulated processor registers are not in a consistant state: > > > > > > > > > > read from stack -> register(real) > > > > > move SP (real) > > > > > SP(real) -> SP(sim) > > > > > call die_stack() > > > > > register(real) -> register(sim) > > > > > > > > > > Because the value on the stack is the last reference to an allocated > > > > block > > > > > > > that I am tracking, when die_stack is called, I note that the > > > > > reference dies and raise a leak report. However, this is not the last > > > > > reference as > > > > > > if > > > > > > > > the stack ->reg(real) reg(real)->reg(sim) had occurred, I would have > > > > > tracked the value there and not leaked. > > > > > > > > > > So, two ways of fixing this I think (open to suggestions as ever): > > > > > > > > > > Tweak VEX so that pending register(sim) updates are flushed before > > > > > the SP(sim) is written. > > > > > Trap the stack change but don't act until the basic block ends so > > > > > that registers(sim) are consistant. > > > > > > > > > > For the second one to work, I have to assume that the stack pointer > > > > > is > > > > > > only > > > > > > > > moved up once in a basic block. I havent done any x86 assembler > > > > previously > > > > > > > so I dont know how sensible an assumption this is. > > > > > > > > > > Any help / advice appreciated. > > > > > > > > > > thanks, > > > > > Bryan "Brain Murders" Meredith > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > SF.Net email is sponsored by: > > > > > Tame your development challenges with Apache's Geronimo App Server. > > > > > Download it for free - -and be entered to win a 42" plasma tv or your > > > > very > > > > > > > own Sony(tm)PSP. Click here to play: > > > > http://sourceforge.net/geronimo.php > > > > > > > _______________________________________________ > > > > > Valgrind-developers mailing list > > > > > Val...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > > > ------------------------------------------------------- > > > > SF.Net email is sponsored by: > > > > Tame your development challenges with Apache's Geronimo App Server. > > > > Download > > > > > > it for free - -and be entered to win a 42" plasma tv or your very own > > > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > > > _______________________________________________ > > > > Valgrind-developers mailing list > > > > Val...@li... > > > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App Server. > > > Download it for free - -and be entered to win a 42" plasma tv or your > > > very own Sony(tm)PSP. Click here to play: > > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Valgrind-developers mailing list > > > Val...@li... > > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > > Download it for free - -and be entered to win a 42" plasma tv or your very > > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |