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
(4) |
|
2
|
3
(1) |
4
|
5
(2) |
6
(1) |
7
(3) |
8
(1) |
|
9
|
10
(9) |
11
(9) |
12
(10) |
13
(2) |
14
|
15
|
|
16
(1) |
17
(9) |
18
(5) |
19
(17) |
20
|
21
(5) |
22
|
|
23
|
24
(17) |
25
(8) |
26
(7) |
27
(10) |
28
(11) |
29
(1) |
|
30
|
31
(6) |
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2005-01-19 08:38:14
|
In message <200...@sm...>
woo...@co... wrote:
> The error is believed to be caused by writing to an output
> address. This is allowed to root when properly registered with the
> kernel (which it is). Is it possible to disable this type of error
> message or have valgrind accept the same registration?
It isn't a question of disabling any message - your program is
using an instruction which valgrind doesn't understand. Please
file a bug so that we can look at adding support for this instruction.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <oli...@on...> - 2005-01-19 08:24:09
|
I apologize. There was nothing wrong with the source at all. It seems the machine I tried it on has some issues, because I did try it on another one and everything worked fine. Sorry for sending all those messages. But using the CVS I recognised something. I got a multithreaded app, that issues some warnings, but the warnings caused by a different thread than the main thread in a shared object doesn't have any stack trace anymore. I just get the line, where the error is and the whole call stack is missing. |
|
From: Bryan O'S. <bo...@se...> - 2005-01-19 07:44:57
|
On Tue, 2005-01-18 at 17:00 -0800, Wayne Christopher wrote: > I know that valgrind will not run (yet) on the Opteron in 64-bit mode. > But I am trying to compile it on a SuSE 9.1 machine as a 32-bit > executable. I tried (after some trial and error): > > ./configure --build=ix86-pc-linux > make CFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS=-m32 > > but I still get errors about 64-bit libraries contaminating the links. > Before I delve any deeper into the makefiles, has anybody gotten this to > work, or is there a reason it's impossible? I don't think anyone has tried. It is not possible (without moderate to severe pain) to build some 32-bit programs on Opteron machines running 64-bit distros due to include file conflicts that preclude installing the 32-bit devel packages. Whether or not this is the case for valgrind remains to be seen. By the way, you should be passing the CFLAGS and friends to configure, not to make. <b |
|
From: <woo...@co...> - 2005-01-19 05:50:02
|
In attempting to use valgrind against the TOCNET32 program,
the following
error occurs:
==1533==
disInstr: unhandled instruction bytes: 0xFA 0x83 0xEC 0x8
at 0x8094F1F: Dsp2187::DataMemRead(unsigned
short, unsigned short,
int, unsigned short *) (./source/dsp2187.cpp:444)
==1533==
==1533== Process terminating with default action of signal
4 (SIGILL)
==1533== Illegal operand at address 0xB0022670
==1533== at 0x8094F1F: Dsp2187::DataMemRead(unsigned
short, unsigned short,
int, unsigned short *) (./source/dsp2187.cpp:444)
==1533== by 0x8095CCC: Dsp2187::ChkWdTimer(void)
(./source/dsp2187.cpp:982)
==1533== by 0x80947E1: Dsp2187::Dsp2187(unsigned short,
unsigned short,
char) (./source/dsp2187.cpp:133)
==1533== by 0x80F60D9: TocSystem::TocSystem(void)
(./source/tocsys.cpp:843)
==1533==
The error is believed to be caused by writing to an output
address. This is
allowed to root when properly registered with the kernel
(which it is). Is it
possible to disable this type of error message or have
valgrind accept the
same registration?
|
|
From: Nicholas N. <nj...@ca...> - 2005-01-19 04:10:01
|
On Tue, 18 Jan 2005, Wayne Christopher wrote: > I know that valgrind will not run (yet) on the Opteron in 64-bit mode. But I > am trying to compile it on a SuSE 9.1 machine as a 32-bit executable. I > tried (after some trial and error): > > ./configure --build=ix86-pc-linux > make CFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS=-m32 > > but I still get errors about 64-bit libraries contaminating the links. Before > I delve any deeper into the makefiles, has anybody gotten this to work, or is > there a reason it's impossible? I've never tried that, but I have had success with running 32-bit programs under a 32-bit Valgrind (built on a 32-bit machine) on a 64-bit machine. I can't remember if 2.1.2 could do that, if not, try the latest CVS version. N |
|
From: Wayne C. <wa...@4r...> - 2005-01-19 01:03:49
|
I know that valgrind will not run (yet) on the Opteron in 64-bit mode. But I am trying to compile it on a SuSE 9.1 machine as a 32-bit executable. I tried (after some trial and error): ./configure --build=ix86-pc-linux make CFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS=-m32 but I still get errors about 64-bit libraries contaminating the links. Before I delve any deeper into the makefiles, has anybody gotten this to work, or is there a reason it's impossible? Thanks, Wayne |
|
From: Paul P. <ppl...@gm...> - 2005-01-19 00:43:56
|
On Tue, 18 Jan 2005 17:48:52 +0100, Andreas Andersen <and...@da...> wrote: > I just recently discovered a bug and from what I can see it looks like > some kind of memory problem. However, when I run it through valgrind no > errors are reported and the bug seems to be gone! There are a couple of likely explanations. If your program is multi-threaded; it is quite likely that VG changes timing or simply hides the race condition that caused corruption (your executable runs on a *single* synthetic CPU, so a whole class of SMP races "hides" under VG). If your program uses signal handlers, and especially if it calls malloc() from within async signal handler, VG might mask this. It appears that VG2.2 does not report such errors. It could be that your program uses uninitialized value, and you've either suppressed or ignored it in VG output. Finally, it could be that your program corrupts its state through a pointer that happens to point into something valid but un-important iwhen under VG, and something important when not under VG (the memory layout of the process changes under VG). Cheers, |
|
From: Chris S. <c.s...@co...> - 2005-01-18 22:13:50
|
On Tue, Jan 18, 2005 at 05:48:52PM +0100, Andreas Andersen wrote: > Hi > > I have been using valgrind to debug a program I have written in C++ and > it has been very helpful in eliminating memory errors/leaks. However, I > just recently discovered a bug and from what I can see it looks like > some kind of memory problem. However, when I run it through valgrind no > errors are reported and the bug seems to be gone! I print some status > from the program and at some point this becomes wrong but when the > program is run through valgrind the status printed is right! > > How can valgrind change the output of my program and does this behaviour > give any clues as to what kind of bug I am looking for? > Well, I've noticed that valgrind can continue through a double-free bug, when the program would crash without valgrind. But valgrind reports the error, so that's probably not your case. -chris |
|
From: David E. <tw...@us...> - 2005-01-18 18:02:31
|
On Tue, 2005-01-18 at 17:48 +0100, Andreas Andersen wrote:
> Hi
>
> I have been using valgrind to debug a program I have written in C++ and
> it has been very helpful in eliminating memory errors/leaks. However, I
> just recently discovered a bug and from what I can see it looks like
> some kind of memory problem. However, when I run it through valgrind no
> errors are reported and the bug seems to be gone! I print some status
> from the program and at some point this becomes wrong but when the
> program is run through valgrind the status printed is right!
>
> How can valgrind change the output of my program and does this behaviour
> give any clues as to what kind of bug I am looking for?
Stack corruption.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
|
|
From: Andreas A. <and...@da...> - 2005-01-18 16:49:15
|
Hi I have been using valgrind to debug a program I have written in C++ and it has been very helpful in eliminating memory errors/leaks. However, I just recently discovered a bug and from what I can see it looks like some kind of memory problem. However, when I run it through valgrind no errors are reported and the bug seems to be gone! I print some status from the program and at some point this becomes wrong but when the program is run through valgrind the status printed is right! How can valgrind change the output of my program and does this behaviour give any clues as to what kind of bug I am looking for? /Andreas |
|
From: Olly B. <ol...@su...> - 2005-01-18 01:36:57
|
On 2005-01-17, Olly Betts <ol...@su...> wrote:
> Here's a patch against CVS HEAD:
Hmm actually, it's against CVS HEAD for the old valgrind CVS on
sourceforge. But it should be obvious how to apply it.
Cheers,
Olly
|
|
From: Tom H. <th...@cy...> - 2005-01-18 00:17:32
|
In message <slrncuntgf.eau.olly@roadkill.localnet>
Olly Betts <ol...@su...> wrote:
> Here's a patch against CVS HEAD:
>
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/valgrind/valgrind/configure.in,v
> retrieving revision 1.97
> diff -p -u -r1.97 configure.in
> --- configure.in 18 Oct 2003 14:05:42 -0000 1.97
> +++ configure.in 17 Jan 2005 17:24:43 -0000
> @@ -1,4 +1,5 @@
> # Process this file with autoconf to produce a configure script.
> +AC_PREREQ(2.59)
> AC_INIT(coregrind/vg_main.c) # give me a source file, any source file...
> AM_CONFIG_HEADER(config.h)
> AM_INIT_AUTOMAKE(valgrind, 20030725)
>
> With this patch in place, you'll get an error like this if your autoconf
> is too old (this is what 2.53 says):
Thanks for that. I've committed it now.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <oli...@on...> - 2005-01-17 18:24:09
|
OK, I got further this time. The perl script seems to create invalid
files. At least a invalid vg_toolint.h. (Note: I am using perl 5.8.0)
I am getting the following error:
In file included from ../../coregrind/core.h:379,
from signal.c:31:
../../coregrind/vg_toolint.h:509: parse error before "_post_clo_init"
../../coregrind/vg_toolint.h:509: warning: no semicolon at end of struct
or union
../../coregrind/vg_toolint.h:518: parse error before "_instrument"
../../coregrind/vg_toolint.h:526: parse error before "_fini"
../../coregrind/vg_toolint.h:546: parse error before "_eq_SkinError"
../../coregrind/vg_toolint.h:552: parse error before "_pp_SkinError"
../../coregrind/vg_toolint.h:564: parse error before "_update_extra"
../../coregrind/vg_toolint.h:571: parse error before
"_recognised_suppression"
../../coregrind/vg_toolint.h:580: parse error before
"_read_extra_suppression_info"
../../coregrind/vg_toolint.h:588: parse error before
"_error_matches_suppression"
../../coregrind/vg_toolint.h:596: parse error before "_get_error_name"
../../coregrind/vg_toolint.h:604: parse error before
"_print_extra_suppression_info"
../../coregrind/vg_toolint.h:615: parse error before
"_discard_basic_block_info"
../../coregrind/vg_toolint.h:632: parse error before
"_process_cmd_line_option"
../../coregrind/vg_toolint.h:638: parse error before "_print_usage"
../../coregrind/vg_toolint.h:644: parse error before
"_print_debug_usage"
../../coregrind/vg_toolint.h:663: parse error before
"_handle_client_request"
../../coregrind/vg_toolint.h:673: parse error before "_get_Xreg_usage"
../../coregrind/vg_toolint.h:676: parse error before "_emit_XUInstr"
../../coregrind/vg_toolint.h:679: parse error before "_sane_XUInstr"
../../coregrind/vg_toolint.h:682: parse error before "_name_XUOpcode"
../../coregrind/vg_toolint.h:685: parse error before "_pp_XUInstr"
../../coregrind/vg_toolint.h:697: parse error before "_pre_syscall"
../../coregrind/vg_toolint.h:700: parse error before "_post_syscall"
../../coregrind/vg_toolint.h:712: parse error before
"_cheap_sanity_check"
../../coregrind/vg_toolint.h:715: parse error before
"_expensive_sanity_check"
../../coregrind/vg_toolint.h:738: parse error before "_new_mem_startup"
../../coregrind/vg_toolint.h:741: parse error before
"_new_mem_stack_signal"
../../coregrind/vg_toolint.h:744: parse error before "_new_mem_brk"
../../coregrind/vg_toolint.h:747: parse error before "_new_mem_mmap"
../../coregrind/vg_toolint.h:751: parse error before "_copy_mem_remap"
../../coregrind/vg_toolint.h:754: parse error before
"_change_mem_mprotect"
../../coregrind/vg_toolint.h:757: parse error before
"_die_mem_stack_signal"
../../coregrind/vg_toolint.h:760: parse error before "_die_mem_brk"
../../coregrind/vg_toolint.h:763: parse error before "_die_mem_munmap"
../../coregrind/vg_toolint.h:777: parse error before "_new_mem_stack_4"
../../coregrind/vg_toolint.h:780: parse error before "_new_mem_stack_8"
../../coregrind/vg_toolint.h:783: parse error before "_new_mem_stack_12"
../../coregrind/vg_toolint.h:786: parse error before "_new_mem_stack_16"
../../coregrind/vg_toolint.h:789: parse error before "_new_mem_stack_32"
../../coregrind/vg_toolint.h:792: parse error before "_new_mem_stack"
../../coregrind/vg_toolint.h:796: parse error before "_die_mem_stack_4"
../../coregrind/vg_toolint.h:799: parse error before "_die_mem_stack_8"
../../coregrind/vg_toolint.h:802: parse error before "_die_mem_stack_12"
../../coregrind/vg_toolint.h:805: parse error before "_die_mem_stack_16"
../../coregrind/vg_toolint.h:808: parse error before "_die_mem_stack_32"
../../coregrind/vg_toolint.h:811: parse error before "_die_mem_stack"
../../coregrind/vg_toolint.h:817: parse error before "_ban_mem_stack"
../../coregrind/vg_toolint.h:823: parse error before "_pre_mem_read"
../../coregrind/vg_toolint.h:826: parse error before
"_pre_mem_read_asciiz"
../../coregrind/vg_toolint.h:829: parse error before "_pre_mem_write"
../../coregrind/vg_toolint.h:836: parse error before "_post_mem_write"
../../coregrind/vg_toolint.h:846: parse error before "_pre_reg_read"
../../coregrind/vg_toolint.h:853: parse error before
"_post_regs_write_init"
../../coregrind/vg_toolint.h:860: parse error before
"_post_reg_write_syscall_return"
../../coregrind/vg_toolint.h:863: parse error before
"_post_reg_write_deliver_signal"
../../coregrind/vg_toolint.h:866: parse error before
"_post_reg_write_pthread_return"
../../coregrind/vg_toolint.h:869: parse error before
"_post_reg_write_clientreq_return"
../../coregrind/vg_toolint.h:874: parse error before
"_post_reg_write_clientcall_return"
../../coregrind/vg_toolint.h:881: parse error before "_thread_run"
../../coregrind/vg_toolint.h:891: parse error before
"_post_thread_create"
../../coregrind/vg_toolint.h:894: parse error before "_post_thread_join"
../../coregrind/vg_toolint.h:905: parse error before "_pre_mutex_lock"
../../coregrind/vg_toolint.h:911: parse error before "_post_mutex_lock"
../../coregrind/vg_toolint.h:917: parse error before
"_post_mutex_unlock"
../../coregrind/vg_toolint.h:928: parse error before
"_pre_deliver_signal"
../../coregrind/vg_toolint.h:934: parse error before
"_post_deliver_signal"
../../coregrind/vg_toolint.h:944: parse error before "_init_shadow_page"
../../coregrind/vg_toolint.h:951: parse error before "_malloc"
../../coregrind/vg_toolint.h:954: parse error before "___builtin_new"
../../coregrind/vg_toolint.h:957: parse error before
"___builtin_vec_new"
../../coregrind/vg_toolint.h:960: parse error before "_memalign"
../../coregrind/vg_toolint.h:963: parse error before "_calloc"
../../coregrind/vg_toolint.h:966: parse error before "_free"
../../coregrind/vg_toolint.h:969: parse error before "___builtin_delete"
../../coregrind/vg_toolint.h:972: parse error before
"___builtin_vec_delete"
../../coregrind/vg_toolint.h:975: parse error before "_realloc"
../../coregrind/vg_toolint.h:977: warning: type defaults to `int' in
declaration of `VgToolInterface'
../../coregrind/vg_toolint.h:977: warning: data definition has no type
or storage class
../../coregrind/vg_toolint.h:979: parse error before
"vgPlain_tool_interface"
../../coregrind/vg_toolint.h:979: warning: type defaults to `int' in
declaration of `vgPlain_tool_interface'
../../coregrind/vg_toolint.h:979: warning: data definition has no type
or storage class
signal.c: In function `extend':
signal.c:385: warning: implicit declaration of function
`vgSkinInternal_new_mem_stack_signal'
signal.c: In function `build_sigframe':
signal.c:440: warning: implicit declaration of function
`vgSkinInternal_pre_mem_write'
signal.c:459: warning: implicit declaration of function
`vgSkinInternal_post_mem_write'
signal.c: In function `vgArch_push_signal_frame':
signal.c:527: warning: implicit declaration of function
`vgSkinInternal_post_reg_write_deliver_signal'
signal.c: In function `vgArch_signal_return':
signal.c:627: warning: implicit declaration of function
`vgSkinInternal_die_mem_stack_signal'
signal.c:635: warning: implicit declaration of function
`vgSkinInternal_post_deliver_signal'
make[5]: *** [signal.o] Fehler 1
|
|
From: Olly B. <ol...@su...> - 2005-01-17 17:29:59
|
On 2005-01-17, Tom Hughes <th...@cy...> wrote:
> So is AS_HELP_STRING if you use a recent version of autoconf.
Since a minimum autoconf version is required, configure.in should really
indicate which using AC_PREREQ. If it doesn't work with autoconf
2.57, then 2.59 is the sensible version to require (2.59 was released
the same day as 2.58 which strongly suggests 2.58 was rather broken).
2.59 is the latest.
Here's a patch against CVS HEAD:
Index: configure.in
===================================================================
RCS file: /cvsroot/valgrind/valgrind/configure.in,v
retrieving revision 1.97
diff -p -u -r1.97 configure.in
--- configure.in 18 Oct 2003 14:05:42 -0000 1.97
+++ configure.in 17 Jan 2005 17:24:43 -0000
@@ -1,4 +1,5 @@
# Process this file with autoconf to produce a configure script.
+AC_PREREQ(2.59)
AC_INIT(coregrind/vg_main.c) # give me a source file, any source file...
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(valgrind, 20030725)
With this patch in place, you'll get an error like this if your autoconf
is too old (this is what 2.53 says):
configure.in:2: error: Autoconf version 2.59 or higher is required
configure.in:2: the top level
Cheers,
Olly
|
|
From: <oli...@on...> - 2005-01-17 13:28:05
|
While compling state.c I get the error, that the "vg_toolint.h" is missing. And when I remove the #include, it says it can't find the "vgPlain_tool_interface". I search the source and didn't find any of this. It is also used in coregrind/vg_main.c coregrind/vg_translate.c Ans at the beginning of the make process, I also get a lot of warnings like this: Use of uninitialized value in concatenation (.) or string at ../coregrind/gen_toolint.pl line 94, <STDIN> line 21. |
|
From: <oli...@on...> - 2005-01-17 13:08:09
|
David Eriksson <tw...@us...> schrieb am 17.01.2005, 10:53:21: > On Mon, 2005-01-17 at 10:26 +0100, oli...@on... wrote: > > I checked out the latest CVS and got the following error, when running > > autoconf: > > > > configure.in:258: error: possibly undefined macro: AS_HELP_STRING > > Try to change AS_HELP_STRING to AC_HELP_STRING (AS -> AC). > > I don't know where AS_HELP_STRING comes from, but AC_HELP_STRING is > included with autoconf: > > http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_132.html > I chagned it to AC_HELP_STRING and it worked fine. The configure also waorked this time. Thanks for the help. |
|
From: <oli...@on...> - 2005-01-17 12:48:13
|
David Eriksson <tw...@us...> schrieb am 17.01.2005, 10:59:18: > On Mon, 2005-01-17 at 10:26 +0100, oli...@on... wrote: > > I checked out the latest CVS and got the following error, when running > > autoconf: > > > > configure.in:258: error: possibly undefined macro: AS_HELP_STRING > > Sorry about my previous mail; ignore it! > > The solution is to upgrade autoconf to 2.59. (I think.) That's just great, because I can't upgrade, it's a fixed configuration. And it worked a few days ago. Well..the autoconf worked, but I couldn't successfully run the configure it created. |
|
From: Tom H. <th...@cy...> - 2005-01-17 10:38:45
|
In message <110...@zi...>
David Eriksson <tw...@us...> wrote:
> On Mon, 2005-01-17 at 10:26 +0100, oli...@on... wrote:
>> I checked out the latest CVS and got the following error, when running
>> autoconf:
>>
>> configure.in:258: error: possibly undefined macro: AS_HELP_STRING
>
> Try to change AS_HELP_STRING to AC_HELP_STRING (AS -> AC).
>
> I don't know where AS_HELP_STRING comes from, but AC_HELP_STRING is
> included with autoconf:
>
> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_132.html
So is AS_HELP_STRING if you use a recent version of autoconf.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: David E. <tw...@us...> - 2005-01-17 09:59:26
|
On Mon, 2005-01-17 at 10:26 +0100, oli...@on... wrote:
> I checked out the latest CVS and got the following error, when running
> autoconf:
>
> configure.in:258: error: possibly undefined macro: AS_HELP_STRING
Sorry about my previous mail; ignore it!
The solution is to upgrade autoconf to 2.59. (I think.)
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
|
|
From: David E. <tw...@us...> - 2005-01-17 09:53:30
|
On Mon, 2005-01-17 at 10:26 +0100, oli...@on... wrote: > I checked out the latest CVS and got the following error, when running > autoconf: > > configure.in:258: error: possibly undefined macro: AS_HELP_STRING Try to change AS_HELP_STRING to AC_HELP_STRING (AS -> AC). I don't know where AS_HELP_STRING comes from, but AC_HELP_STRING is included with autoconf: http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_132.html -- Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net ScummVM - http://scummvm.sourceforge.net Desquirr - http://desquirr.sourceforge.net |
|
From: <oli...@on...> - 2005-01-17 09:28:09
|
I checked out the latest CVS and got the following error, when running autoconf: configure.in:258: error: possibly undefined macro: AS_HELP_STRING |
|
From: Crazymails4u.com
|
<html> <body> Dear ,<br> <br> Thank you for registering for the Crazymails4u.com forums. Before we can activate your account one last step must be taken to complete your registration!<br> <br> Please note - you must complete this last step to become a registered member. You will only need to click on the link once, and your account will be updated.<br> <br> To complete your registration, click on the link below: <br> <br> <a href="http://crazymails4u.com/RegistrationComplete/?a=act&u=12417&i=89808394">http://crazymails4u.com/RegistrationComplete/?a=act&u=12417&i=89808394</a><br> <br> **** Does The Above Link Not Work? ****<br> If the above link does not work, please use your Web browser to go to:<br> <a href="http://crazymails4u.com/RegistrationComplete/?a=ver">http://crazymails4u.com/RegistrationComplete/?a=ver</a><br> <br> Please to be sure not to add extra spaces. You will need to type in your username and activation number on the page that<br> appears when you click on or copy the above link in your browser.<br> <br> Your Username is: <br> Your Activation ID is: 3264<br> <br> If you are still having problems signing up please contact a member of our support staff at web...@cr...<br> <br> Thanks very much,<br> Crazymails4u.com team<br> <br> <br> --------------------<br> To stop receiving this email, please click here:<br> <a href="http://crazymails4u.com/RegistrationComplete/?a=act&u=12417&i=89808394">http://crazymails4u.com/RegistrationComplete/?a=act&u=12417&i=89808394</a><br> </body> </html> |
|
From: Sev B. <se...@bn...> - 2005-01-13 16:08:34
|
32c32,33
<
---
> #include <string.h>
> #include <stdio.h>
105a107
>
246a249,250
> Char ** dnames = NULL; //sev - create a dir table
> UInt last_dir_entry = 0; //sev - and keep an index
337a342,343
>
> /*
339c345,346
< {
---
> {
> UChar * name;
341c348,375
< }
---
>
> }
> */
>
> //sev - lets not ignore dir
> // lets save them so we can use them later to create the full
> // path
> while (* data != 0)
> {
> UChar * name;
>
> ++ last_dir_entry;
>
> name = data;
>
> /* Since we don't have realloc (0, ....) == malloc (...)
> semantics, we need to malloc the first time. */
>
> if (dnames == NULL)
> dnames = VG_(arena_malloc)(VG_AR_SYMTAB, sizeof (UInt) * 2);
> else
> dnames = VG_(arena_realloc)(VG_AR_SYMTAB, dnames, /*alignment*/4,
> sizeof(UInt) * (last_dir_entry + 1));
> data += VG_(strlen) ((Char *) data) + 1;
> dnames[last_dir_entry] = VG_(addStr) (si,name, -1);
> /* printf("dir = %s \n", dnames[last_dir_entry]); */
> }
> /* printf("***************************\n"); */
362a397,398
> /*sev*/
>
363a400
> /*printf("file = %s \n", name); */
374d410
< fnames[state_machine_regs.last_file_entry] = VG_(addStr) (si,name, -1);
376c412,417
< read_leb128 (data, & bytes_read, 0);
---
> //sev - what I need to do here is concatenate the dir
> //from above with name & pass it in
>
> // fnames[state_machine_regs.last_file_entry] = VG_(addStr) (si,name, -1);
>
> unsigned int dirindex = read_leb128 (data, & bytes_read, 0);
381a423,444
>
> {
> /* sev -- append the dir name to file name and save */
> /*printf("dirindex = %u \n", dirindex ); */
> if (dirindex > last_dir_entry ) printf("dirindex too large \n");
> char fullname[2000];
> fullname[0] = '\0';
> if ((dirindex <=0) || (dirindex > last_dir_entry) )
> {/* if dont have a dir name then skip it */
> /*printf("dirindex <= 0 \n"); */
> strcpy(fullname, name);
> }
> else
> {
> /*printf("dirnameB %s\n", dnames[dirindex ]); */
> sprintf(fullname,"%s/",dnames[dirindex]);
> strcat(fullname, name);
> }
> /* printf( "fullname = %s \n", fullname); */
> fnames[state_machine_regs.last_file_entry] = VG_(addStr) (si, fullname, -1);
> /*printf("***************************\n"); */
> }
384a448,452
> //sev - clean up dir structure and index
> VG_(arena_free)(VG_AR_SYMTAB, dnames);
> dnames = NULL;
> last_dir_entry = 0;
>
530a599
>
|
|
From: Paul P. <ppl...@gm...> - 2005-01-13 03:50:35
|
On Wed, 12 Jan 2005 15:29:40 -0500, Chris Shoemaker <c.s...@co...> wrote: > Is there a way to make valgrind report the _read_ of an uninitialized > value instead of waiting until a conditional jump depends on it? This is what Chaperon (part of commercial Insure++ product from Parasoft) does. Unfortunately, this tends to produce a lot of "noise": some versions of gcc emit code that copies around uninitialized values (the copies are never used either). With VG strategy you have a real bug but have trouble finding the root cause. With Chaperon, you (sometimes) have a lot of "false positives". Either way, you loose :-( |
|
From: Yardumian, H. (H. (hrant) <hr...@ch...> - 2005-01-12 21:51:41
|
Here is the Valgrind command line ... libtool --mode=3Dexecute '/data/intersect/users/liko/valgrind-2.2.0/bin/valgrind = --error-limit=3Dno --leak-check=3Dno -v --skin=3Dmemcheck --logfile=3DVALGRIND = --num-callers=3D25 --show-reachable=3Dyes' simulator_test_simulator_test_main.exe=20 It's version 2.2 Thanks ! Hrant Yardumian ChevronTexaco - ETC Reservoir Simulation Research - INTERSECT Team 4800 Fournace Pl., Rm E-561 Bellaire, TX 77401-2324 Tel : (713) 432-2816 =20 Mobile : (281) 782-8669 Fax : (713) 432-6620 -----Original Message----- From: Chris Shoemaker [mailto:c.s...@co...]=20 Sent: Wednesday, January 12, 2005 2:24 PM To: Yardumian, Hrant (HEYA) (hrant) Cc: val...@li...; Lim, Kok-Thye (KLim); Verma, Ajay Subject: Re: [Valgrind-users] (no subject) On Wed, Jan 12, 2005 at 12:49:23PM -0600, Yardumian, Hrant (HEYA) (hrant) wrote: >=20 > I am trying to use Valgrind on an executable that's built with the -g=20 > option, yet Valgrind complains that it cannot load the debug info and=20 > symbols. (see sample output below.) >=20 > As a result, Valgrind output will not give me exact locations of=20 > problems. >=20 > Are there any settings other than -g that I need when building my=20 > executable? >=20 > Thanks - >=20 You should show the command line used to execute valgrind. What version are you using? =20 >=20 >=20 > =3D=3D30298=3D=3D Reading syms from=20 > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_tes > t/ > simulator_test/simulator_test_simulator_test_main.exe (0x8048000) > =3D=3D30298=3D=3D warning: mmap failed on Why is the mmap failing? > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_tes > t/ > simulator_test/simulator_test_simulator_test_main.exe > =3D=3D30298=3D=3D no symbols or debug info loaded > =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from > /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ > lib/valgrind/stage2 (0xB0000000) > =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0xB1000000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from /lib/libdl-2.2.5.so (0xB1031000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from /lib/i686/libc-2.2.5.so = (0xB1035000) > =3D=3D30298=3D=3D object doesn't have any debug info >=20 > Hrant Yardumian > ChevronTexaco - ETC > Reservoir Simulation Research - INTERSECT Team > 4800 Fournace Pl., Rm E-561 > Bellaire, TX 77401-2324 >=20 > Tel : (713) 432-2816 =20 > Mobile : (281) 782-8669 > Fax : (713) 432-6620 >=20 |