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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: John R.
|
valgrind-3.0.0 crashes with SIGILL [illegal instruction] at startup on AMD Athlon ["plain"]. Apparently valgrind-3.0.0 assumes SSE x86 hardware ["ldmxcsr" instruction introduced with SSE]. So if "cat /proc/cpuinfo | grep flags" does not show "sse", then valgrind-3.0.0 will not work your CPU. http://bugs.kde.org/show_bug.cgi?id=110274 -- |
|
From: John R.
|
> Hmmm.. This is the tail of the strace result > strace valgrind /bin/date ## supposedly valgrind-2.4.0 from source > getpid() = 21057 > socketpair(0x5241 /* PF_??? */, 0xb /* SOCK_??? */, 2957078392, 0xb) = -1 > ENOSYS (Function not implemented) > kill(21057, SIGSEGV) = 0 > --- SIGSEGV (Segmentation fault) --- > +++ killed by SIGSEGV +++ http://www.valgrind.org/downloads/valgrind-2.4.1.tar.bz2 is the only 2.4.* version available on the downloads page. I compiled it with gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) running on Red Hat 8 updated to 2.4.20-30.8.legacy, the oldest system that is readily available to me. Valgrind works on that system, which is powered by an AMD Athlon family 6, model 4, stepping 2 (including mmx mmxext 3dnow 3dnowext, but excluding sse.) "strace valgrind /bin/date" shows no socketpair calls. Either that was removed from valgrind-2.4.0, or Ahmet's binary was built on a foreign system, or Ahmet's machine had hardware errors. -- |
|
From: Julian S. <js...@ac...> - 2005-08-05 16:34:44
|
On Friday 05 August 2005 16:58, Nicholas Nethercote wrote: > So I'm trying to clear up the confusion. Here's a summary: > > - 3.0.0 does not use PIE by default. This is much more stable. Do not > use --enable-pie unless you have to. > > - Any why would you have to? Because a PIE build can give your program > more address space when running under Valgrind, particularly on AMD64. One more comment, which is: the fact that PIE gives you more address space on AMD64 is really because it works around limitations in Valgrind's low-level address space management. There is a plan to completely overhaul the address space manager, and if that works out, then you will be able to use arbitrary amounts of address space on 64-bit targets without having to resort to PIE builds. J |
|
From: Dirk M. <dm...@gm...> - 2005-08-05 16:15:47
|
On Friday 05 August 2005 17:58, Nicholas Nethercote wrote: > problems -- people having random, inexplicable crashes. So for 3.0.0 we > turned it off by default because it was causing too many problems. same for 2.4.1 that is. Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-08-05 15:58:38
|
Hi, In Valgrind 2.4.0, we built Valgrind as a position-independent executable (PIE) if the toolchain supported it. This turned out to cause quite a few problems -- people having random, inexplicable crashes. So for 3.0.0 we turned it off by default because it was causing too many problems. As a result of all this, it unfortunately seems like --enable-pie/--disable-pie has taken on a mythical status... as though we deliberately shipped a crippled Valgrind and you have to find the special configure option to get it to work, bwaha! So I'm trying to clear up the confusion. Here's a summary: - 3.0.0 does not use PIE by default. This is much more stable. Do not use --enable-pie unless you have to. - Any why would you have to? Because a PIE build can give your program more address space when running under Valgrind, particularly on AMD64. - However, as we have seen, using PIE is a bit flaky and has caused problems on many systems. In short: don't use --enable-pie when configuring Valgrind unless you know you need the extra address space it allows. And if you do use it, don't be shocked if Valgrind crashes. We'd like to fix these problems, but we don't understand them yet. Any information people can shed on them would be great, but as usual, saying "I built with PIE and Valgrind crashes!! What's wrong??" isn't very helpful. The more relevant information you can provide, the better. N |
|
From: Ahmet B.
|
Hmmm.. This is the tail of the strace result
strace valgrind /bin/date
Function not implemented .. So kill ?
Ahmet
open("/proc/self/maps", O_RDONLY) = 3
read(3, "08048000-0804e000 r-xp 00000000 "..., 2048) = 2048
read(3, " /lib/ld-2.2.5.so\nb1015000-b10"..., 2048) = 940
read(3, "", 1108) = 0
close(3) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {0xb0039ac2, ~[KILL STOP],
SA_RESTART|SA_SIGINFO|0x4000000}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) =
0
getpid() = 21057
socketpair(0x5241 /* PF_??? */, 0xb /* SOCK_??? */, 2957078392, 0xb) = -1
ENOSYS (Function not implemented)
kill(21057, SIGSEGV) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
|
|
From: Ahmet B.
|
>Basic fault isolation (divide and conquer): >Does "valgrind /bin/date" run on your system? Below is the result... I guess the answer is "NO" So the problem is either in my kernel, or in the way I built valgrind, Or I need to supply runtime switches or initialization file before I run even "Hello world" ? (that does not sound right) I had problems with my first install where even "./valgrind" did not run. Then I used --disable-pie and got to this stage.... Are there other switches that I may want to use for building valgrind ? Thanks guys.. ---------------------------------------------------------------------------- --- data/NOMSClient> valgrind /bin/date ==21015== Memcheck, a memory error detector for x86-linux. ==21015== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==21015== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==21015== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==21015== For more details, rerun with: -v ==21015== ==21015== ==21015== Process terminating with default action of signal 11 (SIGSEGV) ==21015== Bad permissions for mapped region at address 0x1B903638 ==21015== at 0x1B8EDE53: _dl_relocate_object (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==21015== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==21015== Jump to the invalid address stated on the next line ==21015== at 0x8C2: ??? ==21015== by 0x1B8F9A5F: ??? ==21015== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==21015== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==21015== Address 0x8C2 is not stack'd, malloc'd or (recently) free'd ==21015== ==21015== Process terminating with default action of signal 11 (SIGSEGV) ==21015== Access not within mapped region at address 0x8C2 ==21015== at 0x8C2: ??? ==21015== by 0x1B8F9A5F: ??? ==21015== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==21015== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==21015== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==21015== ==21015== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 2) ==21015== malloc/free: in use at exit: 0 bytes in 0 blocks. ==21015== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==21015== For counts of detected errors, rerun with: -v ==21015== No malloc'd blocks -- no leaks are possible. |
|
From: John R.
|
>>I don't know what else I can say > What is the output of > ldd ./my_application Because it appears that the failure occurs very close to the beginning: strace -o strace.out valgrind ./my_application Then post (or make available) the output file strace.out (or a compressed version.) Output from strace can become very large very quickly, but in this case it may be small. -- |
|
From: Paul P. <ppl...@gm...> - 2005-08-05 14:33:19
|
On 8/5/05, Ahmet Buharali <abu...@sc...> wrote:
> I don't know what else I can say
Basic fault isolation (divide and conquer):
Does "valgrind /bin/date" run on your system?
No: there is something wrong with your system. Describe what the system is.
Yes: goto next question.
Does "int main() { return 0; }" run when linked with the same shared librar=
ies?
No: something's wrong with one of the shared libraries; try to figure
out which one.
Yes: something wrong with your app; try to comment out parts of it.
Etc. etc.
Cheers,
|
|
From: John R.
|
> Using gcc, They are dynamically linked libraries, i.e. xxx.so files, not > xxx.a > It is a large applicationcd totalling about 300Mb of object code ... > I don't know what else I can say The number, size, and placement of main and shared libraries may matter. What is the output of ldd ./my_application [Disguise the names of your own shared libraries, if you wish.] Kernel version 2.4.18 and being compiled three years ago: Linux atlas 2.4.18-64GB-SMP #1 SMP Wed Mar 27 13:58:12 UTC 2002 i686 unknown indicates that your kernel does not randomize placment of mmap(0,...) which might also matter if it did. -- |
|
From: Ahmet B.
|
Using gcc, They are dynamically linked libraries, i.e. xxx.so files, not xxx.a It is a large applicationcd totalling about 300Mb of object code I use tmake and make Gcc version 3.4.0 I have the optimizers turned off It is a multi-threaded application. It is using TC/PIP (through sockets) and STL, as well as Qt I don't know what else I can say Ahmet -----Original Message----- From: Maurice van der Pot [mailto:gri...@ge...] Sent: Thursday, August 04, 2005 5:15 PM To: val...@li... Subject: Re: [Valgrind-users] Valgrind crashes during startup......help On Thu, Aug 04, 2005 at 11:54:22AM -0400, Ahmet Buharali wrote: > I have not been able to use valgrind on my application. > It seems it is failing right at the start. > I did compile it with --disable-pie > Below is the console output I am getting with Valgrind How did you compile your application? Maurice. -- Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-04 21:15:09
|
On Thu, Aug 04, 2005 at 11:54:22AM -0400, Ahmet Buharali wrote: > I have not been able to use valgrind on my application. > It seems it is failing right at the start. > I did compile it with --disable-pie > Below is the console output I am getting with Valgrind How did you compile your application? Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Stephen T. <st...@to...> - 2005-08-04 19:28:30
|
On Thu, 2005-08-04 at 09:37 -0500, Trey Boudreau wrote: > Indeed. Valgrind has helped enormously on the PalmOS for Linux port by > turning up a GCC optimization bug that kept our release builds from > running, not to mention the various bugs of our own making. To quote > one of our engineers: "valgrind is my new best friend." >=20 > -- > Trey Boudreau > Sr. Code Monkey > PalmSource, Inc. Is it possible for your team of engineers to post examples on a web page of how they used valgrind and what bugs it caught? This is ofcourse if its possible for them to talking about how they used valgrind without giving away any secrets. I believe it would be very helpful to see a repository of bug examples and how valgrind helped solve them. Stephen |
|
From: <an...@cl...> - 2005-08-04 16:41:22
|
> In message <42EA2129.3060005 <at> clarinet.u-strasbg.fr> > Martin André <andre <at> clarinet.u-strasbg.fr> wrote: > >> Hi Dennis, >> >> >At 18:27 27.07.2005, Martin André wrote: >> >>The problem is that running my program using Valgrind makes the >> >>if_indextoname function (declared as extern char *if_indextoname (unsigned >> >>int __ifindex, char *__ifname) __THROW; in net/if.h) return NULL with the >> >>following error in the output: >> >> >> >>==10869== Syscall param ioctl(SIOCGIFNAME) points to unaddressable byte(s) >> >>==10869== at 0x1B9EF114: ioctl (in /lib/tls/libc-2.3.2.so) >> >>==10869== by 0x8048478: main (test.c:14) >> >>==10869== Address 0x2 is not stack"d, malloc"d or (recently) free"d >> > >> >You are passing an invalid parameter to the syscall, thus 0 is returned. >> >Check if the parameters to if_indextoname are valid prior to calling it >> >> Yes I've checked and the arguments I pass if_indextoname are valid. As I >> already said - the call to if_indextoname is part of a program that's >> running as expected (i.e. returning the name of a network interface) >> when not run from within Valgrind. Does that mean that the error is >> inside if_indextoname's implementation? Is it possible to tell Valgrind >> not to examine this syscall? > > This should be fixed now - it was using the value of ifr_index as > the address when trying to test it is was valid. The bug is still present in 2.4.1, but has been fixed in 3.0 release. Thanks. Martin |
|
From: Ahmet B.
|
I have not been able to use valgrind on my application. It seems it is failing right at the start. I did compile it with --disable-pie Below is the console output I am getting with Valgrind My system is: data/NOMSClient> uname -a ---------------------------------------------------------------------------- - Linux atlas 2.4.18-64GB-SMP #1 SMP Wed Mar 27 13:58:12 UTC 2002 i686 unknown ---------------------------------------------------------------------------- - It basically a pentium box. I am using Oracle 9 libraries, as well as Qt 3 gcc 3.4.0 Any words of wisdom ? Thanks Ahmet ---------------------------------------------------------------------------- --- Console output Shell started ... ==17673== Memcheck, a memory error detector for x86-linux. ==17673== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==17673== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==17673== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==17673== For more details, rerun with: -v ==17673== ==17673== ==17673== Process terminating with default action of signal 11 (SIGSEGV) ==17673== Bad permissions for mapped region at address 0x1B903638 ==17673== at 0x1B8EDE53: _dl_relocate_object (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==17673== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==17673== Jump to the invalid address stated on the next line ==17673== at 0x8C2: ??? ==17673== by 0x1B8F9A5F: ??? ==17673== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==17673== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==17673== Address 0x8C2 is not stack'd, malloc'd or (recently) free'd ==17673== ==17673== Process terminating with default action of signal 11 (SIGSEGV) ==17673== Access not within mapped region at address 0x8C2 ==17673== at 0x8C2: ??? ==17673== by 0x1B8F9A5F: ??? ==17673== by 0x1B8E7E39: dl_main (in /lib/ld-2.2.5.so) ==17673== by 0x1B8F25DC: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E6431: _dl_start_final (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E637B: _dl_start (in /lib/ld-2.2.5.so) ==17673== by 0x1B8E5E35: (within /lib/ld-2.2.5.so) ==17673== ==17673== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 207 from 2) ==17673== malloc/free: in use at exit: 0 bytes in 0 blocks. ==17673== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==17673== For counts of detected errors, rerun with: -v ==17673== No malloc'd blocks -- no leaks are possible. Segmentation fault |
|
From: Trey B. <tr...@tr...> - 2005-08-04 14:38:12
|
On Thu, Aug 04, 2005 at 04:22:18AM -0400, Daniel Veillard wrote: > On Thu, Aug 04, 2005 at 01:21:06AM +0100, Julian Seward wrote: > > We are pleased to announce a new release of Valgrind, version 3.0.0. > > It is available from http://www.valgrind.org. > > As John Maddog points out regulary, it's important to say thank you ! > Valgrind is a fantastic tool, it saved me countless hours of debugging > and is one of the key tools which are making my Linux environment safer > and more reliable everyday. > > Congratulations and a big Thank You to all the valgrind developpers ! > Indeed. Valgrind has helped enormously on the PalmOS for Linux port by turning up a GCC optimization bug that kept our release builds from running, not to mention the various bugs of our own making. To quote one of our engineers: "valgrind is my new best friend." -- Trey Boudreau Sr. Code Monkey PalmSource, Inc. |
|
From: Daniel V. <vei...@re...> - 2005-08-04 08:22:39
|
On Thu, Aug 04, 2005 at 01:21:06AM +0100, Julian Seward wrote: > We are pleased to announce a new release of Valgrind, version 3.0.0. > It is available from http://www.valgrind.org. As John Maddog points out regulary, it's important to say thank you ! Valgrind is a fantastic tool, it saved me countless hours of debugging and is one of the key tools which are making my Linux environment safer and more reliable everyday. Congratulations and a big Thank You to all the valgrind developpers ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Christian P. <tr...@ge...> - 2005-08-04 02:30:34
|
Hi, well yeah, I do understand why -1 is not that good to write(), however, I'd like to know where this happened, that is, I am really missing the=20 calltrace there; is there a way to tell valgrind to do so? (as I'm having not just one locat= ion=20 where this could have been happening) Thanks in advance, Christian Parpart. =2D-=20 04:28:41 up 133 days, 17:36, 5 users, load average: 1.50, 3.00, 7.42 |
|
From: Julian S. <js...@ac...> - 2005-08-04 00:21:15
|
We are pleased to announce a new release of Valgrind, version 3.0.0. It is available from http://www.valgrind.org. Valgrind is an open-source suite of simulation based debugging and profiling tools. With the tools that come with Valgrind, you can automatically detect many memory management bugs, avoiding hours of frustrating bug-hunting, and make your code more stable. You can also perform detailed time and space profiling to help speed up and slim down your programs. 3.0.0 is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not work well enough to be useful yet. There have been many other improvements and refinements relative to the 2.4.X line. The attached release notes detail what is new in 3.0.0. Many thanks to all those who contributed to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.0.0 (3 August 2005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user visible change is that Valgrind now supports architectures other than x86. The new architectures it supports are AMD64 and PPC32, and the infrastructure is present for other architectures to be added later. AMD64 support works well, but has some shortcomings: - It generally won't be as solid as the x86 version. For example, support for more obscure instructions and system calls may be missing. We will fix these as they arise. - Address space may be limited; see the point about position-independent executables below. - If Valgrind is built on an AMD64 machine, it will only run 64-bit executables. If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine. And it probably won't work if you do something tricky like exec'ing a 32-bit program from a 64-bit program while using --trace-children=yes. We hope to improve this situation in the future. The PPC32 support is very basic. It may not work reliably even for small programs, but it's a start. Many thanks to Paul Mackerras for his great work that enabled this support. We are working to make PPC32 usable as soon as possible. Other user-visible changes: - Valgrind is no longer built by default as a position-independent executable (PIE), as this caused too many problems. Without PIE enabled, AMD64 programs will only be able to access 2GB of address space. We will fix this eventually, but not for the moment. Use --enable-pie at configure-time to turn this on. - Support for programs that use stack-switching has been improved. Use the --max-stackframe flag for simple cases, and the VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE client requests for trickier cases. - Support for programs that use self-modifying code has been improved, in particular programs that put temporary code fragments on the stack. This helps for C programs compiled with GCC that use nested functions, and also Ada programs. This is controlled with the --smc-check flag, although the default setting should work in most cases. - Output can now be printed in XML format. This should make it easier for tools such as GUI front-ends and automated error-processing schemes to use Valgrind output as input. The --xml flag controls this. As part of this change, ELF directory information is read from executables, so absolute source file paths are available if needed. - Programs that allocate many heap blocks may run faster, due to improvements in certain data structures. - Addrcheck is currently not working. We hope to get it working again soon. Helgrind is still not working, as was the case for the 2.4.0 release. - The JITter has been completely rewritten, and is now in a separate library, called Vex. This enabled a lot of the user-visible changes, such as new architecture support. The new JIT unfortunately translates more slowly than the old one, so programs may take longer to start. We believe the code quality is produces is about the same, so once started, programs should run at about the same speed. Feedback about this would be useful. On the plus side, Vex and hence Memcheck tracks value flow properly through floating point and vector registers, something the 2.X line could not do. That means that Memcheck is much more likely to be usably accurate on vectorised code. - There is a subtle change to the way exiting of threaded programs is handled. In 3.0, Valgrind's final diagnostic output (leak check, etc) is not printed until the last thread exits. If the last thread to exit was not the original thread which started the program, any other process wait()-ing on this one to exit may conclude it has finished before the diagnostic output is printed. This may not be what you expect. 2.X had a different scheme which avoided this problem, but caused deadlocks under obscure circumstances, so we are trying something different for 3.0. - Small changes in control log file naming which make it easier to use valgrind for debugging MPI-based programs. The relevant new flags are --log-file-exactly= and --log-file-qualifier=. - As part of adding AMD64 support, DWARF2 CFI-based stack unwinding support was added. In principle this means Valgrind can produce meaningful backtraces on x86 code compiled with -fomit-frame-pointer providing you also compile your code with -fasynchronous-unwind-tables. - The documentation build system has been completely redone. The documentation masters are now in XML format, and from that HTML, PostScript and PDF documentation is generated. As a result the manual is now available in book form. Note that the documentation in the source tarballs is pre-built, so you don't need any XML processing tools to build Valgrind from a tarball. Changes that are not user-visible: - The code has been massively overhauled in order to modularise it. As a result we hope it is easier to navigate and understand. - Lots of code has been rewritten. BUGS FIXED: 110046 sz == 4 assertion failed 109810 vex amd64->IR: unhandled instruction bytes: 0xA3 0x4C 0x70 0xD7 109802 Add a plausible_stack_size command-line parameter ? 109783 unhandled ioctl TIOCMGET (running hw detection tool discover) 109780 unhandled ioctl BLKSSZGET (running fdisk -l /dev/hda) 109718 vex x86->IR: unhandled instruction: ffreep 109429 AMD64 unhandled syscall: 127 (sigpending) 109401 false positive uninit in strchr from ld-linux.so.2 109385 "stabs" parse failure 109378 amd64: unhandled instruction REP NOP 109376 amd64: unhandled instruction LOOP Jb 109363 AMD64 unhandled instruction bytes 109362 AMD64 unhandled syscall: 24 (sched_yield) 109358 fork() won't work with valgrind-3.0 SVN 109332 amd64 unhandled instruction: ADC Ev, Gv 109314 Bogus memcheck report on amd64 108883 Crash; vg_memory.c:905 (vgPlain_init_shadow_range): Assertion `vgPlain_defined_init_shadow_page()' failed. 108349 mincore syscall parameter checked incorrectly 108059 build infrastructure: small update 107524 epoll_ctl event parameter checked on EPOLL_CTL_DEL 107123 Vex dies with unhandled instructions: 0xD9 0x31 0xF 0xAE 106841 auxmap & openGL problems 106713 SDL_Init causes valgrind to exit 106352 setcontext and makecontext not handled correctly 106293 addresses beyond initial client stack allocation not checked in VALGRIND_DO_LEAK_CHECK 106283 PIE client programs are loaded at address 0 105831 Assertion `vgPlain_defined_init_shadow_page()' failed. 105039 long run-times probably due to memory manager 104797 valgrind needs to be aware of BLKGETSIZE64 103594 unhandled instruction: FICOM 103320 Valgrind 2.4.0 fails to compile with gcc 3.4.3 and -O0 103168 potentially memory leak in coregrind/ume.c 102039 bad permissions for mapped region at address 0xB7C73680 101881 weird assertion problem 101543 Support fadvise64 syscalls 75247 x86_64/amd64 support (the biggest "bug" we have ever fixed) (3.0RC1: 27 July 05, vex r1303, valgrind r4283). (3.0.0: 3 August 05, vex r1313, valgrind r4316). |
|
From: Paul P. <ppl...@gm...> - 2005-08-03 16:17:37
|
On 8/3/05, Nicholas Nethercote <nj...@cs...> wrote:
> > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI readi=
ng
>=20
> Julian fixed that, too.
The new regtest results from that system:
=3D=3D 159 tests, 8 stderr failures, 1 stdout failure =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
memcheck/tests/leakotron (stdout)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/sigprocmask (stderr)
memcheck/tests/strchr (stderr)
memcheck/tests/vgtest_ume (stderr)
memcheck/tests/weirdioctl (stderr)
memcheck/tests/xml1 (stderr)
none/tests/faultstatus (stderr)
none/tests/fdleak_fcntl (stderr)
The "interesting" diffs are:
*** vgtest_ume.stderr.exp 2005-07-02 15:43:03.000000000 -0700
--- vgtest_ume.stderr.out 2005-08-03 07:41:05.000000000 -0700
***************
*** 4 ****
! Hello, world!
--- 4,5 ----
! Warning: client syscall mmap2 tried to modify addresses 0x........-0x....=
....
! valgrind: mmap(0x........, 4096) failed in UME.
*** weirdioctl.stderr.exp 2005-07-02 15:42:58.000000000 -0700
--- weirdioctl.stderr.out 2005-08-03 07:41:06.000000000 -0700
***************
*** 3,4 ****
! by 0x........: __libc_start_main (in /...libc...)
! by 0x........: ...
--- 3,8 ----
! by 0x........: main (weirdioctl.c:28)
! Address 0x........ is on thread 1's stack
!=20
! Syscall param ioctl(TCSET{A,AW,AF}) points to uninitialised byte(s)
! at 0x........: ioctl (in /...libc...)
! by 0x........: main (weirdioctl.c:43)
*** xml1.stderr.exp64 2005-08-03 07:33:52.000000000 -0700
--- xml1.stderr.out 2005-08-03 07:41:09.000000000 -0700
***************
*** 353,364 ****
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>__libc_start_main</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <dir>...</dir>
- <file>start.S</file>
- <line>...</line>
- </frame>
--- 352 ----
*** faultstatus.stderr.exp 2005-07-02 15:43:44.000000000 -0700
--- faultstatus.stderr.out 2005-08-03 07:41:37.000000000 -0700
***************
*** 6,12 ****
- Test 5: PASS
- Test 6: PASS
- Test 7: PASS
- Test 8: PASS
- Test 9: disInstr: unhandled instruction bytes: 0x........ 0x........
0x........ 0x........
- at 0x........: test9 (faultstatus.c:127)
- FAIL: expected signal 11, not 4
--- 5 ----
(Looks like new faultstatus.stderr.exp64 is needed for that last one).
Cheers,
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-03 13:22:05
|
On Fri, 29 Jul 2005, Paul Pluzhnikov wrote: > make check fails to build: > /home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go' > collect2: ld returned 1 exit status > > This is because this gcc uses -D__x86_64 rather then -D__amd64 I fixed that the other day. > Most of the tests fail: > == 157 tests, 149 stderr failures, 2 stdout failures ================= > memcheck/tests/addressable (stderr) > memcheck/tests/badaddrvalue (stderr) > memcheck/tests/badfree-2trace (stderr) > memcheck/tests/badfree (stderr) > memcheck/tests/badjump (stderr) > memcheck/tests/badjump2 (stderr) > ... > > Looks like most of them are failing due to > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading > which I reported earlier. Julian fixed that, too. N |
|
From: Doriane R. <Ruf...@je...> - 2005-08-03 07:50:51
|
Hello, hands could no longer be doubted after the proofs it had given. ButI have = this to say before you deliver judgment. Your lordship seesColonel = Bishop set his foot upon the crossbar, and leaned over hisVastly = obliging of him, drawled his lordship, seeing that Missand all the while = those dulled wits of Pitt's were sharpeningin the shape of a great = bottle having its neck towards the seaOglethorpe's Farm by the river. I = bore him thither ... and ...went in quest of Blood. But he was still = intrigued. If she were afellows.violently by the time he reached the = stockade.Dutch brig, which he knew had been due to sail for Amsterdam = withnot hear of it. Blood must sleep in his own chamber to be at = handeffort. He sighed. He resumed his earlier gentle plaintiveness.and = pity. Their owner put forth a hand to touch the scarlet sleeveYour = lordship was about to say? he asked, with challengingDuring the = capitulation and for some time after, Captain Blood and |
|
From: Robert W. <rj...@du...> - 2005-08-02 23:10:48
|
> well, is this message prompted *only* when it mismatches the > malloc()/new/new[] or even, when someone passes free()/delete/delete[] a > pointer to some space that's never been allocated and/or even *already* > deallocated? No. Only for a mismatch. Invalid frees or already-freed messages are two different messages. Regards, Robert. |
|
From: Christian P. <tr...@ge...> - 2005-08-02 22:40:40
|
Hi all, well, is this message prompted *only* when it mismatches the=20 malloc()/new/new[] or even, when someone passes free()/delete/delete[] a=20 pointer to some space that's never been allocated and/or even *already*=20 deallocated? I guess, memcheck shall be slightly more verbose on this message then :o) It would indeet be a slight better help then. Any objections? Regards, Christian Parpart. =2D-=20 00:38:27 up 132 days, 13:46, 1 user, load average: 4.25, 7.48, 10.80 |
|
From: Cerion Armour-B. <ce...@op...> - 2005-08-02 19:15:36
|
On Tuesday 02 August 2005 18:32, Nicholas Nethercote wrote: > On Tue, 2 Aug 2005, Cerion Armour-Brown wrote: > > We're wondering whether to go the route of providing a terminal within > > the GUI, or to simply use the same terminal that Valkyrie was started in. > > I think the latter. I expect that if you try to provide a built-in > terminal it will take a lot of development effort, you'll never get it to > work exactly the way the normal terminals work, and both you and users > will get frustrated... > Assuming this could be done without too much trouble, and without huge dependencies etc, what say you then? I can imagine it might encourage kdevelop type programmers to valgrindify their code if it was made real easy for them. With kdevelop, you click 'run' and it can start up a konsole and run the program from there... Any kdevelop users out there with comments? Cerion |