|
From: Ashoka K <ash...@gm...> - 2014-03-19 12:45:11
|
Hi, I have an ARM based embedded system and running a lrge application which never returns. I want to use valgrind on this. I cross compiled and built the valgrind and run it on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled. I tested and found that summary of valgrind output is shown only on graceful exit of the application. Tested with a small memleak program as described in Valgrind documentation. Is there any way to check the the summary of Valgrind found issues while application is still running, like on returning from any function. Or is it required to exit the application so that valgrind summarizes its findings. The application which i want to run Valgrind on never returns normally. If graceful exit from process is always a requirement then can we trust the summary output of Valgrind if application process is killed with SIGTERM or any other signal. -AK |
|
From: Tom H. <to...@co...> - 2014-03-19 13:50:27
|
On 19/03/14 12:45, Ashoka K wrote: on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled. > > I tested and found that summary of valgrind output is shown only on > graceful exit of > the application. Tested with a small memleak program as described in Valgrind > documentation. Memory leaks are only reported when the program finishes, unless you use a client request to ask for a check. Other errors, such as using uninitialised values, are reported as soon as they occur. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2014-03-19 20:02:48
|
On Wed, 2014-03-19 at 13:50 +0000, Tom Hughes wrote: > On 19/03/14 12:45, Ashoka K wrote: > on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled. > > > > I tested and found that summary of valgrind output is shown only on > > graceful exit of > > the application. Tested with a small memleak program as described in Valgrind > > documentation. > > Memory leaks are only reported when the program finishes, unless you use > a client request to ask for a check. You can also trigger leak check from shell script (or from gdb), using vgdb. e.g. vgdb leak_check full possible increased will do a leak check, showing the possibly and definitely leaked loss records that have increased since the previous leak check. Philippe |
|
From: Giuseppe A. <giu...@sa...> - 2014-03-21 10:15:55
|
Hello, I've installed Valgrind and I've added debug info to my libc. But now, each time I try to launch Valgrind I have the following error: /*root@mx27:/usr/local/lib/valgrind# valgrind ls -la*//* *//*==1486== Memcheck, a memory error detector*//* *//*==1486== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.*//* *//*==1486== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info*//* *//*==1486== Command: ls -la*//* *//*==1486== *//* *//*==1486== *//* *//*==1486== Process terminating with default action of signal 4 (SIGILL)*//* *//*==1486== Illegal opcode at address 0x3807BD5C*//* *//*==1486== at 0x4000800: ??? (in /lib/ld-2.6.1.so)*//* *//* *//*valgrind: m_scheduler/scheduler.c:957 (run_thread_for_a_while): Assertion 'done_this_time >= 0' failed.*//* *//*==1486== at 0x38034C18: report_and_quit (m_libcassert.c:260)*//* *//*==1486== by 0x624A9AAF: ???*//* *//* *//*sched status:*//* *//* running_tid=1*//* *//* *//*Thread 1: status = VgTs_Runnable*//* *//*==1486== at 0x4000800: ??? (in /lib/ld-2.6.1.so)*/ ...any idea? Thanks Il 19/03/2014 21:02, Philippe Waroquiers ha scritto: > On Wed, 2014-03-19 at 13:50 +0000, Tom Hughes wrote: >> On 19/03/14 12:45, Ashoka K wrote: >> on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled. >>> I tested and found that summary of valgrind output is shown only on >>> graceful exit of >>> the application. Tested with a small memleak program as described in Valgrind >>> documentation. >> Memory leaks are only reported when the program finishes, unless you use >> a client request to ask for a check. > You can also trigger leak check from shell script (or from gdb), > using vgdb. > > e.g. vgdb leak_check full possible increased > will do a leak check, showing the possibly and definitely leaked loss > records that have increased since the previous leak check. > > Philippe > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@Bi...> - 2014-03-22 03:06:06
|
On 03/21/2014 03:15 AM, Giuseppe Assalve wrote: > I've installed Valgrind and I've added debug info to my libc. Please tell us which CPU architecture and variant, chip manufacturer, and model name. Please tell us which operating system, distribution brand name, and version number. Please tell us which libc (glibc, dietlibc, uClibc, bionic, ...) and version number. Please start a new newsgroup posting thread unless the content of your post is a direct reply to an existing conversation. Else there is little incentive to pay any attention to your report. |
|
From: John R. <jr...@Bi...> - 2014-03-19 14:01:45
|
> Is there any way to check the the summary of Valgrind found issues while > application is still running ... Look in memcheck/memcheck.h and search for all instances of LEAK_CHECK. The app should catch a signal and the handler should call one of the LEAK_CHECK requests. Or, make a suitable LEAK_CHECK call synchronously at appropriate times: just before and after each "phase", or after every N events, etc. -- |