You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(5) |
2
(5) |
3
(3) |
|
4
|
5
(4) |
6
(6) |
7
(4) |
8
(14) |
9
(2) |
10
(4) |
|
11
(2) |
12
(2) |
13
(4) |
14
(7) |
15
(5) |
16
(11) |
17
(4) |
|
18
|
19
(10) |
20
(4) |
21
(13) |
22
(6) |
23
(6) |
24
(4) |
|
25
(5) |
26
(18) |
27
(7) |
28
(10) |
29
(11) |
30
(17) |
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-04-23 08:21:57
|
Hi, > It shouldn't make any difference, since that is all hardware-level stuff. > The only exception is that Valgrind doesn't yet support SSE3 instructions, > and I think there are some hyperthreading-related instructions in SSE3? It doesn't seem to make any difference in our case. We have dual-CPU Xeon boxes with hyper-threading enabled and valgrind works just fine here. Dimitri |
|
From: Nicholas N. <nj...@ca...> - 2004-04-23 07:22:00
|
On Fri, 23 Apr 2004, Banibrata Dutta wrote: > are there any known issues with running Valgrind on Intel P4's with > HyperThreading technology enabled, and or with multi-CPU Xeon boxes ?? just > wondering. It shouldn't make any difference, since that is all hardware-level stuff. The only exception is that Valgrind doesn't yet support SSE3 instructions, and I think there are some hyperthreading-related instructions in SSE3? N |
|
From: Banibrata D. <du...@in...> - 2004-04-23 05:39:48
|
hi, are there any known issues with running Valgrind on Intel P4's with HyperThreading technology enabled, and or with multi-CPU Xeon boxes ?? just wondering. thanks & regards, Banibrata Dutta Hewlett-Packard ISO Pvt. Ltd, 29, Cunningham Road, Bangalore - 560052, India. Tel: +91-80-22051796 |
|
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 > |
|
From: Srivatsa <sr...@in...> - 2004-04-22 09:16:41
|
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 |
|
From: Tom H. <th...@cy...> - 2004-04-22 08:09:09
|
In message <108...@sa...>
tm...@sa... wrote:
> In vg 2.1.1 and cvs the following symbols are used:
>
> vg_main.c:1140: `AT_DCACHEBSIZE' undeclared (first use in this function)
> vg_main.c:1141: `AT_ICACHEBSIZE' undeclared (first use in this function)
> vg_main.c:1142: `AT_UCACHEBSIZE' undeclared (first use in this function)
>
> As far as I can tell, they are PPC specific (PPC_ELF_H).
>
> #define AT_DCACHEBSIZE 19
> #define AT_ICACHEBSIZE 20
> #define AT_UCACHEBSIZE 21
It seems to be unconditionally defined in elf.h on my x86 systems.
I believe that 2.2 kernels didn't define it though, so that may be
your problem. There are other problems with 2.2 though, which is why
the build issues haven't been fixed.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <tm...@sa...> - 2004-04-22 02:25:30
|
In vg 2.1.1 and cvs the following symbols are used: vg_main.c:1140: `AT_DCACHEBSIZE' undeclared (first use in this function) vg_main.c:1141: `AT_ICACHEBSIZE' undeclared (first use in this function) vg_main.c:1142: `AT_UCACHEBSIZE' undeclared (first use in this function) As far as I can tell, they are PPC specific (PPC_ELF_H). #define AT_DCACHEBSIZE 19 #define AT_ICACHEBSIZE 20 #define AT_UCACHEBSIZE 21 |
|
From: Bob R. <bo...@br...> - 2004-04-22 02:14:09
|
On Thu, Apr 22, 2004 at 02:50:14AM +0200, Henrik Nordstrom wrote: > On Tue, 20 Apr 2004, Bob Rossi wrote: > > > Is there any easy way to run valgrind on a curses application. > > Basically, when you tell valgrind to run a new window, is there an > > option to have it execute the new program in an xterm or something? That > > would help the I/O fighting between valgrind and the exe. > > The following should work I think: > > exec 5>&2 > xterm -e valgrind --logfile-fd=5 ... Wow. I have never knew you could do that. Thanks! Bob Rossi |
|
From: Henrik N. <hn...@ma...> - 2004-04-22 00:51:12
|
On Tue, 20 Apr 2004, Bob Rossi wrote: > Is there any easy way to run valgrind on a curses application. > Basically, when you tell valgrind to run a new window, is there an > option to have it execute the new program in an xterm or something? That > would help the I/O fighting between valgrind and the exe. The following should work I think: exec 5>&2 xterm -e valgrind --logfile-fd=5 ... Regards Henrik |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-04-21 17:42:01
|
Ignore me, I did not realise that I now have to explicitly specify --tool=memcheck. Joshua Moore-Oliva |
|
From: Tom H. <th...@cy...> - 2004-04-21 17:39:52
|
In message <200...@ch...>
Joshua Moore-Oliva <jo...@ch...> wrote:
> I installed valgrind 2.1.1 and now whenever I run
>
> valgrind ./a.out
>
> I get this.. it refuses to run any programs?
You haven't specified which tool to use - there is no longer a
default tool so you will need this:
valgrind --tool=memcheck ./a.out
You can add "--tool=memcheck" to ~/.valgrindrc if you want to make
it the default.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Andrew C. <and...@ya...> - 2004-04-21 17:39:20
|
On Wednesday 21 Apr 2004 18:44, Joshua Moore-Oliva wrote: > I installed valgrind 2.1.1 and now whenever I run > > valgrind ./a.out Use valgrind --tool=memcheck ./a.out (or specify a different --tool=...) Andrew |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-04-21 17:36:03
|
I installed valgrind 2.1.1 and now whenever I run
valgrind ./a.out
I get this.. it refuses to run any programs?
I'm using glibc 2.3.3-pre
valgrind ./a.out
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.
On April 21, 2004 1:32 pm, Tom Hughes wrote:
> In message <200...@ch...>
> Joshua Moore-Oliva <jo...@ch...> wrote:
>
> > Ok, so I need to valgrind a program that contains epoll.
> >
> > Now, valgrind is telling me that I can't run the program using epoll...
> > and I have no idea how ti implement the system call myself..
> >
> > This may be a laughable question, but is there a way to just get valgrind
> > to nto debug the epoll system call and just debug the rest of the code?
> >
> > Or even better is there a cvs version//patch for valgrind that will let me
> > debug epoll programs?
>
> A quick grep of the source suggests that 2.1.1 has epoll support.
>
> Tom
>
|
|
From: Tom H. <th...@cy...> - 2004-04-21 17:32:01
|
In message <200...@ch...>
Joshua Moore-Oliva <jo...@ch...> wrote:
> Ok, so I need to valgrind a program that contains epoll.
>
> Now, valgrind is telling me that I can't run the program using epoll...
> and I have no idea how ti implement the system call myself..
>
> This may be a laughable question, but is there a way to just get valgrind
> to nto debug the epoll system call and just debug the rest of the code?
>
> Or even better is there a cvs version//patch for valgrind that will let me
> debug epoll programs?
A quick grep of the source suggests that 2.1.1 has epoll support.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joshua Moore-O. <jo...@ch...> - 2004-04-21 17:28:06
|
Ok, so I need to valgrind a program that contains epoll. Now, valgrind is telling me that I can't run the program using epoll... and I have no idea how ti implement the system call myself.. This may be a laughable question, but is there a way to just get valgrind to nto debug the epoll system call and just debug the rest of the code? Or even better is there a cvs version//patch for valgrind that will let me debug epoll programs? Thanks, Joshua Moore-Oliva |
|
From:
|
> I can fix valgrind to initialise %cs, %ds and %ss at startup to match > the system, which will stop the segv but it will then assert as the > segment register will point at a GDT entry that valgrind can't > handle currently. Thank! Assertion is better than SEGV. > value. Given that, an instruction with an explicit %ds qualification > is the same as one with no segment qualification except that it > probably executes much slower... Yesterday I add library into project, checked program under valgrind and = received SEGV. It was strange for me because before valgrind produce = assertion messages while running incorrect programs. Letter was sent = only for bug report. I was surprised looking into library code and rewrote it :) Dmytry Dyachenko http://CryptoPro.ru |
|
From: Tom H. <th...@cy...> - 2004-04-21 15:09:40
|
In message <147...@xf...>
=B4=EC=EF=E7=D5=DD=DA=DE =B4=DC=D8=E2=E0=D8=D9 =B3=D5=DD=DD=D0=D4=
=EC=D5=D2=D8=E7 <dim@CryptoPro.ru> wrote:
> I have valgrind's strange error while running a program:
> int main()
> {
> __asm("movl %eax,%ds:0(%ebp)");
> return 0;
> }
>
> And there are no valgrind's error messages as usually in incorrect
> program, "Segmentation fault" only :( Without 'ds:' valgrind run
> correctly.
Unfortunately valgrind doesn't fully emulate segmentation at the
moment. It is only the use of segment registers to access thread
local storage in the way that glibc does it that is supported.
It is dying because the emulated %ds is not filled in at startup
with the system value, but is filled with zero instead. That causes
valgrind to raise a segmentation fault in the target program as the
segment register appears to have a system privilege level.
I can fix valgrind to initialise %cs, %ds and %ss at startup to match
the system, which will stop the segv but it will then assert as the
segment register will point at a GDT entry that valgrind can't
handle currently.
Why are you trying to do this anyway? You obviously aren't setting
up your own segment or you would have changed %ds to some other
value. Given that, an instruction with an explicit %ds qualification
is the same as one with no segment qualification except that it
probably executes much slower...
Tom
--=20
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 14:19:00
|
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 |
|
From: Srivatsa <sr...@in...> - 2004-04-21 14:05:32
|
Hi , I am getting following output when i ran a "valgrind" on some binary. valgrind version is 2.0.0 output we got is : ==6180== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==6180== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==6180== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==6180== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==6180== Command line: ==6180== ./hponcfg ==6180== Startup, with flags: ==6180== --suppressions=/usr/local/lib/valgrind/default.supp ==6180== -v ==6180== Reading syms from /root/valgrind/valgrind-2.0.0/hponcfg ==6180== Reading syms from /lib/ld-2.2.93.so ==6180== object doesn't have any debug info ==6180== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so ==6180== Reading syms from /usr/local/lib/valgrind/valgrind.so ==6180== Reading syms from /usr/lib/libcpqci.so.1.0 ==6180== Reading syms from /lib/i686/libc-2.2.93.so ==6180== object doesn't have any debug info ==6180== Reading suppressions file: /usr/local/lib/valgrind/default.supp ==6180== Estimated CPU clock rate is 2816 MHz ==6180== No RILOE II board found ==6180== Invalid read of size 4 ==6180== at 0x4022B644: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== by 0x8048EF1: probe_mp_device (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== by 0x8048CF7: main (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A018 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022B655: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== by 0x8048EF1: probe_mp_device (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== by 0x8048CF7: main (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A298 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD33: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A084 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD36: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A080 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD41: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A104 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD44: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A100 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD53: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A008 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD69: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A008 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD80: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A184 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD83: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A180 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD8E: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A18C is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD91: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A188 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD9C: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A084 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BD9F: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A080 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDB2: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A104 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDB5: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A100 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDCC: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A184 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDCF: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A180 is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDE6: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A18C is not stack'd, malloc'd or free'd ==6180== ==6180== Invalid read of size 4 ==6180== at 0x4022BDE9: CpqCiFifoDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022C4D9: CpqCiPacketDequeue (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x4022B690: CpqCiSend (in /usr/lib/libcpqci.so.1.0) ==6180== by 0x804A647: ilo_detect_firmflash (in /root/valgrind/valgrind-2.0.0/hponcfg) ==6180== Address 0x4117A188 is not stack'd, malloc'd or free'd disInstr: unhandled instruction bytes: 0xF0 0xF 0xC7 0xF Illegal instruction From the above output it is clear that we are not getting any memory leakage report. Please let me know how to resolve the above issue. Thanks®ards M.S.Srivatsa |
|
From:
|
I have valgrind's strange error while running a program:
int main()
{
__asm("movl %eax,%ds:0(%ebp)");
return 0;
}
And there are no valgrind's error messages as usually in incorrect =
program, "Segmentation fault" only :(
Without 'ds:' valgrind run correctly.
I use latest valgrind from CVS-head/
Valgrind output follow:
[dim@nrepus valgrind]$ valgrind --tool=3Dmemcheck -v ./a.out
=3D=3D10751=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D10751=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D10751=3D=3D Using valgrind-2.1.2.CVS, a program supervision =
framework for x86-linux.
=3D=3D10751=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D10751=3D=3D Valgrind library directory: /usr/local/lib/valgrind
=3D=3D10751=3D=3D Command line
=3D=3D10751=3D=3D ./a.out
=3D=3D10751=3D=3D Startup, with flags:
=3D=3D10751=3D=3D --tool=3Dmemcheck
=3D=3D10751=3D=3D -v
=3D=3D10751=3D=3D Contents of /proc/version:
=3D=3D10751=3D=3D Linux version 2.4.20-28.8smp =
(bhc...@da...) (gcc version 3.2 20020903 (Red Hat =
Linux 8.0 3.2-7)) #1 SMP Thu Dec 18 12:25:21 EST 2003
[skip]
=3D=3D10751=3D=3D Process terminating with default action of signal 11 =
(SIGSEGV)
=3D=3D10751=3D=3D at 0x8048304: main (in =
/u2/home/dim/src/valgrind/a.out)
=3D=3D10751=3D=3D
=3D=3D10751=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: =
11 from 1)
--10751--
--10751-- supp: 11 Ugly strchr error in /lib/ld-2.3.2.so
=3D=3D10751=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D10751=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D10751=3D=3D
--10751-- TT/TC: 0 tc sectors discarded.
--10751-- 891 chainings, 0 unchainings.
--10751-- translate: new 1292 (23589 -> 307530; ratio 130:10)
--10751-- discard 0 (0 -> 0; ratio 0:10).
--10751-- dispatch: 18973 jumps (bb entries), of which 2992 (15%) were =
unchained.
--10751-- 25/1333 major/minor sched events. 1292 tt_fast =
misses.
--10751-- reg-alloc: 325 t-req-spill, 57555+2598 orig+spill uis, 7254 =
total-reg-r.
--10751-- sanity: 14 cheap, 1 expensive checks.
--10751-- ccalls: 4746 C calls, 53% saves+restores avoided (14832 =
bytes)
--10751-- 6321 args, avg 0.85 setup instrs each (1788 bytes)
--10751-- 0% clear the stack (14235 bytes)
--10751-- 2282 retvals, 26% of reg-reg movs avoided (1184 =
bytes)
Segmentation fault
Dmitry G. Dyachenko
http://CryptoPro.ru
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 07:21:15
|
On Tue, 20 Apr 2004, Bob Rossi wrote:
> Is there any easy way to run valgrind on a curses application.
> Basically, when you tell valgrind to run a new window, is there an
> option to have it execute the new program in an xterm or something? That
> would help the I/O fighting between valgrind and the exe.
Do these options help?
--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
Eg.
valgrind --tool=memcheck --logfile-fd=19 ./myapp 19> myapp.out
N
|
|
From: Bob R. <bo...@br...> - 2004-04-21 01:56:38
|
Hi, Is there any easy way to run valgrind on a curses application. Basically, when you tell valgrind to run a new window, is there an option to have it execute the new program in an xterm or something? That would help the I/O fighting between valgrind and the exe. Any ideas? Thanks, Bob Rossi |
|
From: David E. <tw...@us...> - 2004-04-20 16:58:59
|
On Tue, 2004-04-20 at 17:20, Jim Amrhein wrote:
> Hi , I'm new to valgrind.
> My setup :
> Redhat 9
> gcc -v
> Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
> Configured with: ./configure
> Thread model: posix
> gcc version 3.2.2
>
> Valgrind version valgrind-2.0.0
>
> The code :
>
>
> outfile = (char *)malloc(100);
>
> (void) strncpy (outfile, infile_backup,len);
>
> jfif_name = (char *) malloc(100);
>
> Line 72: (void) strcpy(jfif_name, outfile );
>
>
> The errors:
> ==16656== 1 errors in context 1 of 2:
> ==16656== Conditional jump or move depends on uninitialised value(s)
> ==16656== at 0x40022F2C: strlen (mac_replace_strmem.c:164)
> ==16656== by 0x4048F00D: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)
> ==16656== by 0x404A9F6B: _IO_vsprintf_internal (in /lib/libc-2.3.2.so)
> ==16656== by 0x404973CC: __GI_sprintf (in /lib/libc-2.3.2.so)
> ==16656==
> ==16656== 1 errors in context 2 of 2:
> ==16656== Conditional jump or move depends on uninitialised value(s)
> ==16656== at 0x40022F55: strcpy (mac_replace_strmem.c:173)
> ==16656== by 0x804B311: hdfconverter (hdfconverter.c:72)
> ==16656== by 0x804E4EF: Process8BitImages (sendbrowse.c:1436)
> ==16656== by 0x804C612: main (sendbrowse.c:343)
> ==16656== IN SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
>
> I've printed out outfile so there is data there.
> The data is way less than 100 characters.
>
>
> Not sure what I'm missing.
I think that if strlen(infile_backup) >= len then outfile will not
become null-terminated by the call to strncpy(), so you should add
outfile[len] = '\0' or similar. See the strncpy man page for details.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Tom H. <th...@cy...> - 2004-04-20 15:48:32
|
In message <loo...@po...>
Jim Amrhein <am...@ly...> wrote:
> The code :
>
>
> outfile = (char *)malloc(100);
>
> (void) strncpy (outfile, infile_backup,len);
>
> jfif_name = (char *) malloc(100);
>
> Line 72: (void) strcpy(jfif_name, outfile );
If len is more than 100 then this will fail as outfile won't be nul
terminated, and valgrind would be telling the truth.
> I've printed out outfile so there is data there.
> The data is way less than 100 characters.
But is len set correctly?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jim A. <am...@ly...> - 2004-04-20 15:30:14
|
Hi , I'm new to valgrind.
My setup :
Redhat 9
gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
Configured with: ./configure
Thread model: posix
gcc version 3.2.2
Valgrind version valgrind-2.0.0
The code :
outfile = (char *)malloc(100);
(void) strncpy (outfile, infile_backup,len);
jfif_name = (char *) malloc(100);
Line 72: (void) strcpy(jfif_name, outfile );
The errors:
==16656== 1 errors in context 1 of 2:
==16656== Conditional jump or move depends on uninitialised value(s)
==16656== at 0x40022F2C: strlen (mac_replace_strmem.c:164)
==16656== by 0x4048F00D: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)
==16656== by 0x404A9F6B: _IO_vsprintf_internal (in /lib/libc-2.3.2.so)
==16656== by 0x404973CC: __GI_sprintf (in /lib/libc-2.3.2.so)
==16656==
==16656== 1 errors in context 2 of 2:
==16656== Conditional jump or move depends on uninitialised value(s)
==16656== at 0x40022F55: strcpy (mac_replace_strmem.c:173)
==16656== by 0x804B311: hdfconverter (hdfconverter.c:72)
==16656== by 0x804E4EF: Process8BitImages (sendbrowse.c:1436)
==16656== by 0x804C612: main (sendbrowse.c:343)
==16656== IN SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
I've printed out outfile so there is data there.
The data is way less than 100 characters.
Not sure what I'm missing.
Thx in advance,
Jim
|