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
(9) |
2
(15) |
3
|
4
(5) |
5
(2) |
6
(7) |
|
7
(2) |
8
(2) |
9
(7) |
10
(3) |
11
(14) |
12
(4) |
13
|
|
14
(2) |
15
(2) |
16
(6) |
17
(6) |
18
(5) |
19
|
20
|
|
21
(2) |
22
(1) |
23
(4) |
24
(4) |
25
|
26
(1) |
27
(1) |
|
28
(4) |
29
(24) |
30
(4) |
|
|
|
|
|
From: Sinan Y. <asm...@ya...> - 2004-11-06 11:34:07
|
confirm 190754 ===== __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |
|
From: Tom H. <th...@cy...> - 2004-11-06 11:06:28
|
In message <200...@fr...>
Brad Hards <br...@fr...> wrote:
> I thought valgrind could do coverage testing, but a bit more research led
> me to believe that I need callgrind to do so.
I don't believe there is any valgrind tool for coverage testing at
the moment - it has been suggested but I don't think anybody has
written one. I don't think callgrind will help will it?
> At this stage, I can't make callgrind 0.9.9 configure against the current
> CVS (valgrind --version says valgrind-2.3.0.CVS).
I'd suggest sticking with 2.2.0 if you want to use callgrind. There
are a lot of changes going on in CVS at the moment so it's quite likely
that a third party tool like callgrind will have problems building
against it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Brad H. <br...@fr...> - 2004-11-06 00:44:43
|
I'm trying to do coverage testing for my unittests.
The target is Qt Cryptographic Architecture - it is a Qt based library that
supports plugins (essentially just more shared libraries). I'm most interes=
ted
in the plugins, although it is all (except for my unit test harness) of
interest in a coverage sense. All I really need is a post-run output for ea=
ch
line, like gcov produces.
I thought valgrind could do coverage testing, but a bit more research led me
to believe that I need callgrind to do so.=20
At this stage, I can't make callgrind 0.9.9 configure against the current
CVS (valgrind --version says valgrind-2.3.0.CVS).
The configure run ends with:
checking for valgrind installation... in /usr/local
checking if vg_skin.h is available... configure: error: No. Needs header fi=
les from Valgrind (2.0.x/2.2.x).
Perhaps a valgrind-dev package is missing in your installation?
The applicable part of config.log appears to be:
configure:3353: checking for valgrind installation
configure:3365: result: in /usr/local
configure:3387: checking if vg_skin.h is available
configure:3410: gcc -c -I /usr/local/include/valgrind conftest.c >&5
In file included from /usr/local/include/valgrind/vg_skin.h:3,
from conftest.c:19:
/usr/local/include/valgrind/tool.h:39:60: tool_arch.h: No such file or dire=
ctory
/usr/local/include/valgrind/tool.h:40:17: vki.h: No such file or directory
In file included from /usr/local/include/valgrind/vg_skin.h:3,
from conftest.c:19:
/usr/local/include/valgrind/tool.h: In function `main':
/usr/local/include/valgrind/tool.h:374: warning: `struct vki_rlimit' declar=
ed inside parameter list
/usr/local/include/valgrind/tool.h:374: warning: its scope is only this def=
inition or declaration, which is pr
obably not what you want
/usr/local/include/valgrind/tool.h:377: warning: `struct vki_rlimit' declar=
ed inside parameter list
/usr/local/include/valgrind/tool.h:441: warning: `struct vki_dirent' declar=
ed inside parameter list
I looked at /usr/local/include/valgrind/tool.h, and it contains:
#include "basic_types.h"
#include "tool_asm.h" // asm stuff
#include "tool_arch.h" // arch-specific tool stuff
#include "vki.h"
however it appears that tool_arch is in/usr/local/include/valgrind/x86/tool=
_arch.h
and vki.h is in /usr/local/include/valgrind/linux/vki.h
So I guess my questions are:
1. Do I need callgrind, or is there a Better Way?
2. If I need callgrind, how am I supposed to make it compile?
3. Does /usr/local/include/valgrind/tool.h make sense with those includes?
Brad
|
|
From: Robert W. <rj...@du...> - 2004-11-05 17:32:37
|
> Running such a program with the > environment variabel GLIBCPP_FORCE_NEW set (with gcc 3.x) also the > string implementation uses the slower new allocator. This will cause > valgrind to correctly report that in your case the memory is deleted > when s goes out of scope, and if you would after that use the pointer > from s.c_str() valgrind would also report the misuse there. Huh. Maybe Valgrind should set this variable for you by default, then? Perhaps with an option to turn it off. Regards, Robert. |
|
From: Dennis L. <pla...@tz...> - 2004-11-05 15:40:22
|
Am Donnerstag, den 04.11.2004, 16:26 +0100 schrieb Trond Valen:
> Hi!
>
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
The GNU string implementation uses some custom allocator pools for
strings, as this is also encouraged by ISO C++. Things are even worse if
you assing the s.c_str(); to something, and use it after s goes out of
scope, it often works, and valgrind does not notice the bug. In a
previous post I asked that this issue should be added to FAQ5, but it
seemed to be silently ignored. Running such a program with the
environment variabel GLIBCPP_FORCE_NEW set (with gcc 3.x) also the
string implementation uses the slower new allocator. This will cause
valgrind to correctly report that in your case the memory is deleted
when s goes out of scope, and if you would after that use the pointer
from s.c_str() valgrind would also report the misuse there.
greets
Dennis
--
Dennis Lubert <pla...@tz...>
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-11-04 17:00:15
|
> Hi!
>
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
See also item 4.3 in the Valgrind FAQ, file FAQ.txt in the top source
directory, for more information on these memory leaks in the C++ STL and
string classes.
Regards,
Jeroen.
|
|
From: Htin H. <hh...@ve...> - 2004-11-04 16:37:17
|
I think, string will internally allocate memory from heap with its
allocator and it might still cache the memory at the time when s is gone
out of scope..
Htin
> -----Original Message-----
> From: val...@li...
[mailto:valgrind-users-
> ad...@li...] On Behalf Of Trond Valen
> Sent: Thursday, November 04, 2004 7:26 AM
> To: val...@li...
> Subject: [Valgrind-users] Valgrind string bug?
>=20
> Hi!
>=20
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>=20
> #include <string>
> using namespace std;
>=20
> int main()
> {
> string s =3D "jklds";
> }
>=20
> This is not an actual mistake on my part, right? s will go out of
scope
> when main terminates, won't it?
>=20
> --
> Trond Valen
> NTNU student
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-04 16:19:09
|
On Thu, 4 Nov 2004, Trond Valen wrote:
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right?
It's not a bug by you or Valgrind. Underneath the shiny "string" surface,
glibc will have done one allocation.
> s will go out of scope when main terminates, won't it?
Yes, but it looks like glibc doesn't bother to free it. This is not a
problem. You don't need to worry about mismatches between the
allocs/frees counts, rather only the leaks that --leak-check=yes tells
you.
N
|
|
From: Tom H. <th...@cy...> - 2004-11-04 16:17:29
|
In message <109...@we...>
Trond Valen <va...@st...> wrote:
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
It will, yes. I believe what you are seeing is an artifact of the
pooled memory allocator that libstdc++ uses for string objects.
The result of that is that the memory is returned to an internal free
pool inside the string class and not to the main free pool. So as far
as valgrind is concerned it is still allocated.
If you use --leak-check=yes --show-reachable=yes then you should be
able to see that there is a block still allocated and that something
in libstdc++ has a handle to it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Trond V. <va...@st...> - 2004-11-04 15:26:25
|
Hi!
It seems that Valgrind has a bug concerning strings on the stack. This
simple example yields "1 allocs, 0 frees" using the command "valgrind
alloctest", where alloctest is the executable file of the example:
#include <string>
using namespace std;
int main()
{
string s =3D "jklds";
}
This is not an actual mistake on my part, right? s will go out of scope
when main terminates, won't it?
--
Trond Valen
NTNU student
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-02 19:10:54
|
On Tue, 2 Nov 2004, Tom Schutter wrote: >> I would like to script valgrind so that it runs nightly. I am interested >> to know how I know if valgrind found at least one bug in the executable >> it ran under. Is it supposed to return a non-zero value if at least one >> problem was found? > > I just checked our overnight build script which does this. We just use > "-quiet". Our smoke test program is designed to output nothing if it > finds no problems. That combined with the -quiet to valgrind means no > output at all if there are no problems. Or you can use the VALGRIND_COUNT_ERRORS client request in your test harness, as described in the manual. N |
|
From: Tom H. <th...@cy...> - 2004-11-02 18:33:21
|
In message <20041102172447.GC4165@white>
Bob Rossi <bo...@br...> wrote:
> Sorry for all the trouble.
>
> I just got past the infinate loop problem by updating to latest CVS.
> However, now I am getting this error,
>
> valgrind: ../../valgrind/coregrind/vg_signals.c:1983
> (vgPlain_route_signals): Assertion `tst->sigqueue_head !=
> tst->sigqueue_tail' failed.
> ==18905== at 0xB002B724: vgPlain_skin_assert_fail
> (../../valgrind/coregrind/vg_mylibc.c:1161)
That means you must have a thread with more than eight outstanding
signals which seems a bit strange.
Note that this is signals which are in the process of being delivered
so this is after signal block masks have been considered.
You should raise a bug for it anyway.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-02 17:25:03
|
Sorry for all the trouble. I just got past the infinate loop problem by updating to latest CVS. However, now I am getting this error, valgrind: ../../valgrind/coregrind/vg_signals.c:1983 (vgPlain_route_signals): Assertion `tst->sigqueue_head != tst->sigqueue_tail' failed. ==18905== at 0xB002B724: vgPlain_skin_assert_fail (../../valgrind/coregrind/vg_mylibc.c:1161) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==18905== at 0x49E722F0: sigprocmask (in /lib/i686/libc-2.2.5.so) ==18905== by 0x49E930D0: system (in /lib/i686/libc-2.2.5.so) ==18905== by 0x870E84A: platform__platform_specific__local_executeX (../.chop_Linux/platform-platform_specific.adb:263) ==18905== by 0x87258E7: platform__platform_specific__copy_fileX (../.chop_Linux/platform-platform_specific.adb:1427) Any help? Thanks, Bob Rossi |
|
From: Tom S. <to...@pl...> - 2004-11-02 16:53:50
|
On Tue, 2004-11-02 at 06:56, Bob Rossi wrote: > Hi, > > I would like to script valgrind so that it runs nightly. I am interested > to know how I know if valgrind found at least one bug in the executable > it ran under. Is it supposed to return a non-zero value if at least one > problem was found? I just checked our overnight build script which does this. We just use "-quiet". Our smoke test program is designed to output nothing if it finds no problems. That combined with the -quiet to valgrind means no output at all if there are no problems. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Naveen K. <g_n...@ya...> - 2004-11-02 16:06:35
|
Bob, I had suggested you try the "solution" I had put forward when you first mailed the list regarding this problem since my case was similar. http://sourceforge.net/mailarchive/message.php?msg_id=9681249 I fixed the "looping" as shown below(in link). Doesn't look like it is the same fix that Tom is talking about. http://sourceforge.net/mailarchive/message.php?msg_id=9532982 Anyway good to know that you have it fixed. Naveen --- Bob Rossi <bo...@br...> wrote: > On Mon, Nov 01, 2004 at 05:30:19PM +0000, Tom Hughes > wrote: > > In message <20041101170921.GD2460@white> > > Bob Rossi <bo...@br...> wrote: > > > > > I want to stop in the stabs reader. I just got > the translation unit and > > > see that the function name I think I want to > stop in > > > vgPlain_read_debuginfo_stabs. However, I > > > > > > 1. run 'valgrind --wait-for-gdb=yes > --tool=corecheck ./tmp/uut' > > > 2. gdb valgrind --pid=valgrind above > > > > That's wrong - it should be > /usr/lib/valgrind/stage2 as I wrote in > > my first message. > > Thanks Tom, > > I found the place where it is looping forever, it is > in vg_symtypes.c > line 416. > > Here is the backtrace. > > #0 vgPlain_st_basetype (type=0xb0201498, > do_resolve=0 '\0') at > vg_symtypes.c:41 > 7 > #1 0xb0037778 in initSym (si=0xb01e8020, > sym=0xb0200f58, kind=N_LSYM, > namep=0xb > fffeaa0, val=0) at vg_stabs.c:1095 > #2 0xb00382b0 in vgPlain_read_debuginfo_stabs > (si=0xb01e8020, > stabC=0xb02fbf20 > "\001", stab_sz=29508, stabstr=0xb0303264 "", > stabstr_sz=61536) at > vg_stabs.c:16 > 72 > > > Basically the typdef points to itself. > > $8 = (SymType *) 0xb0201430 > (tgdb) p type->u.t_typedef.type > $9 = (SymType *) 0xb0201430 > (tgdb) > > So, is the problem that the data > structure was populated the wrong way? Or can I look > at the actual > stabs data in the assembly file to see if it is > incorrect? > > Any suggestions on how to fix this? > > What about an assertion in the loop like below? > if ( type == type->u.t_typedef.type ) then > break; /* Error in symbol reading */ > > Thanks, > Bob Rossi > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for > FREE > LinuxWorld Reader's Choice Award Winner for best > database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |
|
From: Tom H. <th...@cy...> - 2004-11-02 14:45:54
|
In message <20041102135611.GB4165@white>
Bob Rossi <bo...@br...> wrote:
> I would like to script valgrind so that it runs nightly. I am interested
> to know how I know if valgrind found at least one bug in the executable
> it ran under. Is it supposed to return a non-zero value if at least one
> problem was found?
No. The exit status of valgrind is the exit status of the program that
you were running under valgrind so that it is transparent.
You need to grep the log file to do what you want.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-02 13:56:20
|
Hi, I would like to script valgrind so that it runs nightly. I am interested to know how I know if valgrind found at least one bug in the executable it ran under. Is it supposed to return a non-zero value if at least one problem was found? Thanks, Bob Rossi |
|
From: Bob R. <bo...@br...> - 2004-11-02 13:43:49
|
On Mon, Nov 01, 2004 at 05:22:53PM -0500, Bob Rossi wrote: > On Mon, Nov 01, 2004 at 08:14:45PM +0000, Tom Hughes wrote: > > In message <20041101185938.GE2460@white> > > Bob Rossi <bo...@br...> wrote: > > > > > > > > Thanks Tom, > > > > > > I found the place where it is looping forever, it is in vg_symtypes.c > > > line 416. > > > > > > Here is the backtrace. > > > > > > #0 vgPlain_st_basetype (type=0xb0201498, do_resolve=0 '\0') at > > > vg_symtypes.c:41 > > > 7 > > > #1 0xb0037778 in initSym (si=0xb01e8020, sym=0xb0200f58, kind=N_LSYM, > > > namep=0xb > > > fffeaa0, val=0) at vg_stabs.c:1095 > > > #2 0xb00382b0 in vgPlain_read_debuginfo_stabs (si=0xb01e8020, > > > stabC=0xb02fbf20 > > > "\001", stab_sz=29508, stabstr=0xb0303264 "", stabstr_sz=61536) at > > > vg_stabs.c:16 > > > 72 > > > > > > > > > Basically the typdef points to itself. > > > > > > $8 = (SymType *) 0xb0201430 > > > (tgdb) p type->u.t_typedef.type > > > $9 = (SymType *) 0xb0201430 > > > (tgdb) > > > > That looks suspiciously like the bug I fixed a few weeks ago. Are > > you using the CVS head or 2.2.0 here? > > I was using CVS from sometime around a few weeks ago :) > I'll do an update and try again. Hopefully it'll work ... Great, this works now, thanks! Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-11-02 09:50:55
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 2 Nov 2004, Tom Hughes wrote:
>
>> If you look a bit further up you'll see that it tried to generate
>> vg_toolint.h but failed because your perl is so prehistoric that it
>> doesn't have a warnings.pm module.
>
> In that case we should add that line that specifies which version of
> Perl is the minimum, to all our Perl scripts... I can't remember how
> you specify that, though, and I don't have my Perl book to hand...
It turns out that changing "use warnings" to -w is enough to get the
two scripts used for building valgrind working on 5.005_03 so I have
made that change. There is one script used in the tests which uses
other features from 5.6 so I have added "use 5.006" to that one.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-02 09:23:45
|
On Tue, 2 Nov 2004, Tom Hughes wrote: > If you look a bit further up you'll see that it tried to generate > vg_toolint.h but failed because your perl is so prehistoric that it > doesn't have a warnings.pm module. In that case we should add that line that specifies which version of Perl is the minimum, to all our Perl scripts... I can't remember how you specify that, though, and I don't have my Perl book to hand... N |
|
From: Tom H. <th...@cy...> - 2004-11-02 08:47:47
|
In message <IDE...@ge...>
Jim Su <ji...@ge...> wrote:
> I am new to the Valgrind.
> After I downloaded the latest Valgrind. I did configure then
> make. The make failed due to no vg_toolint.h file.
If you look a bit further up you'll see that it tried to generate
vg_toolint.h but failed because your perl is so prehistoric that it
doesn't have a warnings.pm module.
If you remove the "use warnings" line from that script then it may
work but there may be other things in the script that don't work on
such an old perl.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jim S. <ji...@ge...> - 2004-11-02 07:23:53
|
SGkgR3JlZXRpbmc6DQoNCiAgICBJIGFtIG5ldyB0byB0aGUgVmFsZ3JpbmQuDQogICAgQWZ0ZXIg SSBkb3dubG9hZGVkIHRoZSBsYXRlc3QgVmFsZ3JpbmQuIEkgZGlkIGNvbmZpZ3VyZSB0aGVuIG1h a2UuIFRoZSBtYWtlIGZhaWxlZCBkdWUgdG8gbm8gdmdfdG9vbGludC5oIGZpbGUuDQoNCiAgICBX aGF0IGlzIHRoZSByaWdodCBwcm9jZWR1cmUgdG8gbWFrZSBvdGhlciB0aGFuIHB1cmVseSBydW5u aW5nIHRoZSBjb25maWd1cmU/IElzIHRoZXJlIGFueSBvcHRpb24gc2V0dGluZyBmb3IgY29uZmln dXJlPw0KICAgIFRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIGtpbmRseSBoZWxwLg0KICAgICBU aGUgT1MgaXMgTGludXguIA0KICAgICBMaW51eCAgMi40LjIxLW10ZC4xDQoNClJlZ2FyZHMsDQpK aW0NCg0KKioqKioqKioqKioNCg0Kfi9qaW0vdG9vbHMvdmFsZ3JpbmQtMi4yLjAkIC4vY29uZmln dXJlDQpjaGVja2luZyBmb3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsLi4uIC91c3IvYmluL2lu c3RhbGwgLWMNCmNoZWNraW5nIHdoZXRoZXIgYnVpbGQgZW52aXJvbm1lbnQgaXMgc2FuZS4uLiB5 ZXMNCmNoZWNraW5nIGZvciBnYXdrLi4uIGdhd2sNCmNoZWNraW5nIHdoZXRoZXIgL3Vzci9iaW4v bWFrZSBzZXRzICQoTUFLRSkuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIHRvIGVuYWJsZSBtYWlu dGFpbmVyLXNwZWNpZmljIHBvcnRpb25zIG9mIE1ha2VmaWxlcy4uLiBubw0KY2hlY2tpbmcgd2hl dGhlciBsbiAtcyB3b3Jrcy4uLiB5ZXMNCmNoZWNraW5nIGZvciBnY2MuLi4gZ2NjDQpjaGVja2lu ZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUuLi4gYS5vdXQNCmNoZWNr aW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MuLi4geWVzDQpjaGVja2luZyB3aGV0aGVy IHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gbm8NCmNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhl Y3V0YWJsZXMuLi4gDQpjaGVja2luZyBmb3Igc3VmZml4IG9mIG9iamVjdCBmaWxlcy4uLiBvDQpj aGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4geWVzDQpj aGVja2luZyB3aGV0aGVyIGdjYyBhY2NlcHRzIC1nLi4uIHllcw0KY2hlY2tpbmcgZm9yIGdjYyBv cHRpb24gdG8gYWNjZXB0IEFOU0kgQy4uLiBub25lIG5lZWRlZA0KY2hlY2tpbmcgZm9yIHN0eWxl IG9mIGluY2x1ZGUgdXNlZCBieSAvdXNyL2Jpbi9tYWtlLi4uIEdOVQ0KY2hlY2tpbmcgZGVwZW5k ZW5jeSBzdHlsZSBvZiBnY2MuLi4gZ2NjDQpjaGVja2luZyBob3cgdG8gcnVuIHRoZSBDIHByZXBy b2Nlc3Nvci4uLiBnY2MgLUUNCmNoZWNraW5nIGZvciBnKysuLi4gZysrDQpjaGVja2luZyB3aGV0 aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMrKyBjb21waWxlci4uLiB5ZXMNCmNoZWNraW5nIHdo ZXRoZXIgZysrIGFjY2VwdHMgLWcuLi4geWVzDQpjaGVja2luZyBkZXBlbmRlbmN5IHN0eWxlIG9m IGcrKy4uLiBnY2MNCmNoZWNraW5nIGZvciByYW5saWIuLi4gcmFubGliDQpjaGVja2luZyBmb3Ig cGVybC4uLiAvdXNyL2Jpbi9wZXJsDQpjaGVja2luZyBmb3IgZ2RiLi4uIC91c3IvbG9jYWwvYmlu L2dkYg0KY2hlY2tpbmcgZm9yIGEgc3VwcG9ydGVkIHZlcnNpb24gb2YgZ2NjLi4uIG9rICgyLjk1 LjMpDQpjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZS4uLiBpNjg2LXBjLWxpbnV4DQpjaGVja2lu ZyBob3N0IHN5c3RlbSB0eXBlLi4uIGk2ODYtcGMtbGludXgNCmNoZWNraW5nIGZvciBhIHN1cHBv cnRlZCBDUFUuLi4gb2sgKGk2ODYpDQpjaGVja2luZyBmb3IgYSBzdXBwb3J0ZWQgT1MuLi4gb2sg KGxpbnV4KQ0KY2hlY2tpbmcgZm9yIHRoZSBrZXJuZWwgdmVyc2lvbi4uLiAyLjQgZmFtaWx5ICgy LjQuMjEtbXRkLjEpDQpjaGVja2luZyBmb3IgYSBzdXBwb3J0ZWQgQ1BVL09TIGNvbWJpbmF0aW9u Li4uIG9rIChpNjg2LWxpbnV4KQ0KY2hlY2tpbmcgZm9yIGVncmVwLi4uIGdyZXAgLUUNCmNoZWNr aW5nIHRoZSBnbGliYyB2ZXJzaW9uLi4uIDIuMSBmYW1pbHkNCmNoZWNraW5nIHdoZXRoZXIgc2No ZWRfcGFyYW0gaGFzIGEgc2NoZWRfcHJpb3JpdHkgbWVtYmVyLi4uIHllcw0KY2hlY2tpbmcgd2hl dGhlciBuZmRzX3QgaXMgZGVmaW5lZC4uLiBubw0KY2hlY2tpbmcgZm9yIFguLi4gbm8NCmNoZWNr aW5nIGlmIGdhcyBhY2NlcHRzIC5jZmkuLi4gbm8NCmNoZWNraW5nIGlmIGdjYyBhY2NlcHRzIC1t cHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5Li4uIHllcw0KY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFk ZXIgZmlsZXMuLi4geWVzDQpjaGVja2luZyBmb3Igc3lzL3R5cGVzLmguLi4geWVzDQpjaGVja2lu ZyBmb3Igc3lzL3N0YXQuaC4uLiB5ZXMNCmNoZWNraW5nIGZvciBzdGRsaWIuaC4uLiB5ZXMNCmNo ZWNraW5nIGZvciBzdHJpbmcuaC4uLiB5ZXMNCmNoZWNraW5nIGZvciBtZW1vcnkuaC4uLiB5ZXMN CmNoZWNraW5nIGZvciBzdHJpbmdzLmguLi4geWVzDQpjaGVja2luZyBmb3IgaW50dHlwZXMuaC4u LiB5ZXMNCmNoZWNraW5nIGZvciBzdGRpbnQuaC4uLiB5ZXMNCmNoZWNraW5nIGZvciB1bmlzdGQu aC4uLiB5ZXMNCmNoZWNraW5nIGZjbnRsLmggdXNhYmlsaXR5Li4uIHllcw0KY2hlY2tpbmcgZmNu dGwuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBmY250bC5oLi4uIHllcw0KY2hlY2tp bmcgZm9yIHN0ZGxpYi5oLi4uIChjYWNoZWQpIHllcw0KY2hlY2tpbmcgZm9yIHN0cmluZy5oLi4u IChjYWNoZWQpIHllcw0KY2hlY2tpbmcgc3lzL3NvY2tldC5oIHVzYWJpbGl0eS4uLiB5ZXMNCmNo ZWNraW5nIHN5cy9zb2NrZXQuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBzeXMvc29j a2V0LmguLi4geWVzDQpjaGVja2luZyBzeXMvc3RhdGZzLmggdXNhYmlsaXR5Li4uIHllcw0KY2hl Y2tpbmcgc3lzL3N0YXRmcy5oIHByZXNlbmNlLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN5cy9zdGF0 ZnMuaC4uLiB5ZXMNCmNoZWNraW5nIHN5cy90aW1lLmggdXNhYmlsaXR5Li4uIHllcw0KY2hlY2tp bmcgc3lzL3RpbWUuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBzeXMvdGltZS5oLi4u IHllcw0KY2hlY2tpbmcgc3lzL2VuZGlhbi5oIHVzYWJpbGl0eS4uLiBubw0KY2hlY2tpbmcgc3lz L2VuZGlhbi5oIHByZXNlbmNlLi4uIG5vDQpjaGVja2luZyBmb3Igc3lzL2VuZGlhbi5oLi4uIG5v DQpjaGVja2luZyBlbmRpYW4uaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyBlbmRpYW4uaCBw cmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBlbmRpYW4uaC4uLiB5ZXMNCmNoZWNraW5nIHRl cm1pb3MuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyB0ZXJtaW9zLmggcHJlc2VuY2UuLi4g eWVzDQpjaGVja2luZyBmb3IgdGVybWlvcy5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHVuaXN0ZC5o Li4uIChjYWNoZWQpIHllcw0KY2hlY2tpbmcgdXRpbWUuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVj a2luZyB1dGltZS5oIHByZXNlbmNlLi4uIHllcw0KY2hlY2tpbmcgZm9yIHV0aW1lLmguLi4geWVz DQpjaGVja2luZyBsaW51eC9mYi5oIHVzYWJpbGl0eS4uLiB5ZXMNCmNoZWNraW5nIGxpbnV4L2Zi LmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3IgbGludXgvZmIuaC4uLiB5ZXMNCmNoZWNr aW5nIG1xdWV1ZS5oIHVzYWJpbGl0eS4uLiBubw0KY2hlY2tpbmcgbXF1ZXVlLmggcHJlc2VuY2Uu Li4gbm8NCmNoZWNraW5nIGZvciBtcXVldWUuaC4uLiBubw0KY2hlY2tpbmcgbGludXgvY29tcGls ZXIuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyBsaW51eC9jb21waWxlci5oIHByZXNlbmNl Li4uIHllcw0KY2hlY2tpbmcgZm9yIGxpbnV4L2NvbXBpbGVyLmguLi4geWVzDQpjaGVja2luZyBm b3IgbGludXgvbWlpLmguLi4geWVzDQpjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgu Li4geWVzDQpjaGVja2luZyBmb3Igb2ZmX3QuLi4geWVzDQpjaGVja2luZyBmb3Igc2l6ZV90Li4u IHllcw0KY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5kIHN5cy90aW1lLmggbWF5IGJvdGggYmUg aW5jbHVkZWQuLi4geWVzDQpjaGVja2luZyBmb3IgX19wdGhyZWFkX3Vud2luZF9idWZfdC4uLiBu bw0KY2hlY2tpbmcgZm9yIHUxNi4uLiBubw0KY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWVtY21wLi4u IHllcw0KY2hlY2tpbmcgZm9yIHN0ZGxpYi5oLi4uIChjYWNoZWQpIHllcw0KY2hlY2tpbmcgZm9y IHVuaXN0ZC5oLi4uIChjYWNoZWQpIHllcw0KY2hlY2tpbmcgZm9yIGdldHBhZ2VzaXplLi4uIHll cw0KY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiB5ZXMNCmNoZWNraW5nIHJldHVybiB0eXBl IG9mIHNpZ25hbCBoYW5kbGVycy4uLiB2b2lkDQpjaGVja2luZyBmb3IgZmxvb3IuLi4gbm8NCmNo ZWNraW5nIGZvciBtZW1jaHIuLi4geWVzDQpjaGVja2luZyBmb3IgbWVtc2V0Li4uIHllcw0KY2hl Y2tpbmcgZm9yIG1rZGlyLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0cmNoci4uLiB5ZXMNCmNoZWNr aW5nIGZvciBzdHJkdXAuLi4geWVzDQpjaGVja2luZyBmb3Igc3RycGJyay4uLiB5ZXMNCmNoZWNr aW5nIGZvciBzdHJyY2hyLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0cnN0ci4uLiB5ZXMNCmNoZWNr aW5nIGZvciBzZW10aW1lZG9wLi4uIG5vDQpjb25maWd1cmU6IGNyZWF0aW5nIC4vY29uZmlnLnN0 YXR1cw0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNy ZWF0aW5nIHZhbGdyaW5kLnNwZWMNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIHZhbGdyaW5kLnBj DQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBkb2NzL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBj cmVhdGluZyB0ZXN0cy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgdGVzdHMvdmdf cmVndGVzdA0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgdGVzdHMvdW51c2VkL01ha2VmaWxlDQpj b25maWcuc3RhdHVzOiBjcmVhdGluZyBpbmNsdWRlL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBj cmVhdGluZyBhdXhwcm9ncy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgY29yZWdy aW5kL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBjb3JlZ3JpbmQvZGVtYW5nbGUv TWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGNvcmVncmluZC9kb2NzL01ha2VmaWxl DQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBjb3JlZ3JpbmQveDg2L01ha2VmaWxlDQpjb25maWcu c3RhdHVzOiBjcmVhdGluZyBhZGRyY2hlY2svTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0 aW5nIGFkZHJjaGVjay90ZXN0cy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgYWRk cmNoZWNrL2RvY3MvTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIG1lbWNoZWNrL01h a2VmaWxlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBtZW1jaGVjay90ZXN0cy9NYWtlZmlsZQ0K Y29uZmlnLnN0YXR1czogY3JlYXRpbmcgbWVtY2hlY2svZG9jcy9NYWtlZmlsZQ0KY29uZmlnLnN0 YXR1czogY3JlYXRpbmcgY2FjaGVncmluZC9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRp bmcgY2FjaGVncmluZC90ZXN0cy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgY2Fj aGVncmluZC9kb2NzL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBjYWNoZWdyaW5k L2NnX2Fubm90YXRlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBoZWxncmluZC9NYWtlZmlsZQ0K Y29uZmlnLnN0YXR1czogY3JlYXRpbmcgaGVsZ3JpbmQvdGVzdHMvTWFrZWZpbGUNCmNvbmZpZy5z dGF0dXM6IGNyZWF0aW5nIGhlbGdyaW5kL2RvY3MvTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNy ZWF0aW5nIG1hc3NpZi9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgbWFzc2lmL2hw MnBzL01ha2VmaWxlDQpjb25maWcuc3RhdHVzOiBjcmVhdGluZyBtYXNzaWYvdGVzdHMvTWFrZWZp bGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIG1hc3NpZi9kb2NzL01ha2VmaWxlDQpjb25maWcu c3RhdHVzOiBjcmVhdGluZyBjb3JlY2hlY2svTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0 aW5nIGNvcmVjaGVjay90ZXN0cy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgY29y ZWNoZWNrL2RvY3MvTWFrZWZpbGUNCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIGxhY2tleS9NYWtl ZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgbGFja2V5L3Rlc3RzL01ha2VmaWxlDQpjb25m aWcuc3RhdHVzOiBjcmVhdGluZyBsYWNrZXkvZG9jcy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czog Y3JlYXRpbmcgbm9uZS9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgbm9uZS90ZXN0 cy9NYWtlZmlsZQ0KY29uZmlnLnN0YXR1czogY3JlYXRpbmcgbm9uZS9kb2NzL01ha2VmaWxlDQpj b25maWcuc3RhdHVzOiBjcmVhdGluZyBjb25maWcuaA0KY29uZmlnLnN0YXR1czogZXhlY3V0aW5n IGRlcGZpbGVzIGNvbW1hbmRzDQoNClVzaW5nIHRoZSBmb2xsb3dpbmcgc3VwcHJlc3Npb25zIGJ5 IGRlZmF1bHQ6DQoNCiAgICAgICBnbGliYy0yLjEuc3VwcA0KZ2VuaWVAR01TUy02MCB+L2ppbS90 b29scy92YWxncmluZC0yLjIuMCQgbWFrZQ0KL3Vzci9iaW4vbWFrZSAgYWxsLXJlY3Vyc2l2ZQ0K bWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL2hvbWUvZ2VuaWUvamltL3Rvb2xzL3Zh bGdyaW5kLTIuMi4wJw0KTWFraW5nIGFsbCBpbiBpbmNsdWRlDQptYWtlWzJdOiBFbnRlcmluZyBk aXJlY3RvcnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFsZ3JpbmQtMi4yLjAvaW5jbHVk ZScNCi91c3IvYmluL21ha2UgIGFsbC1hbQ0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAv dXNyL2hvbWUvZ2VuaWUvamltL3Rvb2xzL3ZhbGdyaW5kLTIuMi4wL2luY2x1ZGUnDQptYWtlWzNd OiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGwtYW0nLg0KbWFrZVszXTogTGVhdmluZyBkaXJl Y3RvcnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFsZ3JpbmQtMi4yLjAvaW5jbHVkZScN Cm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL2hvbWUvZ2VuaWUvamltL3Rvb2xzL3Zh bGdyaW5kLTIuMi4wL2luY2x1ZGUnDQpNYWtpbmcgYWxsIGluIGNvcmVncmluZA0KbWFrZVsyXTog RW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL2hvbWUvZ2VuaWUvamltL3Rvb2xzL3ZhbGdyaW5kLTIu Mi4wL2NvcmVncmluZCcNCnJtIC1mIHZnX3Rvb2xpbnQuYw0KL3Vzci9iaW4vcGVybCAuL2dlbl90 b29saW50LnBsIGNhbGx3cmFwICAgICA8IC4vdG9vbGZ1bmNzLmRlZiA+ICB2Z190b29saW50LmMg fHwgcm0gLWYgdmdfdG9vbGludC5jDQpDYW4ndCBsb2NhdGUgd2FybmluZ3MucG0gaW4gQElOQyAo QElOQyBjb250YWluczogL3Vzci9saWIvcGVybDUvNS4wMDUwMy9pNTg2LWxpbnV4IC91c3IvbGli L3Blcmw1LzUuMDA1MDMgL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuMDA1L2k1ODYtbGludXgg L3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuMDA1IC4pIGF0IC4vZ2VuX3Rvb2xpbnQucGwgbGlu ZSAyNy4NCkJFR0lOIGZhaWxlZC0tY29tcGlsYXRpb24gYWJvcnRlZCBhdCAuL2dlbl90b29saW50 LnBsIGxpbmUgMjcuDQovdXNyL2Jpbi9wZXJsIC4vZ2VuX3Rvb2xpbnQucGwgbWlzc2luZ2Z1bmNz IDwgLi90b29sZnVuY3MuZGVmID4+IHZnX3Rvb2xpbnQuYyB8fCBybSAtZiB2Z190b29saW50LmMN CkNhbid0IGxvY2F0ZSB3YXJuaW5ncy5wbSBpbiBASU5DIChASU5DIGNvbnRhaW5zOiAvdXNyL2xp Yi9wZXJsNS81LjAwNTAzL2k1ODYtbGludXggL3Vzci9saWIvcGVybDUvNS4wMDUwMyAvdXNyL2xp Yi9wZXJsNS9zaXRlX3BlcmwvNS4wMDUvaTU4Ni1saW51eCAvdXNyL2xpYi9wZXJsNS9zaXRlX3Bl cmwvNS4wMDUgLikgYXQgLi9nZW5fdG9vbGludC5wbCBsaW5lIDI3Lg0KQkVHSU4gZmFpbGVkLS1j b21waWxhdGlvbiBhYm9ydGVkIGF0IC4vZ2VuX3Rvb2xpbnQucGwgbGluZSAyNy4NCi91c3IvYmlu L3BlcmwgLi9nZW5fdG9vbGludC5wbCBpbml0ZnVuYyAgICAgPCAuL3Rvb2xmdW5jcy5kZWYgPj4g dmdfdG9vbGludC5jIHx8IHJtIC1mIHZnX3Rvb2xpbnQuYw0KQ2FuJ3QgbG9jYXRlIHdhcm5pbmdz LnBtIGluIEBJTkMgKEBJTkMgY29udGFpbnM6IC91c3IvbGliL3Blcmw1LzUuMDA1MDMvaTU4Ni1s aW51eCAvdXNyL2xpYi9wZXJsNS81LjAwNTAzIC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjAw NS9pNTg2LWxpbnV4IC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjAwNSAuKSBhdCAuL2dlbl90 b29saW50LnBsIGxpbmUgMjcuDQpCRUdJTiBmYWlsZWQtLWNvbXBpbGF0aW9uIGFib3J0ZWQgYXQg Li9nZW5fdG9vbGludC5wbCBsaW5lIDI3Lg0KL3Vzci9iaW4vcGVybCAuL2dlbl90b29saW50LnBs IGluaXRkbHN5bSAgICA8IC4vdG9vbGZ1bmNzLmRlZiA+PiB2Z190b29saW50LmMgfHwgcm0gLWYg dmdfdG9vbGludC5jDQpDYW4ndCBsb2NhdGUgd2FybmluZ3MucG0gaW4gQElOQyAoQElOQyBjb250 YWluczogL3Vzci9saWIvcGVybDUvNS4wMDUwMy9pNTg2LWxpbnV4IC91c3IvbGliL3Blcmw1LzUu MDA1MDMgL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuMDA1L2k1ODYtbGludXggL3Vzci9saWIv cGVybDUvc2l0ZV9wZXJsLzUuMDA1IC4pIGF0IC4vZ2VuX3Rvb2xpbnQucGwgbGluZSAyNy4NCkJF R0lOIGZhaWxlZC0tY29tcGlsYXRpb24gYWJvcnRlZCBhdCAuL2dlbl90b29saW50LnBsIGxpbmUg MjcuDQovdXNyL2Jpbi9wZXJsIC4vZ2VuX3Rvb2xpbnQucGwgc3RydWN0ZGVmICAgIDwgLi90b29s ZnVuY3MuZGVmID4+IHZnX3Rvb2xpbnQuYyB8fCBybSAtZiB2Z190b29saW50LmMNCkNhbid0IGxv Y2F0ZSB3YXJuaW5ncy5wbSBpbiBASU5DIChASU5DIGNvbnRhaW5zOiAvdXNyL2xpYi9wZXJsNS81 LjAwNTAzL2k1ODYtbGludXggL3Vzci9saWIvcGVybDUvNS4wMDUwMyAvdXNyL2xpYi9wZXJsNS9z aXRlX3BlcmwvNS4wMDUvaTU4Ni1saW51eCAvdXNyL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS4wMDUg LikgYXQgLi9nZW5fdG9vbGludC5wbCBsaW5lIDI3Lg0KQkVHSU4gZmFpbGVkLS1jb21waWxhdGlv biBhYm9ydGVkIGF0IC4vZ2VuX3Rvb2xpbnQucGwgbGluZSAyNy4NCnJtIC1mIHZnX3Rvb2xpbnQu aA0KL3Vzci9iaW4vcGVybCAuL2dlbl90b29saW50LnBsIHByb3RvICA8IC4vdG9vbGZ1bmNzLmRl ZiA+ICB2Z190b29saW50LmggfHwgcm0gLWYgdmdfdG9vbGludC5oDQpDYW4ndCBsb2NhdGUgd2Fy bmluZ3MucG0gaW4gQElOQyAoQElOQyBjb250YWluczogL3Vzci9saWIvcGVybDUvNS4wMDUwMy9p NTg2LWxpbnV4IC91c3IvbGliL3Blcmw1LzUuMDA1MDMgL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJs LzUuMDA1L2k1ODYtbGludXggL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuMDA1IC4pIGF0IC4v Z2VuX3Rvb2xpbnQucGwgbGluZSAyNy4NCkJFR0lOIGZhaWxlZC0tY29tcGlsYXRpb24gYWJvcnRl ZCBhdCAuL2dlbl90b29saW50LnBsIGxpbmUgMjcuDQovdXNyL2Jpbi9wZXJsIC4vZ2VuX3Rvb2xp bnQucGwgc3RydWN0IDwgLi90b29sZnVuY3MuZGVmID4+IHZnX3Rvb2xpbnQuaCB8fCBybSAtZiB2 Z190b29saW50LmgNCkNhbid0IGxvY2F0ZSB3YXJuaW5ncy5wbSBpbiBASU5DIChASU5DIGNvbnRh aW5zOiAvdXNyL2xpYi9wZXJsNS81LjAwNTAzL2k1ODYtbGludXggL3Vzci9saWIvcGVybDUvNS4w MDUwMyAvdXNyL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS4wMDUvaTU4Ni1saW51eCAvdXNyL2xpYi9w ZXJsNS9zaXRlX3BlcmwvNS4wMDUgLikgYXQgLi9nZW5fdG9vbGludC5wbCBsaW5lIDI3Lg0KQkVH SU4gZmFpbGVkLS1jb21waWxhdGlvbiBhYm9ydGVkIGF0IC4vZ2VuX3Rvb2xpbnQucGwgbGluZSAy Ny4NCi91c3IvYmluL21ha2UgIGFsbC1yZWN1cnNpdmUNCm1ha2VbM106IEVudGVyaW5nIGRpcmVj dG9yeSBgL3Vzci9ob21lL2dlbmllL2ppbS90b29scy92YWxncmluZC0yLjIuMC9jb3JlZ3JpbmQn DQpNYWtpbmcgYWxsIGluIHg4Ng0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL2hv bWUvZ2VuaWUvamltL3Rvb2xzL3ZhbGdyaW5kLTIuMi4wL2NvcmVncmluZC94ODYnDQpnY2MgLVds LC0tdmVyYm9zZSAtbm9zdGRsaWIgMj4mMSB8IHNlZCBcDQogICAgICAgIC1lICcxLC9ePT09PT1c KyQvZCcgXA0KICAgICAgICAtZSAnL149PT09PVwrJC9kJyBcDQogICAgICAgIC1lICdzL0VOVFJZ KF9zdGFydCkvRU5UUlkoX3VtZV9lbnRyeSkvJyBcDQogICAgICAgIC1lICdzLzB4MDgwNDgwMDAv a2lja3N0YXJ0X2Jhc2UvZycgPiBzdGFnZTIubGRzIHx8IHJtIC1mIHN0YWdlMi5sZHMNCi91c3Iv YmluL21ha2UgIGFsbC1hbQ0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL2hvbWUv Z2VuaWUvamltL3Rvb2xzL3ZhbGdyaW5kLTIuMi4wL2NvcmVncmluZC94ODYnDQptYWtlWzVdOiBO b3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGwtYW0nLg0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3Rv cnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFsZ3JpbmQtMi4yLjAvY29yZWdyaW5kL3g4 NicNCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL2hvbWUvZ2VuaWUvamltL3Rvb2xz L3ZhbGdyaW5kLTIuMi4wL2NvcmVncmluZC94ODYnDQpNYWtpbmcgYWxsIGluIGRlbWFuZ2xlDQpt YWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFs Z3JpbmQtMi4yLjAvY29yZWdyaW5kL2RlbWFuZ2xlJw0Kc291cmNlPSdjcC1kZW1hbmdsZS5jJyBv YmplY3Q9J2NwLWRlbWFuZ2xlLm8nIGxpYnRvb2w9bm8gXA0KZGVwZmlsZT0nLmRlcHMvY3AtZGVt YW5nbGUuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2NwLWRlbWFuZ2xlLlRQbycgXA0KZGVwbW9kZT1n Y2MgL2Jpbi9zaCAuLi8uLi9kZXBjb21wIFwNCmdjYyAtREhBVkVfQ09ORklHX0ggLUkuIC1JLiAt SS4uLy4uICAtSS4uLy4uL2NvcmVncmluZCAtSS4uLy4uL2NvcmVncmluZCAtSS4uLy4uL2luY2x1 ZGUgLUkuLi8uLi9pbmNsdWRlICAgLVdpbmxpbmUgLVdhbGwgLVdzaGFkb3cgLU8gLWZvbWl0LWZy YW1lLXBvaW50ZXIgLWcgIC1Xbm8tdW51c2VkIC1Xbm8tc2hhZG93ICAtYyBjcC1kZW1hbmdsZS5j DQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gY3AtZGVtYW5nbGUuYzo0MzoNCi4uLy4uL2NvcmVncmlu ZC92Z19pbmNsdWRlLmg6MzMwOiB2Z190b29saW50Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkNCm1ha2VbNF06ICoqKiBbY3AtZGVtYW5nbGUub10gRXJyb3IgMQ0KbWFrZVs0XTogTGVhdmlu ZyBkaXJlY3RvcnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFsZ3JpbmQtMi4yLjAvY29y ZWdyaW5kL2RlbWFuZ2xlJw0KbWFrZVszXTogKioqIFthbGwtcmVjdXJzaXZlXSBFcnJvciAxDQpt YWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9ob21lL2dlbmllL2ppbS90b29scy92YWxn cmluZC0yLjIuMC9jb3JlZ3JpbmQnDQptYWtlWzJdOiAqKiogW2FsbF0gRXJyb3IgMg0KbWFrZVsy XTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3IvaG9tZS9nZW5pZS9qaW0vdG9vbHMvdmFsZ3JpbmQt Mi4yLjAvY29yZWdyaW5kJw0KbWFrZVsxXTogKioqIFthbGwtcmVjdXJzaXZlXSBFcnJvciAxDQpt YWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9ob21lL2dlbmllL2ppbS90b29scy92YWxn cmluZC0yLjIuMCcNCm1ha2U6ICoqKiBbYWxsXSBFcnJvciAy |
|
From: Nick R. <ni...@sn...> - 2004-11-02 05:34:31
|
> I am exploring the use of Valgrind in my project. I would like to invoke > gdb within Xemacs, when prompted by Valgrind. Does anyone know how to do > it? Xemacs give nicer interface when going through the source files. Below is something similar to what I intended add to the Emacs manual, but didn't because there didn't seem to be much interest. You can also find an earlier reference at http://emacro.sourceforge.net/en/tips.html but the instructions below are probably better. For M-x gdba you need the CVS version of Emacs at Savannah but M-x gdb should work for XEmacs too. Nick Valgrind is a tool to help you find memory-management problems in GNU/Linux-x86 executables. If your program does not require user input, you can run valgrind in the `*compilation*' buffer where you can visit the source code for any particular memory error message in the normal way. If your program requires user input, or if you wish to attach to GDB, then this can be done in the GUD buffer by typing M-x gdb or M-x gdba and replacing the default input (e.g gdb -fullname) as shown: Run gdb (like this): valgrind --gdb-attach=yes ~/myprog At a memory violation, valgrind asks if you want to attach to gdb. If you type "y", then at GDB's prompt, type "set ann 1", if you want the mode for M-x gdb, or "set ann 3", if you want the mode for M-x gdba. In the first case, nothing happens immediately. In the second case, the main routine appears in the source buffer and the resulting layout depends on the value of gdb-many-windows. If you now type "bt" in the GUD buffer, GDB prints the call stack. This also includes calls to valgrind's code. Identify the frame number of your code, six say, and type "frame 6" in the GUD buffer. The source code for this call should appear in another buffer in both cases. As with operation from the command line, you can't step through your code when it is run through valgrind. However you can move up and down the stack and examine the values of variables. When you want to return control to valgrind type `C-d' to quit GDB but stay in the GUD buffer. |
|
From: prasad <pg...@ma...> - 2004-11-02 05:07:07
|
Hi=0D
I am using kernel 2.4 and gcc 2.96
=0D
I get the above messages immediately after starting valgrind.
This bug has already posted on th list but I didn't find any=
solution=0D
Does anybody knows abt it.
Prasad Gore
*********************************************************
Disclaimer: =0D
This message (including any attachments) contains=0D
confidential information intended for a specific=0D
individual and purpose, and is protected by law.=0D
If you are not the intended recipient, you should=0D
delete this message and are hereby notified that=0D
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,=0D
is strictly prohibited.
*********************************************************
Visit us at http://www.mahindrabt.com
|
|
From: prasad <pg...@ma...> - 2004-11-02 04:50:07
|
Hi all,
I am getting message=0D
@@ unlikely looking definition in unparsed remains ";"
=0D
Immediately after it starts.
This bug has already reported but I didn't find any fix for it.
I am using kernel 2.4 and gcc 2.96 version.
=0D
Does anybody knows the wayout to get rid of this problem.
=0D
Prasad Gore.
*********************************************************
Disclaimer: =0D
This message (including any attachments) contains=0D
confidential information intended for a specific=0D
individual and purpose, and is protected by law.=0D
If you are not the intended recipient, you should=0D
delete this message and are hereby notified that=0D
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,=0D
is strictly prohibited.
*********************************************************
Visit us at http://www.mahindrabt.com
|