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
(7) |
2
(23) |
3
(1) |
4
|
|
5
(1) |
6
(2) |
7
(3) |
8
(7) |
9
(11) |
10
(10) |
11
(3) |
|
12
(1) |
13
(10) |
14
(8) |
15
(6) |
16
(4) |
17
(7) |
18
(2) |
|
19
(1) |
20
(2) |
21
(1) |
22
(2) |
23
(2) |
24
(7) |
25
(1) |
|
26
(2) |
27
(1) |
28
(5) |
29
(2) |
30
(20) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-06-13 18:30:42
|
On Mon, 13 Jun 2005, Dennis Lubert wrote: >> I would like to port the nice valgrind tools to NetBSD i386 platform as the >> Google Summer of Code project. What are the issues that I should be >> careful with when I port valgrind to NetBSD? Since there is a FreeBSD port >> for valgrind-stable-352, I would start with that, and make necessary >> changes to fit NetBSD. Any comment/suggestion/feedback is highly >> appreciated. > > Wasnt the FreeBSD port of the 2.x version ? Maybe you should try to work > on the current 3.x svn tree, so the 3.x works on netbsd too. The > experiences you will make will probably be useful for porting it to > other BSDs or BSD derived systems. greets The FreeBSD port was against an earlier version. It should still be very instructive. But things have changed quite a bit between 2.X and the pre-3.0 line, so as Dennis says working against the 3.0 line would make more sense. It should be more amenable to OS ports than the 2.X line, but you should beware that it's still in flux -- things are currently being moved around a lot for modularisation reasons, so picking a current snapshot and working just from that (not updating) might be the best way to go. Then, if you get it working well you could update for any changes. Another thing: 3.0 supports both x86 and amd64. Any new port will actually be an arch/OS pair, eg. x86-freebsd or amd64-freebsd, because there is some platform-specific code. However, if you get one working it shouldn't be much more work to get the other working. People have worked on other OS ports; I know there are/have been Darwin, Solaris and DragonflyBSD ports under development. The authors of these might have suggestions or advice. Finally, this is a nice goal to aim for, but I hope you have a pretty detailed knowledge of how NetBSD works, since Valgrind does lots of low-level OS interactions, and ports are definitely non-trivial -- much more so than for more normal programs. (Doug Rabson, the FreeBSD porter, is a long-time FreeBSD kernel hacker, for example.) Good luck! Nick |
|
From: Dennis L. <pla...@in...> - 2005-06-13 18:06:53
|
At 19:43 13.06.2005, you wrote: >Hi all > >I would like to port the nice valgrind tools to NetBSD i386 platform as >the Google Summer of Code project. What are the issues that I should be >careful with when I port valgrind to NetBSD? Since there is a FreeBSD >port for valgrind-stable-352, I would start with that, and make necessary >changes to fit NetBSD. Any comment/suggestion/feedback is highly appreciated. Wasnt the FreeBSD port of the 2.x version ? Maybe you should try to work on the current 3.x svn tree, so the 3.x works on netbsd too. The experiences you will make will probably be useful for porting it to other BSDs or BSD derived systems. greets Dennis Carpe quod tibi datum est |
|
From: Farid A. <far...@ho...> - 2005-06-13 18:03:17
|
(I apologize for previous email: hotmail defaults to rich text mode) Hi, I recently switched from valgrind 2.0.0 to valgrind 2.4.0. when I started valgrind with the following options: valgrind --skin=none --trace-syscalls=yes -v MyProgram valgrind worked fine in version 2.0.0 but loading the dynamic libraries at startup takes a long long time to load in verion 2.4.0 (some dynamic libraries took around 4 minutes each to load. Also system calls which did not show in 2.0.0 are now showing in 2.4.0. For example in Valgrind 2.0.0 I will get ==8927== Reading syms from /sanbox/foo.so but in Valgrind 2.4.0 I will get something like the following and then a long pause for most dynamic libraries --> 985698304 (0x3AC09000) SYSCALL[8287,1](125):sys_mprotect ( 0x3AC20000, 13224, 0 ) --> 0 (0x0) SYSCALL[8287,1]( 90) special:old_mmap ( 0x3AC20000, 16384, 3, 18, 3, 90112 ) --> 985792512 (0x3AC20000) SYSCALL[8287,1]( 6):sys_close ( 3 ) --> 0 (0x0) SYSCALL[8287,1]( 5) mayBlock:sys_open ( 0xAFEFD4BC(/sandbox/foo.so), 0 ) --> ... SYSCALL[8287,1]( 5) --> 3 (0x3) SYSCALL[8287,1]( 3) mayBlock:sys_read ( 3, 0xAFEFD694, 1024 ) --> ... SYSCALL[8287,1]( 3) --> 1024 (0x400) SYSCALL[8287,1](197):sys_fstat64 ( 3, 0xAFEFD5C4 ) --> 0 (0x0) SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 4096, 3, 34, -1, 0 ) --> 985812992 (0x3AC25000) SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 77212, 5, 2, 3, 0 )==8287== Reading syms from /sandbox/foo.so (0x3AC27000) --> 985821184 (0x3AC27000) What could be wrong? Thanks Farid |
|
From: Ruibiao Q. <ru...@ar...> - 2005-06-13 17:35:22
|
Hi all
I would like to port the nice valgrind tools to NetBSD i386 platform as the
Google Summer of Code project. What are the issues that I should be
careful with when I port valgrind to NetBSD? Since there is a FreeBSD port
for valgrind-stable-352, I would start with that, and make necessary changes
to fit NetBSD. Any comment/suggestion/feedback is highly appreciated.
Please cc your reply to me as I am not currently on the mailing list now.
Thanks.
/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
Ruibiao Qiu Rui...@wu...
Research Assistant ru...@ar...
Applied Research Laboratory ru...@cs...
Department of Computer Science ru...@co...
and Engineering ru...@ac...
Washington University http://www.arl.wustl.edu/~ruibiao
Campus Box 1045 http://www.cse.wustl.edu/~ruibiao
One Brookings Drive Tel. (314)935-4163
St. Louis, MO 63130-4899, USA Fax (314)935-7302
\____________________________________________________________________/
|
|
From: Farid A. <far...@ho...> - 2005-06-13 15:39:14
|
<html><div style='background-color:'><DIV> <DIV class=RTE>Hi, <BR>I recently switched from valgrind 2.0.0 to valgrind 2.4.0.</DIV> <DIV class=RTE>when I start valgrind with the following options:<BR> valgrind --skin=none --trace-syscalls=yes -v MyProgram</DIV> <DIV class=RTE>valgrind works fine in version 2.0.0 but loading the dynamic libraries at startup takes a long long time to load in verion 2.4.0 (some dynamic libraries took around 4 minutes each to load. Also system calls which did not show in 2.0.0 are now showing in 2.4.0.</DIV> <DIV class=RTE>For example in Valgrind 2.0.0 I will get </DIV> <DIV class=RTE>==8927== Reading syms from /sanbox/foo.so</DIV> <DIV class=RTE>but in Valgrind 2.4.0 I will get something like the following and then a long pause for most dynamic libraries</DIV> <DIV class=RTE> --> 985698304 (0x3AC09000)<BR>SYSCALL[8287,1](125):sys_mprotect ( 0x3AC20000, 13224, 0 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x3AC20000, 16384, 3, 18, 3, 90112 ) --> 985792512 (0x3AC20000)<BR>SYSCALL[8287,1]( 6):sys_close ( 3 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 5) mayBlock:sys_open ( 0xAFEFD4BC(/sandbox/foo.so), 0 ) --> ...<BR>SYSCALL[8287,1]( 5) --> 3 (0x3)<BR>SYSCALL[8287,1]( 3) mayBlock:sys_read ( 3, 0xAFEFD694, 1024 ) --> ...<BR>SYSCALL[8287,1]( 3) --> 1024 (0x400)<BR>SYSCALL[8287,1](197):sys_fstat64 ( 3, 0xAFEFD5C4 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 4096, 3, 34, -1, 0 ) --> 985812992 (0x3AC25000)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 77212, 5, 2, 3, 0 )==8287== Reading syms from /sandbox/foo.so (0x3AC27000)<BR> --> 985821184 (0x3AC27000)</DIV> <DIV class=RTE><BR>What could be wrong?<BR>Thanks<BR>Farid</DIV></DIV></div></html> |
|
From: Farid A. <far...@ho...> - 2005-06-13 15:37:46
|
<html><div style='background-color:'><DIV class=RTE>Hi, <BR>I recently switched from valgrind 2.0.0 to valgrind 2.4.0.</DIV> <DIV class=RTE>when I start valgrind with the following options:<BR> valgrind --skin=none --trace-syscalls=yes -v MyProgram</DIV> <DIV class=RTE>valgrind works fine in version 2.0.0 but loading the dynamic libraries at startup takes a long long time to load in verion 2.4.0 (some dynamic libraries took around 4 minutes each to load. Also system calls which did not show in 2.0.0 are now showing in 2.4.0.</DIV> <DIV class=RTE>For example in Valgrind 2.0.0 I will get </DIV> <DIV class=RTE>==8927== Reading syms from /sanbox/foo.so</DIV> <DIV class=RTE>but in Valgrind 2.4.0 I will get something like the following and then a long pause for most dynamic libraries</DIV> <DIV class=RTE> --> 985698304 (0x3AC09000)<BR>SYSCALL[8287,1](125):sys_mprotect ( 0x3AC20000, 13224, 0 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x3AC20000, 16384, 3, 18, 3, 90112 ) --> 985792512 (0x3AC20000)<BR>SYSCALL[8287,1]( 6):sys_close ( 3 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 5) mayBlock:sys_open ( 0xAFEFD4BC(/sandbox/foo.so), 0 ) --> ...<BR>SYSCALL[8287,1]( 5) --> 3 (0x3)<BR>SYSCALL[8287,1]( 3) mayBlock:sys_read ( 3, 0xAFEFD694, 1024 ) --> ...<BR>SYSCALL[8287,1]( 3) --> 1024 (0x400)<BR>SYSCALL[8287,1](197):sys_fstat64 ( 3, 0xAFEFD5C4 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 4096, 3, 34, -1, 0 ) --> 985812992 (0x3AC25000)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 77212, 5, 2, 3, 0 )==8287== Reading syms from /sandbox/foo.so (0x3AC27000)<BR> --> 985821184 (0x3AC27000)</DIV> <DIV class=RTE><BR>What could be wrong?<BR>Thanks<BR>Farid</DIV></div></html> |
|
From: Nicholas N. <nj...@cs...> - 2005-06-12 16:38:51
|
On Tue, 7 Jun 2005, Martin Porter wrote: > I find that vagrind (I am using 2.2.0 on Linux) reports space loss through use > of the curses library. > > --------------------------------------------- > ==4009== Memcheck, a memory error detector for x86-linux. > ==4009== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. > ==4009== Using valgrind-2.2.0, a program supervision framework for x86-linux. > ==4009== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. > ==4009== For more details, rerun with: -v > ==4009== > (terminal is 52 by 99) > ==4009== > ==4009== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) > ==4009== malloc/free: in use at exit: 3267 bytes in 10 blocks. > ==4009== malloc/free: 12 allocs, 2 frees, 3303 bytes allocated. > ==4009== For a detailed leak analysis, rerun with: --leak-check=yes > ==4009== For counts of detected errors, rerun with: -v > --------------------------------------------- > > 1) Is there some way of releasing the space which curses is mallocing > here? I am not aware of any myself, and the little example program > above is more-or-less copied from a textbook. Running with --run-libc-freeres=yes might help, but might not. > 2) Do I need to worry about the loss of space? Probably not. Lots of programs don't bother freeing dynamically allocated memory that is used right until the program's end. Use --leak-check=yes if you want to know about genuine memory leaks. N |
|
From: Nicholas N. <nj...@cs...> - 2005-06-11 23:53:56
|
On Sat, 11 Jun 2005, Guilhem Bichot wrote: > But after > cd vex && make clean version all > finishes, we are left in vex/, so "cd valgrind" will not work. > I suggest > cd ../valgrind Done, thanks. N |
|
From: Guilhem B. <gu...@my...> - 2005-06-11 21:10:41
|
Hello, http://valgrind.org/devel/cvs_svn.html reads: To check out code on the 3.0 line (anonymous, read-only SVN access), proceed as follows. Note that the 3.0 line has been split into two pieces: Vex, a library that provides dynamic translation services, and Valgrind proper. You need both pieces. Do this: svn co svn://svn.valgrind.org/vex/trunk vex svn co svn://svn.valgrind.org/valgrind/trunk valgrind cd vex && make clean version all cd valgrind ./autogen.sh ./configure --prefix=... --with-vex=/path/to/vex make install But after cd vex && make clean version all finishes, we are left in vex/, so "cd valgrind" will not work. I suggest cd ../valgrind or (cd vex && make clean version all) |
|
From: Jesper O. <jes...@gm...> - 2005-06-11 04:47:44
|
On 6/10/05, James Begley <ja...@ha...> wrote: >=20 > On Fri, 2005-06-10 at 16:50 +0300, Jesper Olsen wrote: > > On 6/10/05, Nicholas Nethercote <nj...@cs...> wrote: > > On Sun, 5 Jun 2005, Jesper Olsen wrote: > > > When I invoke valgrind, the output (a lot of it) seems to be > > > correct, but the line numbers are missing. How come? >=20 > Do you have any spaces in the path to the executable? I seem to > remember that this can confuse valgrind. If the KDE Bugzilla was No, not if I understand you correctly. The executable is in the current=20 directory: valgrind ./a.out -Jesper |
|
From: Nicholas N. <nj...@cs...> - 2005-06-10 18:47:07
|
On Fri, 10 Jun 2005, Beorn Johnson wrote: > By the way, I also changed VG_NTHREAD_KEYS, but I never understood what that > was really doing. Is that not necessary? Or, could it be harmful (other than > performance)? As of 2.4.0 it's no longer used. (In the 3.0 repository it's been removed.) N |
|
From: Beorn J. <beo...@ya...> - 2005-06-10 17:06:05
|
> > The default pthread count limit of 100 is not suffcient for this > > application ( The VG_N_THREADS constant ). So I increased VG_N_THREADS > > to 200 and > > re-build valgrind. Now when I run, pthread_create returns an error - > > errno is set to "Insuffcient Memory" (or something like that). Anyway, > > I was wondering > > if I had to increase some other constant if I increase VG_N_THREADS? > > Its seems that I can only create 110 threads before I get the > > pthread_create to fail. I found a similar problem, but I could cure it by lowering the thread stack size with "pthread_attr_setstacksize"; this was not documented on the version of linux I was using (RedHat/Fedora). The default stack size is 1M, I think. By the way, I also changed VG_NTHREAD_KEYS, but I never understood what that was really doing. Is that not necessary? Or, could it be harmful (other than performance)? __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html |
|
From: James B. <ja...@ha...> - 2005-06-10 14:08:25
|
On Fri, 2005-06-10 at 16:50 +0300, Jesper Olsen wrote: > On 6/10/05, Nicholas Nethercote <nj...@cs...> wrote: > On Sun, 5 Jun 2005, Jesper Olsen wrote: > > When I invoke valgrind, the output (a lot of it) seems to be > > correct, but the line numbers are missing. How come? Do you have any spaces in the path to the executable? I seem to remember that this can confuse valgrind. If the KDE Bugzilla was working at the moment I could point you to the bug number for this ... Cheers, James. |
|
From: Jesper O. <jes...@gm...> - 2005-06-10 13:50:50
|
On 6/10/05, Nicholas Nethercote <nj...@cs...> wrote: >=20 > On Sun, 5 Jun 2005, Jesper Olsen wrote: >=20 > > When I invoke valgrind, the output (a lot of it) seems to be correct, > > but the line numbers are missing. How come? > > >=20 Thanks for taking a look at this Nicholas. In my first post I only quoted part of the output from valgrind - below is= =20 the whole thing, which on my system seems to be more verbose than it should be... -Jesper % uname -a Linux jesperolsen.co.uk <http://jesperolsen.co.uk>=20 2.4.20-021stab028.3.777-enterprise #1 SMP Wed Feb 2 21:08:59 MSK 2005 i686= =20 i686 i386 GNU/Linux % nm a.out 08049424 D _DYNAMIC 08049500 D _GLOBAL_OFFSET_TABLE_ 08048410 R _IO_stdin_used w _Jv_RegisterClasses 080494f0 d __CTOR_END__ 080494ec d __CTOR_LIST__ 080494f8 d __DTOR_END__ 080494f4 d __DTOR_LIST__ 08048414 r __EH_FRAME_BEGIN__ 08048414 r __FRAME_END__ 080494fc d __JCR_END__ 080494fc d __JCR_LIST__ 08049518 A __bss_start 08049418 D __data_start 080483cc t __do_global_ctors_aux 080482c0 t __do_global_dtors_aux 0804941c D __dso_handle 08049418 A __fini_array_end 08049418 A __fini_array_start w __gmon_start__ 08049418 A __init_array_end 08049418 A __init_array_start 08048398 T __libc_csu_fini 08048368 T __libc_csu_init U __libc_start_main@@GLIBC_2.0 08049518 A _edata 0804951c A _end 080483f0 T _fini 0804840c R _fp_hw 08048230 T _init 08048278 T _start 0804829c t call_gmon_start 08049518 b completed.1 08049418 W data_start 08048328 T f 080482fc t frame_dummy 0804834c T main U malloc@@GLIBC_2.0 08049420 d p.0 % valgrind a.out =3D=3D10076=3D=3D Memcheck, a memory error detector for x86-linux. =3D=3D10076=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D10076=3D=3D Using valgrind-2.4.0, a program supervision framework for= =20 x86-linux. =3D=3D10076=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D10076=3D=3D For more details, rerun with: -v =3D=3D10076=3D=3D =3D=3D10076=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D10076=3D=3D at 0x1B8ECD05: ??? =3D=3D10076=3D=3D by 0x1B8E542F: ??? =3D=3D10076=3D=3D by 0x1B8F0BEF: ??? =3D=3D10076=3D=3D by 0x1B8E4CF4: ??? =3D=3D10076=3D=3D by 0x1B8E4A86: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D10076=3D=3D at 0x1B8ECD4F: ??? =3D=3D10076=3D=3D by 0x1B8E542F: ??? =3D=3D10076=3D=3D by 0x1B8F0BEF: ??? =3D=3D10076=3D=3D by 0x1B8E4CF4: ??? =3D=3D10076=3D=3D by 0x1B8E4A86: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D10076=3D=3D at 0x1B8EC54A: ??? =3D=3D10076=3D=3D by 0x1B8ECBF1: ??? =3D=3D10076=3D=3D by 0x1B8E546B: ??? =3D=3D10076=3D=3D by 0x1B8F0BEF: ??? =3D=3D10076=3D=3D by 0x1B8E4CF4: ??? =3D=3D10076=3D=3D by 0x1B8E4A86: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D10076=3D=3D at 0x1B8EC54E: ??? =3D=3D10076=3D=3D by 0x1B8ECBF1: ??? =3D=3D10076=3D=3D by 0x1B8E546B: ??? =3D=3D10076=3D=3D by 0x1B8F0BEF: ??? =3D=3D10076=3D=3D by 0x1B8E4CF4: ??? =3D=3D10076=3D=3D by 0x1B8E4A86: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D10076=3D=3D at 0x1B8ECD4F: ??? =3D=3D10076=3D=3D by 0x1B8E546B: ??? =3D=3D10076=3D=3D by 0x1B8F0BEF: ??? =3D=3D10076=3D=3D by 0x1B8E4CF4: ??? =3D=3D10076=3D=3D by 0x1B8E4A86: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D Invalid write of size 4 =3D=3D10076=3D=3D at 0x8048344: ??? =3D=3D10076=3D=3D by 0x8048360: ??? =3D=3D10076=3D=3D by 0x1B91F62C: __libc_start_main (in /lib/libc-2.3.2.so<http://2.3.2.so> ) =3D=3D10076=3D=3D by 0x8048298: ??? =3D=3D10076=3D=3D Address 0x1BA38050 is 0 bytes after a block of size 40 al= loc'd =3D=3D10076=3D=3D at 0x1B900534: malloc (vg_replace_malloc.c:130) =3D=3D10076=3D=3D by 0x8048337: ??? =3D=3D10076=3D=3D by 0x8048360: ??? =3D=3D10076=3D=3D by 0x1B91F62C: __libc_start_main (in /lib/libc-2.3.2.so<http://2.3.2.so> ) =3D=3D10076=3D=3D by 0x8048298: ??? =3D=3D10076=3D=3D =3D=3D10076=3D=3D ERROR SUMMARY: 14 errors from 6 contexts (suppressed: 0 f= rom 0) =3D=3D10076=3D=3D malloc/free: in use at exit: 40 bytes in 1 blocks. =3D=3D10076=3D=3D malloc/free: 1 allocs, 0 frees, 40 bytes allocated. =3D=3D10076=3D=3D For counts of detected errors, rerun with: -v =3D=3D10076=3D=3D searching for pointers to 1 not-freed blocks. =3D=3D10076=3D=3D checked 57344 bytes. =3D=3D10076=3D=3D =3D=3D10076=3D=3D LEAK SUMMARY: =3D=3D10076=3D=3D definitely lost: 40 bytes in 1 blocks. =3D=3D10076=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D10076=3D=3D still reachable: 0 bytes in 0 blocks. =3D=3D10076=3D=3D suppressed: 0 bytes in 0 blocks. =3D=3D10076=3D=3D Use --leak-check=3Dfull to see details of leaked memory. |
|
From: Nicholas N. <nj...@cs...> - 2005-06-10 13:05:58
|
On Fri, 10 Jun 2005, Ed Hourigan wrote: > I have a legacy application which uses a lot of threads ( its designer > used thread pools ). I am try to run valgrind 2.4.0 to check for memory > leaks. > The default pthread count limit of 100 is not suffcient for this > application ( The VG_N_THREADS constant ). So I increased VG_N_THREADS > to 200 and > re-build valgrind. Now when I run, pthread_create returns an error - > errno is set to "Insuffcient Memory" (or something like that). Anyway, > I was wondering > if I had to increase some other constant if I increase VG_N_THREADS? > Its seems that I can only create 110 threads before I get the > pthread_create to fail. AFAIK increasing VG_N_THREADS should be enough. Can you provide us with a test case program? Nick |
|
From: Ed H. <ed...@em...> - 2005-06-10 12:36:43
|
I have a legacy application which uses a lot of threads ( its designer used thread pools ). I am try to run valgrind 2.4.0 to check for memory leaks. The default pthread count limit of 100 is not suffcient for this application ( The VG_N_THREADS constant ). So I increased VG_N_THREADS to 200 and re-build valgrind. Now when I run, pthread_create returns an error - errno is set to "Insuffcient Memory" (or something like that). Anyway, I was wondering if I had to increase some other constant if I increase VG_N_THREADS? Its seems that I can only create 110 threads before I get the pthread_create to fail. System: Linux 2.6.10 kernel Fedora Core 2 distribution Thank you. _____ |
|
From: Ludovic D. <ld...@li...> - 2005-06-10 10:09:18
|
Dennis Lubert wrote: > Am Freitag, den 10.06.2005, 10:38 +0200 schrieb Ludovic Drolez: > >>Paul Pluzhnikov wrote: >> >>>On 6/9/05, Ludovic Drolez <ld...@li...> wrote: >>> >>> >>>>So it seems to say that pthread_create tried to use a freed block and that this >>>>block has been freed at tftpd.c:736 ? >>> >>> >>>Yes. The bug is as follows: >>> >>> new = calloc(1, sizeof(thread_data)); ... >>> pthread_create(&new->tid, ..., new); >>> >>>At this point it is indeterminate which thread goes first -- the >>>"current" one or the "new" one. If the "new" thread runs to >>>*completion* (including the free(data) on line 736) *before* the >>>"current" thread had a chance to write new->tid, then you'll have >>>the bug which VG cought for you: writing to now dangling memory. >>> >> >>Yes but, new->tid is malloc'd for each new thread, it's not shared. >>So for example, the "new" thread cannot free the memory calloc'd for the >>"current" thread... >> > > It is shared, since pthread_create writes the new->tid field in the > *current* thread, not in the spawned one (where it might be freed() > before the *current* thread comes to run again) Ok, now I understand. I thought that the 1st thing that pthread_create() did, was to assign a value to new->tid. But you say that it might work like this: pthread_create(...): clone() in my thread : free(new) new->tid = segfault So, we should never allocate memory for new->tid to fix this bug. Many thanks for your valuable explanations ! Cheers, -- Ludovic DROLEZ Linbox / Free&ALter Soft www.linbox.com www.linbox.org tel: +33 3 87 50 87 90 152 rue de Grigy - Technopole Metz 2000 57070 METZ |
|
From: Dennis L. <pla...@in...> - 2005-06-10 09:09:12
|
Am Freitag, den 10.06.2005, 10:38 +0200 schrieb Ludovic Drolez: > Paul Pluzhnikov wrote: > > On 6/9/05, Ludovic Drolez <ld...@li...> wrote: > > > >>So it seems to say that pthread_create tried to use a freed block and that this > >>block has been freed at tftpd.c:736 ? > > > > > > Yes. The bug is as follows: > > > > new = calloc(1, sizeof(thread_data)); ... > > pthread_create(&new->tid, ..., new); > > > > At this point it is indeterminate which thread goes first -- the > > "current" one or the "new" one. If the "new" thread runs to > > *completion* (including the free(data) on line 736) *before* the > > "current" thread had a chance to write new->tid, then you'll have > > the bug which VG cought for you: writing to now dangling memory. > > > > Yes but, new->tid is malloc'd for each new thread, it's not shared. > So for example, the "new" thread cannot free the memory calloc'd for the > "current" thread... > It is shared, since pthread_create writes the new->tid field in the *current* thread, not in the spawned one (where it might be freed() before the *current* thread comes to run again) > Cheers, |
|
From: Ludovic D. <lud...@li...> - 2005-06-10 08:39:06
|
Paul Pluzhnikov wrote: > On 6/9/05, Ludovic Drolez <ld...@li...> wrote: > >>So it seems to say that pthread_create tried to use a freed block and that this >>block has been freed at tftpd.c:736 ? > > > Yes. The bug is as follows: > > new = calloc(1, sizeof(thread_data)); ... > pthread_create(&new->tid, ..., new); > > At this point it is indeterminate which thread goes first -- the > "current" one or the "new" one. If the "new" thread runs to > *completion* (including the free(data) on line 736) *before* the > "current" thread had a chance to write new->tid, then you'll have > the bug which VG cought for you: writing to now dangling memory. > Yes but, new->tid is malloc'd for each new thread, it's not shared. So for example, the "new" thread cannot free the memory calloc'd for the "current" thread... Cheers, -- Ludovic DROLEZ |
|
From: Nicholas N. <nj...@cs...> - 2005-06-10 04:41:47
|
On Sun, 5 Jun 2005, Jesper Olsen wrote: > When I invoke valgrind, the output (a lot of it) seems to be correct, > but the line numbers are missing. How come? > > % valgrind a.out > <quote> > ==7772== Invalid write of size 4 > ==7772== at 0x8048489: ??? > ==7772== by 0x80484AA: ??? > ==7772== by 0x1B91F62C: __libc_start_main (in > /lib/libc-2.3.2.so<http://2.3.2.so> > ) > ==7772== by 0x8048398: ??? > ==7772== Address 0x1BA384F0 is 0 bytes after a block of size 40 alloc'd > ==7772== at 0x1B900534: malloc (vg_replace_malloc.c:130) > ==7772== by 0x804847C: ??? > ==7772== by 0x80484AA: ??? > ==7772== by 0x1B91F62C: __libc_start_main (in > /lib/libc-2.3.2.so<http://2.3.2.so> > ) > ==7772== by 0x8048398: ??? > </quote> Valgrind is unable to find any debug/symbol information here, not even module names. That sometimes happens when a shared object is unloaded, but that shouldn't happen in this case. What does the output of "nm a.out" look like? N |
|
From: Paul P. <ppl...@gm...> - 2005-06-09 18:49:00
|
On 6/9/05, Ludovic Drolez <ld...@li...> wrote: >=20 > So it seems to say that pthread_create tried to use a freed block and tha= t this > block has been freed at tftpd.c:736 ? Yes. The bug is as follows: new =3D calloc(1, sizeof(thread_data)); ... pthread_create(&new->tid, ..., new);=20 At this point it is indeterminate which thread goes first -- the "current" one or the "new" one. If the "new" thread runs to *completion* (including the free(data) on line 736) *before* the "current" thread had a chance to write new->tid, then you'll have the bug which VG cought for you: writing to now dangling memory. Cheers, |
|
From: Scott L. <sc...@sw...> - 2005-06-09 16:31:00
|
Nicholas Nethercote wrote: > On Thu, 9 Jun 2005, Scott Long wrote: >> As I said in my original post, I don't think this is a problem. Pick >> one arbitrarily (to make it simple, just use the most recent). The >> developer will fix that error. Memcheck is run again, and now the next >> error is reported. In nearly all realistic cases, only a few >> uninitialized values will be involved. > > > It sounds to me like a good compromise. Patches are welcome! I'd love to, but it'll take me weeks to rummage through the code enough to understand the right way to do it. I'll come back to this the next time I have enough free time, but I will need some help identifying the proper places to make the changes. Please note that I am simply offering an idea, not making demands. There's too much of that crap going around... -- Scott Long <sc...@sw...> Software Engineer SwiftView, Inc. (971) 223-2639 |
|
From: Nicholas N. <nj...@cs...> - 2005-06-09 16:26:28
|
On Thu, 9 Jun 2005, Scott Long wrote: >> It sounds like it needs potentially unbounded storage associated with >> each register in order to work. Supposing a register r contains the >> sum of values from a large range of memory locations, some of which >> are defined and some are undefined. How do you choose which of the >> undefined locations to tag the register with? > > As I said in my original post, I don't think this is a problem. Pick one > arbitrarily (to make it simple, just use the most recent). The developer will > fix that error. Memcheck is run again, and now the next error is reported. In > nearly all realistic cases, only a few uninitialized values will be involved. It sounds to me like a good compromise. Patches are welcome! N |
|
From: Scott L. <sc...@sw...> - 2005-06-09 16:07:12
|
Julian Seward wrote: > It sounds like it needs potentially unbounded storage associated with > each register in order to work. Supposing a register r contains the > sum of values from a large range of memory locations, some of which > are defined and some are undefined. How do you choose which of the > undefined locations to tag the register with? As I said in my original post, I don't think this is a problem. Pick one arbitrarily (to make it simple, just use the most recent). The developer will fix that error. Memcheck is run again, and now the next error is reported. In nearly all realistic cases, only a few uninitialized values will be involved. But consider this extreme case: int uninitialized_array[10000]; int sum = 0; for(i = 0; i < 10000; i++) sum += uninitialized_array[i]; do_something(sum); Obviously, fixing each uninitialized value one at a time will take aeons. However, an intelligent developer will spot the pattern and fix the general error (which is that the entire array is uninitialized). I really can't see any problems with this approach. -- Scott Long <sc...@sw...> Software Engineer SwiftView, Inc. (971) 223-2639 |
|
From: Julian S. <js...@ac...> - 2005-06-09 15:56:03
|
> So is there any comment on my idea, here? Let each register track the > last memory location it was loaded from, and report that location if the > uninitialized register is used. > > If there is something fundamental that makes that idea unfeasible I'd be > very interested to hear what it is. As far as I can tell, it's a good > solution which would avoid false positives and would probably be trivial > to implement. It sounds like it needs potentially unbounded storage associated with each register in order to work. Supposing a register r contains the sum of values from a large range of memory locations, some of which are defined and some are undefined. How do you choose which of the undefined locations to tag the register with? J |