|
From: Lee D. <lee...@mi...> - 2004-04-22 17:06:12
|
Please let me know if you solve this one as my 2.1.1 also behaves the same. > -----Original Message----- > From: val...@li... > [mailto:val...@li...]On Behalf > Of Srivatsa > Sent: Thursday, April 22, 2004 1:44 AM > To: 'Nicholas Nethercote' > Cc: val...@li...; ra...@in...; > sr...@in... > Subject: RE: [Valgrind-users] Problem with valgrind > > > Hi Nicholas, > We have tried using "valgrind 2.1.1" but we are getting a different > problem. > After installing valgrind 2.1.1, > "valgrind ls -l" displays the usage string and it doesn't > give any memory > leakage > report. > We did try > "valgrind --tool=memcheck ls -l " This gives the following output > > ==29730== Memcheck, a memory error detector for x86-linux. > ==29730== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. > ==29730== Using valgrind-2.1.1, a program supervision framework for > x86-linux. > ==29730== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. > --29730-- INTERNAL ERROR: Valgrind received a signal 11 > (SIGSEGV) - exiting > --29730-- si_code=1 Fault EIP: 0xB025BB90 (); Faulting > address: 0x50100000 > > valgrind: the `impossible' happened: > Killed by fatal signal > Basic block ctr is approximately 0 > ==29730== at 0xB802A143: ??? > ==29730== by 0xB802A142: ??? > ==29730== by 0xB802A158: ??? > ==29730== by 0xB802FA63: ??? > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==29730== at 0x3C000B30: ??? > > > Note: see also the FAQ.txt in the source distribution. > It contains workarounds to several common problems. > > If that doesn't help, please report this bug to: valgrind.kde.org > > In the bug report, send all the above text, the valgrind > version, and what Linux distro you are using. Thanks. > > [root@dlilo1 valgrind-2.1.1]# valgrind ls -l > usage: valgrind --tool=<toolname> [options] prog-and-args > > common user options for all Valgrind tools, with defaults in [ ]: > --tool=<name> Use the Valgrind tool named <name> > --help show this message > --help-debug show this message, plus > debugging options > --version show version > -q --quiet run silently; only print error msgs > -v --verbose be more verbose, incl counts of errors > --trace-children=no|yes Valgrind-ise child processes? [no] > --track-fds=no|yes Track open file descriptors? [no] > > uncommon user options for all Valgrind tools: > --run-libc-freeres=no|yes Free up glibc memory at exit? [yes] > --weird-hacks=hack1,hack2,... [none] > recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls > --signal-polltime=<time> time, in mS, we should poll for signals. > Only applies for older kernels > which need > signal routing [50] > --lowlat-signals=no|yes improve wake-up latency when a > thread receives > a signal [no] > --lowlat-syscalls=no|yes improve wake-up latency when a thread's > syscall completes [no] > --pointercheck=no|yes enforce client address space > limits [yes] > > user options for Valgrind tools that report errors: > --logfile-fd=<number> file descriptor for messages [2=stderr] > --logfile=<file> log messages to <file>.pid<pid> > --logsocket=ipaddr:port log messages to socket ipaddr:port > --demangle=no|yes automatically demangle C++ names? [yes] > --num-callers=<number> show <num> callers in stack traces [4] > --error-limit=no|yes stop showing new errors if too > many? [yes] > --show-below-main=no|yes continue stack traces below main() [no] > --suppressions=<filename> suppress errors described in <filename> > --gen-suppressions=no|yes print suppressions for errors > detected [no] > --db-attach=no|yes start debugger when errors > detected? [no] > --db-command=<command> command to start debugger [gdb > -nw %f %p] > --input-fd=<number> file descriptor for input [0=stdin] > > > Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc > > Valgrind is Copyright (C) 2000-2004 Julian Seward > and licensed under the GNU General Public License, version 2. > Bug reports, feedback, admiration, abuse, etc, to: valgrind.kde.org. > > Tools are copyright and licensed by their authors. See each > tool's start-up message for more information. > > [root@dlilo1 valgrind-2.1.1]# valgrind --tool=memcheck ls -l > ==30226== Memcheck, a memory error detector for x86-linux. > ==30226== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. > ==30226== Using valgrind-2.1.1, a program supervision framework for > x86-linux. > ==30226== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. > --30226-- INTERNAL ERROR: Valgrind received a signal 11 > (SIGSEGV) - exiting > --30226-- si_code=1 Fault EIP: 0xB025BB90 (); Faulting > address: 0x50100000 > > valgrind: the `impossible' happened: > Killed by fatal signal > Basic block ctr is approximately 0 > ==30226== at 0xB802A143: ??? > ==30226== by 0xB802A142: ??? > ==30226== by 0xB802A158: ??? > ==30226== by 0xB802FA63: ??? > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==30226== at 0x3C000B30: ??? > > > Note: see also the FAQ.txt in the source distribution. > It contains workarounds to several common problems. > > If that doesn't help, please report this bug to: valgrind.kde.org > > In the bug report, send all the above text, the valgrind > version, and what Linux distro you are using. Thanks. > > Whereas in case of valgrind-2.0.0 "valgrind ls -l" works as > expected. > > Please let me know if you have any other suggestion. > Thanks®ards > M.S.Srivatsa > -----Original Message----- > From: Nicholas Nethercote [mailto:nj...@he...]On Behalf Of > Nicholas Nethercote > Sent: Wednesday, April 21, 2004 7:49 PM > To: Srivatsa > Cc: val...@li... > Subject: Re: [Valgrind-users] Problem with valgrind > > > On Wed, 21 Apr 2004, Srivatsa wrote: > > > I am getting following output when i ran a "valgrind" on some > > binary. > > valgrind version is 2.0.0 > > > > output we got is : > > > > [...] > > > > disInstr: unhandled instruction bytes: 0xF0 0xF 0xC7 0xF > > Illegal instruction > > Try version 2.1.1, it has more complete coverage of x86 instructions. > > > From the above output it is clear that we are not getting > any memory > > leakage report. > > That is not correct; memory leaks are only reported by > Memcheck when a > program terminates, and that program didn't terminate > properly because of > the assertion failure. So it's unclear whether you have > memory leaks or > not. And you need to use the --leak-check=yes flag anyway. > > N > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |