Re: [Valgrind-users] Showing allocated memory in heap summary
If not yet done, upgrade to the last version of Valgrind (3.8.1).
Then use gdb+vgdb to connect to your application. For this, give
--vgdb-error=0 and follow the on-screen instructions.
I'm using SVN only releases. The docs don't build OK, so my manual didn't have
this info. I need to figure out why
the docs won't build properly.
Then place breakpoints at the relevant place(s) to do a leak search
(e.g. just before the exit of main).
When breakpoint reached, do a leak search from gdb, using :
(gdb) monitor leak_search
Note: there are some optional args to leak_search.
use
(gdb) monitor help
and/or read manual for more info
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
Then use the following monitor command to find the list of leaked blocks
(gdb) monitor block_list a_loss_record_nr_output_by_leak_search
This was it :
(gdb) mo l f r a
snip
==30693== 67 (60 direct, 7 indirect) bytes in 3 blocks are definitely lost in
loss record 7 of 7
==30693==at 0x4007EFC: malloc (vg_replace_malloc.c:270)
==30693==by 0x8064DED: scanner_token_construct (parser_native.c:55)
==30693==by 0x80656FE: is_parser_native_parse_input (parser_native.c:355)
==30693==by 0x8065518: is_parser_native_parse_file (parser_native.c:278)
==30693==by 0x8049749: test1 (test-native-parser.c:26)
==30693==by 0x4022739: run_single_test (TestRun.c:818)
==30693==by 0x402250A: run_single_suite (TestRun.c:759)
==30693==by 0x4021C44: CU_run_all_tests (TestRun.c:379)
==30693==by 0x4023FD4: basic_run_all_tests (Basic.c:228)
==30693==by 0x4023D32: CU_basic_run_tests (Basic.c:90)
==30693==by 0x804A09E: main (test-native-parser.c:199)
snip
(gdb) monitor block_list 7
==30693== 0x402D7F8[20]
==30693== 0x402D840[7] indirect loss record 2
==30693== 0x402D8F8[20]
==30693== 0x402DD10[20]
(gdb) p (_scanner_token) *0x402D7F8
$5 = {destruct = 0x8064e35 scanner_token_destruct, opcode = 12,
orig = 0x401 Address 0x401 out of bounds, data = {n = 0,
s = 0x402d840 global}}
Jackpot :-)
Thanks for the assistance and the final hints Philippe !!
Regards,
Igmar
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Generating VEX code in instrument function (inlining)
Am 05.11.2012 01:49, schrieb Wonjoon Song: Hello all, In the lackey example, there is instrument function like static VG_REGPARM(2) void trace_load(Addr addr, SizeT size). Instead of calling this precompiled function, will I get performance gain if I directly generate VEX code? You will, but it depends on what trace_load is doing. If it is just incrementing a counter, the benefit should be quite high. But if you end up calling another function (such as printf) from your generated IR, it probably is not worth it. Josef Has anybody done this kind of optimization? If so, how much performance gain did you get? Thank you, Wonjoon -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind markup for lock-ordering
On Monday 05 November 2012 23:19:42 Philippe Waroquiers wrote:
On Mon, 2012-11-05 at 18:59 +0100, David Faure wrote:
The testcase http://www.davidfaure.fr/2012/qmutex_trylock.cpp
(from https://bugs.kde.org/show_bug.cgi?id=243232)
shows that an optimization inside Qt leads to a helgrind warning about
wrong lock ordering, making the use of that feature impossible for
detecting actual problems elsewhere (i.e. I have to use
--track-lockorders=no all the time).
Technically if we ignore the distinction between lock and tryLock,
helgrind is right, we did lock the mutexes in reverse order. But because
it's a tryLock, it couldn't possibly deadlock.
Should helgrind simply ignore all pthread_mutex_trylock calls, for the
lockorder detection, even if they succeed? I think so, actually (by
definition they couldn't deadlock, which is what track-lockorders is all
about).
A deadlock can appear if there is a mixture of trylock and lock on
the same lock. So, trylock cannot just be ignored.
E.g.
Thread 1:trylock mutex1
lock mutex2
Thread 2:lock mutex2
lock mutex1
might deadlock.
True.
This means that only trylock in second place should be ignored. More on this
below.
Even without mixture, isn't the below slightly bizarre/dangerous ?
Thread 1: trylock mutex1
trylock mutex2
Thread 2: trylock mutex2
trylock mutex1
No deadlock can ever happen here.
If the 2nd trylock fails, what is the plan B ?
If the program then accesses shared data, a race condition will happen and
will be detected by helgrind anyway. So ignoring the ordering of these
trylocks is ok, I would think. Of course helgrind must record we got the
lock, for the race condition detection feature, but it shouldn't warn about
the wrong order of the locking, since it can't possibly deadlock.
Not that the above would be good programming practice, of course, but helgrind
can't say anything about it if all the locks were acquired. It will warn in
another run, where some trylock fails, and a race ensues.
It seems that a task must unlock all locks and restart
from scratch in the above case.
Yes this is exactly that QOrderedMutexLocker does.
Thread 1: lock mutex1
lock mutex2
Thread 2: lock mutex2
trylock mutex1
if that failed,
unlock mutex2
lock mutex1
lock mutex2
If the trylock fails (because thread1 was first), then it unlocks and restarts
from scratch. I can't see a deadlock risk with that, so ideally helgrind
shouldn't warn.
I guess we might need an option such as:
--trylock-logic={normal-lock|local-retry|full-retry}
normal-lock = current behaviour
local-retry means the task would re-trylock
full-retry means that the plan B is to unlock all locks
and retry everything.
I don't see how this can be a global option. Some piece of code (like
QOrderedMutexLocker) might have the full retry logic above, but other pieces
of code might do something different - e.g. something wrong. It doesn't make
sense to me to tell helgrind this is what all the code paths are going to do
about tryLock, that's impossible to predict in a complex program.
Let me present another case:
Thread 1: lock mutex1
lock mutex2
Thread 2: lock mutex2
trylock mutex1
if that fails, unlock mutex2 and give up
This could happen for a non-critical operation that can be canceled if it
can't be done immediately. Again, no deadlock possible, so helgrind shouldn't
warn about a successful trylock being out of order. And yet this isn't a
full retry, so I don't think --trylock-logic=full-retry is the solution.
Deadlock can only happen if both threads use normal locking as their
second operation. A trylock as the second operation doesn't deadlock.
Or maybe we would need the same info but with an annotation
of the lock operation and/or of the lock itself ?
Sounds like an annotation of the trylock operation, unless we agree on my next
statement:
I am quite sure the simple logic trylock can be ignored
is not ok for all cases.
Right. Let me refine that: trylock can be ignored as the second operation,
i.e. helgrind shouldn't issue the out-of-order-locking-warning at the precise
moment it's seeing a successful out-of-order trylock.
If we can agree on that, then there's no need for an annotation in the code.
PS: see my previous email about VALGRIND_HG_ENABLE_CHECKING not working.
Is this known? Should I report a bug?
Always good to report a bug if you have found a bug :).
Mail will be forgotten, bug entries are less likely to be lost.
OK, will do. On the other hand I'm getting more reaction about the tryLock
issue here than on bug 243232 :-). Anyway, thanks for your input, much
appreciated.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE
Re: [Valgrind-users] Invalid read from within well inside an alloc'd buffer
With vgdb/gdb, the debugger hangs after a couple of continues. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00300b4ea3d7 in writev () from /lib64/libc.so.6 Is there a real 'int3' instruction there, or was SIGTRAP sent from somewhere else [using kill()]? Look with something like: (gdb) x/20i 0x00300b4ea3d7 - 0x20 [Philippe, please comment.] There is no progress after this. The CPU utilization is 0 and it looks like memcheck has hung. On the valgrind side, I see ==29118== Syscall param writev(vector[...]) points to uninitialised byte(s) ==29118==at 0x300B4EA3D7: writev (in /usr/lib64/libc-2.15.so) ==29118==by 0x6256B92: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) What are the likely parameters to that writev()? How many different pieces, of what sizes, etc.? Would the output be going to a disk file, or to a socket? -- -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid read from within well inside an alloc'd buffer
On Tue, Nov 6, 2012 at 8:34 PM, John Reiser jrei...@bitwagon.com wrote: With vgdb/gdb, the debugger hangs after a couple of continues. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00300b4ea3d7 in writev () from /lib64/libc.so.6 Is there a real 'int3' instruction there, or was SIGTRAP sent from somewhere else [using kill()]? Look with something like: (gdb) x/20i 0x00300b4ea3d7 - 0x20 [Philippe, please comment.] There is no progress after this. The CPU utilization is 0 and it looks like memcheck has hung. On the valgrind side, I see ==29118== Syscall param writev(vector[...]) points to uninitialised byte(s) ==29118==at 0x300B4EA3D7: writev (in /usr/lib64/libc-2.15.so) ==29118==by 0x6256B92: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) What are the likely parameters to that writev()? How many different pieces, of what sizes, etc.? Would the output be going to a disk file, or to a socket? The output would be going to a socket. I believe it's just sending out a buffer. If it's just sending out uninitialized data, it should perhaps not be related to the invalid read that I see via valgrind at a later stage? Thanks. -- -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind markup for lock-ordering
On Tue, 2012-11-06 at 13:43 +0100, David Faure wrote:
On Monday 05 November 2012 23:19:42 Philippe Waroquiers wrote:
On Mon, 2012-11-05 at 18:59 +0100, David Faure wrote:
The testcase http://www.davidfaure.fr/2012/qmutex_trylock.cpp
(from https://bugs.kde.org/show_bug.cgi?id=243232)
shows that an optimization inside Qt leads to a helgrind warning about
wrong lock ordering, making the use of that feature impossible for
detecting actual problems elsewhere (i.e. I have to use
--track-lockorders=no all the time).
Technically if we ignore the distinction between lock and tryLock,
helgrind is right, we did lock the mutexes in reverse order. But because
it's a tryLock, it couldn't possibly deadlock.
Should helgrind simply ignore all pthread_mutex_trylock calls, for the
lockorder detection, even if they succeed? I think so, actually (by
definition they couldn't deadlock, which is what track-lockorders is all
about).
A deadlock can appear if there is a mixture of trylock and lock on
the same lock. So, trylock cannot just be ignored.
E.g.
Thread 1:trylock mutex1
lock mutex2
Thread 2:lock mutex2
lock mutex1
might deadlock.
True.
This means that only trylock in second place should be ignored. More on
this
below.
More generally, I guess that you mean trylock in last place should
be ignored (rather than the special case of 2nd place).
This might be difficult to implement as each time a lock is taken,
helgrind checks for order violation. I suspect a later lock operation
might then transform a trylock in last place to a trylock which is
now not anymore in last place.
But of course, when the trylock operation has just been done,
this trylock is last place and so if we would ignore it, then
this would be similar to always ignore the trylock, which is not ok.
Currently, helgrind maintains a graph of lock order.
I suspect we might need different graph node types and/or edge types
to cope with trylock. For sure, more investigations needed looking
in depth at the current algorithm.
Even without mixture, isn't the below slightly bizarre/dangerous ?
Thread 1: trylock mutex1
trylock mutex2
Thread 2: trylock mutex2
trylock mutex1
No deadlock can ever happen here.
Yes, no deadlock can occur. However, this is really a really doubful
construction. The question is: should helgrind report a lock order
warning for such constructs ?
If the 2nd trylock fails, what is the plan B ?
If the program then accesses shared data, a race condition will happen and
will be detected by helgrind anyway. So ignoring the ordering of these
trylocks is ok, I would think. Of course helgrind must record we got the
lock, for the race condition detection feature, but it shouldn't warn about
the wrong order of the locking, since it can't possibly deadlock.
The idea of helgrind is that it detects lock order problems and/or
race condition problems *even* if no deadlock happens and/or if no
race condition really happened.
Maybe it is very unlikely that the trylock fails. Still would be nice
to discover the bug. And if the trylock does not fail, then the race
condition will then not be detected by helgrind.
Not that the above would be good programming practice, of course, but
helgrind
can't say anything about it if all the locks were acquired. It will warn in
another run, where some trylock fails, and a race ensues.
It seems that a task must unlock all locks and restart
from scratch in the above case.
Yes this is exactly that QOrderedMutexLocker does.
Thread 1: lock mutex1
lock mutex2
Thread 2: lock mutex2
trylock mutex1
if that failed,
unlock mutex2
lock mutex1
lock mutex2
QOrderedMutexLocker really retries locking in an other order
than the operations done by Thread 2 ?
Or is that a typo ?
If the trylock fails (because thread1 was first), then it unlocks and
restarts
from scratch. I can't see a deadlock risk with that, so ideally helgrind
shouldn't warn.
I guess we might need an option such as:
--trylock-logic={normal-lock|local-retry|full-retry}
normal-lock = current behaviour
local-retry means the task would re-trylock
full-retry means that the plan B is to unlock all locks
and retry everything.
I don't see how this can be a global option. Some piece of code (like
QOrderedMutexLocker) might have the full retry logic above, but other
pieces
of code might do something different - e.g. something wrong. It doesn't make
sense to me to tell helgrind this is what all the code paths are going to do
about tryLock, that's impossible to predict in a complex program.
For sure, generally, an application can do a big variety of behaviours.
I suspect however that an application might (this is sane at least) try
to
