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
(3) |
|
2
(4) |
3
(5) |
4
(8) |
5
(4) |
6
(2) |
7
(4) |
8
(3) |
|
9
(1) |
10
(6) |
11
|
12
(2) |
13
|
14
|
15
|
|
16
|
17
(6) |
18
(7) |
19
(1) |
20
(14) |
21
(2) |
22
(9) |
|
23
(1) |
24
(8) |
25
(6) |
26
(12) |
27
(24) |
28
(24) |
29
(2) |
|
30
(13) |
31
(4) |
|
|
|
|
|
|
From: Susan M. <sma...@uc...> - 2008-03-17 22:10:09
|
You are totally right! I am so used to only new-ing objects that I forgot about new[]-ing arrays! I am so sorry to have bothered you!! Best, Susan ----- Original Message ----- From: "Julian Seward" <js...@ac...> To: "Susan Margulies" <sma...@uc...>; <val...@li...> Sent: Monday, March 17, 2008 2:37 PM Subject: Re: [Valgrind-users] new/free mismatch question? > >> double *array = new double[my_array_size]; >> >> some_lapack_call(array,....); >> >> delete array; > > I don't know much C++, but I had the impression that if you > allocate with > > T* v = new T [] > > (for some type T) then you need to deallocate with > > delete [] v > > Certainly that's what the relevant regression test, > memcheck/tests/mismatches.cpp seems to suggest. So you need > "delete [] array;" in your code. > > J |
|
From: Julian S. <js...@ac...> - 2008-03-17 21:41:20
|
> double *array = new double[my_array_size]; > > some_lapack_call(array,....); > > delete array; I don't know much C++, but I had the impression that if you allocate with T* v = new T [] (for some type T) then you need to deallocate with delete [] v Certainly that's what the relevant regression test, memcheck/tests/mismatches.cpp seems to suggest. So you need "delete [] array;" in your code. J |
|
From: Dan K. <da...@ke...> - 2008-03-17 21:28:17
|
On Mon, Mar 17, 2008 at 2:26 PM, Susan Margulies <sma...@uc...> wrote: > Hello, everyone! I have a question. I have a C++ program which calls into > LAPACK for certain linear operations. I had been doing something like: > > double *array = new double[my_array_size]; > > some_lapack_call(array,....); > > delete array; > > When I ran valgrind, I was getting new/free mismatch errors. Perhaps because you should have written delete[] array; ? |
|
From: Susan M. <sma...@uc...> - 2008-03-17 21:26:42
|
Hello, everyone! I have a question. I have a C++ program which calls into LAPACK for certain linear operations. I had been doing something like:
double *array = new double[my_array_size];
some_lapack_call(array,....);
delete array;
When I ran valgrind, I was getting new/free mismatch errors. So I assumed that because LAPACK was written in C, perhaps the LAPACK call was doing something malloc/free-ish behind the scenes. So I changed my code to
double *array(NULL);
if ((array = (double *) malloc(my_array_size*sizeof(double))) == NULL) {
...out of memory
}
some_lapack_call(array,....);
free(array);
Then all my valgrind errors went away, no more new/free mismatch errors. I am just curious if this was a legitimate error, that LAPACK as a C library should only have blocks of memory passed to it that have been malloc'd, or if this was sort of an anomolous error that I could have ignored.
I would love to hear thoughts and perspectives!
Thanks,
Susan
|
|
From: Ouyang J. <soy...@gm...> - 2008-03-17 09:49:42
|
Hi, I saw "There is experimental support for AIX 5.3, both 32-bit and 64-bit processes." in valgrind-3.3.0/NEWS. So I tried to compile Valgrind on AIX. After change on LDFLAGS, everything went well. But when I executed valgrind, I got: "./valgrind: can't stat /usr/local/lib/valgrind/ppc64-aix5/memcheck". There are lots of stuffs in /usr/local/lib/valgrind: bash-3.00# pwd /usr/local/lib/valgrind bash-3.00# ls aix5libc.supp glibc-2.5.supp ppc64-aix5 cachegrind-ppc32-aix5 glibc-2.6.supp vgpreload_core-ppc32-aix5.so cachegrind-ppc64-aix5 glibc-2.7.supp vgpreload_core-ppc64-aix5.so callgrind-ppc32-aix5 glibc-2.X-drd.supp vgpreload_exp-drd-ppc32-aix5.so callgrind-ppc64-aix5 helgrind-ppc32-aix5 vgpreload_exp-drd-ppc64-aix5.so default.supp helgrind-ppc64-aix5 vgpreload_exp-omega-ppc32-aix5.so exp-drd-ppc32-aix5 lackey-ppc32-aix5 vgpreload_exp-omega-ppc64-aix5.so exp-drd-ppc64-aix5 lackey-ppc64-aix5 vgpreload_helgrind-ppc32-aix5.so exp-omega-ppc32-aix5 massif-ppc32-aix5 vgpreload_helgrind-ppc64-aix5.so exp-omega-ppc64-aix5 massif-ppc64-aix5 vgpreload_massif-ppc32-aix5.so glibc-2.2-LinuxThreads-helgrind.supp memcheck-ppc32-aix5 vgpreload_massif-ppc64-aix5.so glibc-2.2.supp memcheck-ppc64-aix5 vgpreload_memcheck-ppc32-aix5.so glibc-2.3.supp none-ppc32-aix5 vgpreload_memcheck-ppc64-aix5.so glibc-2.34567-NPTL-helgrind.supp none-ppc64-aix5 xfree-3.supp glibc-2.4.supp ppc32-aix5 xfree-4.supp bash-3.00# oslevel 5.3.0.0 bash-3.00# find ppc64-aix5/ ppc64-aix5/ ppc64-aix5/libcoregrind.a ppc64-aix5/libvex.a Compared to valgrind in linux, there should be memcheck, helgrind, callgrind... in ppc64-aix5? I tried to make a soft link to memcheck-ppc64-aix5/memcheck-ppc64-aix5, it core dumped. What should I do to make it work? Thanks in advance! |
|
From: Julian S. <js...@ac...> - 2008-03-12 10:38:15
|
> Has anyone else come across a symbol problem like this ? Any solution > suggests would be welcome, where I can find my missing symbols ! > valgrind: Possible fix: install glibc's debuginfo package on this > machine. If your distro provides a debuginfo package for glibc, installing that would be the easiest solution. You might also want to file a bug report with whoever provided the distro, to say that shipping a completely stripped ld.so makes Valgrind more or less unusable on this machine. J |
|
From: Jonathan M. <Jon...@ub...> - 2008-03-12 08:40:09
|
Hi,
I've been playing with Valgrind (version 3.3.0) cross compiled for a
PPC32_LINUX target.
I'm hitting an interesting bug when trying to execute Valgrind. I'm
using the following debug flags to find out what is going on. valgrind
-d --trace-redir=yes --trace-symtab=yes .......
It seems that I'm missing a symbol from ld-2.3.5.so, which is provided
by the ELDK library (version 4.1). I don't know if the ELDK library has
its symbols stripped off, but I don't think so, otherwise I assume it
wouldn't see any symbols at all. On a different note, in order to load
Valgrind onto my board, I needed to reduce its size, and hence I
"removed" massif functionality following a similar method to adding a
new tool (but in reverse !).
Has anyone else come across a symbol problem like this ? Any solution
suggests would be welcome, where I can find my missing symbols !
--733:1:debuglog DebugLog system started by Stage 1, level 1 logging
requested
--733:1:launcher tool 'memcheck' requested
--733:1:launcher selected platform 'ppc32-linux'
--733:1:launcher launching
/data/valgrind-3.0.0/lib/valgrind/ppc32-linux/memcheck
--733:1:debuglog DebugLog system started by Stage 2 (main), level 1
logging requested
--733:1:main Welcome to Valgrind version 3.3.0 debug logging
--733:1:main Checking current stack is plausible
--733:1:main Checking initial stack was noted
--733:1:main Starting the address space manager
--733:1:main Address space manager is running
--733:1:main Starting the dynamic memory manager
--733:1:mallocfr newSuperblock at 0x41C4D000 (pszB 4194288) owner
VALGRIND/tool
--733:1:main Dynamic memory manager is running
--733:1:main Getting stage1's name
--733:1:main Get hardware capabilities ...
--733:1:main ... arch = PPC32, hwcaps = ppc32-int-flt-GX
--733:1:main Getting the working directory at startup
--733:1:main ... /opt/ubd
--733:1:main Split up command line
--733:1:main Preprocess command line opts
--733:1:main Create initial image
--733:1:initimg Loading client
--733:1:initimg Setup client env
--733:1:initimg Setup client stack
--733:1:initimg Setup client data (brk) segment
--733:1:main Setup file descriptors
--733:1:main Create fake /proc/<pid>/cmdline
--733:1:main Initialise the tool part 1 (pre_clo_init)
--733:1:main Print help and quit, if requested
--733:1:main Process Valgrind's command line options, setup logging
--733:1:mallocfr newSuperblock at 0x4204D000 (pszB 1048560) owner
VALGRIND/core
--733:1:main Print the preamble...
==733== Memcheck, a memory error detector.
==733== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==733== Using LibVEX rev 1804, a library for dynamic binary translation.
==733== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==733== Using valgrind-3.3.0, a dynamic binary instrumentation
framework.
==733== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==733== For more details, rerun with: -v
==733==
--733:1:main ...finished the preamble
--733:1:main Initialise the tool part 2 (post_clo_init)
--733:1:main Initialise TT/TC
--733:1:main Initialise redirects
--733:1:mallocfr newSuperblock at 0x421C8000 (pszB 1048560) owner
VALGRIND/symtab
--733-- <<
--733-- ------ REDIR STATE after VG_(redir_initialise) ------
--733-- TOPSPECS of soname (hardwired)
--733-- ld.so.1 index
R-> 0x380320d0
--733-- ld.so.1 strcmp
R-> 0x3803205c
--733-- ld.so.1 strlen
R-> 0x38032034
--733-- ------ ACTIVE ------
--733-- >>
--733:1:main Load initial debug info
--733-- Reading syms from /lib/ld-2.3.5.so (0x4000000)
soname=ld.so.1
--733-- svma 0x0000000000, avma 0x0004000000
shoff = 98036, shnum = 21, size = 40, n_vg_oimage = 98876
.dynsym : filea 0x40281D0 .. 0x402840F, vma 0x40001D0 ..
0x400040F
.dynstr : filea 0x4028410 .. 0x402858E, vma 0x4000410 ..
0x400058E
.eh_frame : filea 0x403EA98 .. 0x403EBF7, vma 0x4016A98 ..
0x4016BF7
.got : filea 0x403F2E0 .. 0x403FA17, vma 0x40272E0 ..
0x4027A17
.plt : filea 0x403FE48 .. 0x403FECB, vma 0x4027EB8 ..
0x4027F3B
Reading (ELF, standard) dynamic symbol table (36 entries)
raw symbol [ 1]: LOC SEC : val 0x0004001D20, sz 0 NONAME
raw symbol [ 2]: LOC SEC : val 0x0004013A44, sz 0 NONAME
raw symbol [ 3]: LOC SEC : val 0x0004016A44, sz 0 NONAME
raw symbol [ 4]: LOC SEC : val 0x0004016A98, sz 0 NONAME
raw symbol [ 5]: LOC SEC : val 0x0004026E5C, sz 0 NONAME
raw symbol [ 6]: LOC SEC : val 0x0004027000, sz 0 NONAME
raw symbol [ 7]: LOC SEC : val 0x0004027A18, sz 0 NONAME
raw symbol [ 8]: LOC SEC : val 0x0004027E48, sz 0 NONAME
raw symbol [ 9]: LOC SEC : val 0x0004027F3C, sz 0 NONAME
raw symbol [ 10]: GLO OBJ : val 0x0004027A18, sz 1072 _rtld_global
raw symbol [ 11]: GLO FUN : val 0x000400F050, sz 220
_dl_make_stack_executable
record [ 11]: val 0x000400F050, sz 220
_dl_make_stack_executable
raw symbol [ 12]: GLO OBJ : val 0x0004026F48, sz 4 __libc_stack_end
raw symbol [ 13]: WEA FUN : val 0x000400FEA0, sz 308 __libc_memalign
record [ 13]: val 0x000400FEA0, sz 308 __libc_memalign
raw symbol [ 14]: WEA FUN : val 0x000400FFD4, sz 40 malloc
record [ 14]: val 0x000400FFD4, sz 40 malloc
raw symbol [ 15]: GLO OBJ : val 0x0004000000, sz 0 GLIBC_2.1
raw symbol [ 16]: GLO FUN : val 0x000400EA2C, sz 132
_dl_deallocate_tls
record [ 16]: val 0x000400EA2C, sz 132
_dl_deallocate_tls
raw symbol [ 17]: GLO OBJ : val 0x0004026F44, sz 4
__libc_enable_secure
raw symbol [ 18]: GLO FUN : val 0x000400EB28, sz 832 __tls_get_addr
record [ 18]: val 0x000400EB28, sz 832 __tls_get_addr
raw symbol [ 19]: GLO FUN : val 0x000400E74C, sz 56
_dl_get_tls_static_info
record [ 19]: val 0x000400E74C, sz 56
_dl_get_tls_static_info
raw symbol [ 20]: WEA FUN : val 0x000400FFFC, sz 36 calloc
record [ 20]: val 0x000400FFFC, sz 36 calloc
raw symbol [ 21]: GLO FUN : val 0x000400C5A0, sz 12 _dl_debug_state
record [ 21]: val 0x000400C5A0, sz 12 _dl_debug_state
raw symbol [ 22]: GLO OBJ : val 0x0004026E5C, sz 4 _dl_argv
raw symbol [ 23]: GLO FUN : val 0x000400E838, sz 448
_dl_allocate_tls_init
record [ 23]: val 0x000400E838, sz 448
_dl_allocate_tls_init
raw symbol [ 24]: GLO OBJ : val 0x0004000000, sz 0 GLIBC_2.0
raw symbol [ 25]: GLO OBJ : val 0x0004000000, sz 0 GLIBC_PRIVATE
raw symbol [ 26]: GLO OBJ : val 0x0004026E60, sz 168 _rtld_global_ro
raw symbol [ 27]: WEA FUN : val 0x0004010088, sz 152 realloc
record [ 27]: val 0x0004010088, sz 152 realloc
raw symbol [ 28]: GLO FUN : val 0x000400E61C, sz 184 _dl_tls_setup
record [ 28]: val 0x000400E61C, sz 184 _dl_tls_setup
raw symbol [ 29]: GLO FUN : val 0x0004007C64, sz 440
_dl_rtld_di_serinfo
record [ 29]: val 0x0004007C64, sz 440
_dl_rtld_di_serinfo
raw symbol [ 30]: GLO OBJ : val 0x0004013EA8, sz 14
_dl_out_of_memory
raw symbol [ 31]: GLO FUN : val 0x000400DE8C, sz 768 _dl_mcount
record [ 31]: val 0x000400DE8C, sz 768 _dl_mcount
raw symbol [ 32]: GLO FUN : val 0x000400E9F8, sz 52 _dl_allocate_tls
record [ 32]: val 0x000400E9F8, sz 52 _dl_allocate_tls
raw symbol [ 33]: GLO OBJ : val 0x0004027F58, sz 20 _r_debug
raw symbol [ 34]: GLO OBJ : val 0x0004000000, sz 0 GLIBC_2.3
raw symbol [ 35]: WEA FUN : val 0x0004010020, sz 104 free
record [ 35]: val 0x0004010020, sz 104 free
0 merged
valgrind: Fatal error at startup: a function redirection
valgrind: which is mandatory for this platform-tool combination
valgrind: cannot be set up. Details of the redirection are:
valgrind:
valgrind: A must-be-redirected function
valgrind: whose name matches the pattern: strlen
valgrind: in an object with soname matching: ld.so.1
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld.so.1
valgrind:
valgrind: Possible fix: install glibc's debuginfo package on this
machine.
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
Best Regards,
Jon.
|
|
From: Michael B. <mi...@ob...> - 2008-03-10 21:23:00
|
> -----Original Message----- > From: val...@li... > [mailto:val...@li...] On > Behalf Of Nicholas Nethercote > Yes -- Valgrind's line number reports are entirely dependent > on the debug info added by GCC. > Thanks to both Julian and Nicholas for that confirmation. Analysing the report, I could see that thread->timedwait.tv_sec was the issue, I was just curious about the line number 'jitter'. Regards, MikeB |
|
From: Nicholas N. <nj...@cs...> - 2008-03-10 21:04:50
|
On Mon, 10 Mar 2008, Julian Seward wrote: >> I've copied a small example here to explain further what I mean. From >> the following report, it can be seen that lines 1823 and 1833 are indeed >> conditionals, but line 1851 is actually a printf statement containing >> only a string literal. However, the next line (1852) is a conditional. > > There can sometimes be a small degree of error in the line numbers. > Reading it exactly accurately is not always easy and gcc has been > known to emit bogus line number info, especially at high optimisation > levels. Yes -- Valgrind's line number reports are entirely dependent on the debug info added by GCC. N |
|
From: Nicholas N. <nj...@cs...> - 2008-03-10 20:25:07
|
On Fri, 7 Mar 2008, Robert Walsh wrote: > How about setting and then getting the validity bits? I haven't > looked at the client requests in a while. Is this still possible? It is. At best, that would let you know if you're running Memcheck vs. a non-Memcheck tool. Nick |
|
From: Nicholas N. <nj...@cs...> - 2008-03-10 20:23:52
|
On Sun, 9 Mar 2008, Josef Weidendorfer wrote: >>> It is even more difficult if the child sometimes afterwards does an exec, >>> and VG does follow the new executable. Then, the new log file started after >>> the exec will overwrite the file already written to between fork and exec. >> >> Is that a problem? It might be a little inefficient (although the new flag >> --child-silent-after-fork can help), but I don't see how it would cause a >> correctness problem? > > Lost lines in the log file for sure can be a problem? As the child after > fork has the same PID as the new Valgrind process after exec in this child, > the log file name will be the same. Or am I missing something here? I see. I guess if a fork follows an exec, in practice it will be almost immediate so anything lost would be unimportant? But in general, yes, there's the potential for lost information. Nick |
|
From: Julian S. <js...@ac...> - 2008-03-10 12:14:07
|
> I've copied a small example here to explain further what I mean. From > the following report, it can be seen that lines 1823 and 1833 are indeed > conditionals, but line 1851 is actually a printf statement containing > only a string literal. However, the next line (1852) is a conditional. > > At first, I suspected a synchronization issue between the running code > and the sources, but I've now convinced myself that this is not the case. > > Can anyone explain this behaviour? Am I just doing something stupid? There can sometimes be a small degree of error in the line numbers. Reading it exactly accurately is not always easy and gcc has been known to emit bogus line number info, especially at high optimisation levels. Ideally, code you want to Memcheckify shouldn't be compiled at -O2 or -O3. Also you have no stack traces. Are you compiling with -fomit-frame-pointer? Anyway, the obvious conclusion from looking at these is that thread->timedwait.tv_sec contains an uninitialised value. You might want to figure out where that came from. Finally .. it is important to fix the first reported error first -- error cascades are well known. J |
|
From: Michael B. <mi...@ob...> - 2008-03-10 11:57:43
|
Hi,
I've been asked to look at some intermittent segmentation faults in some
code written by other developers so I decided to run the code under
Valgrind to see if it might reveal any issues. The good(?) news is that
Valgrind does highlight a number of potential issues but I'm not always
able to reconcile the lines that Valgrind reports with the actual lines
in the code.
I've copied a small example here to explain further what I mean. From
the following report, it can be seen that lines 1823 and 1833 are indeed
conditionals, but line 1851 is actually a printf statement containing
only a string literal. However, the next line (1852) is a conditional.
At first, I suspected a synchronization issue between the running code
and the sources, but I've now convinced myself that this is not the case.
Can anyone explain this behaviour? Am I just doing something stupid?
Regards and TIA,
MikeB
Valgrind report:
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x45958F8: Reschedule (scheduling.c:1823)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x4595941: Reschedule (scheduling.c:1833)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x4595951: Reschedule (scheduling.c:1833)
==24033==
==24033== Conditional jump or move depends on uninitialised value(s)
==24033== at 0x45959C0: Reschedule (scheduling.c:1851)
scheduling.c:
1823: if( ( thread->timedwait.tv_sec != 0 )
1824: || ( thread->timedwait.tv_nsec != 0 ) )
1825: {
.
1833: if( ( thread->timedwait.tv_sec < currentTime.tv_sec )
1834: || ( ( thread->timedwait.tv_sec == currentTime.tv_sec )
1835: && ( thread->timedwait.tv_nsec <=
currentTime.tv_nsec)))
.
1851: printf("!!\n");
1852: if(thread->timedwait.tv_sec == 0)
|
|
From: Josef W. <Jos...@gm...> - 2008-03-09 18:42:10
|
On Friday 07 March 2008, Nicholas Nethercote wrote: > On Fri, 7 Mar 2008, Josef Weidendorfer wrote: > > > On Wednesday 05 March 2008, Nicholas Nethercote wrote: > >> ps: Valgrind's main logging mechanism suffers from the same problem, as do > >> Cachegrind and Callgrind. The fix is equally simple for Cachegrind and > >> Callgrind. > > > > Yes. > > There still is an issue here: you get all the counters happening before > > the fork duplicated in the output of the parent and the child. I am not > > sure this is the right thing. > > It probably would be better to clear the counters in the child directly > > after the fork. > > Maybe -- there's two clear possibilities that make sense. It's unclear to > me which is correct. Clearing the counters is more difficult, because it > requires the tool to notice it's been forked. OK, this depends very much on the tool. For profiling tools, clearing the counters is better option. As the output file name contains the child PID, the user would not expect that there is data of the parent included, too. > >> For the core it's more difficult, because the output doesn't happen all in > >> one hit at the end, rather it happens gradually. I guess when a fork > >> happens, if we're logging to file and a %p specifier is present in the > >> --log-file option, then a new logging file should be opened. Sigh. > > > > It is even more difficult if the child sometimes afterwards does an exec, > > and VG does follow the new executable. Then, the new log file started after > > the exec will overwrite the file already written to between fork and exec. > > Is that a problem? It might be a little inefficient (although the new flag > --child-silent-after-fork can help), but I don't see how it would cause a > correctness problem? Lost lines in the log file for sure can be a problem? As the child after fork has the same PID as the new Valgrind process after exec in this child, the log file name will be the same. Or am I missing something here? Josef > > > Hmm... does the log file mechanism concatenate existing files? > > No. > > Nick > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Paul W. <pa...@bl...> - 2008-03-08 14:23:00
|
On Fri, Mar 07, 2008 at 01:07:59PM -0800, Hien Le wrote:
> if(RUNNING_ON_VALGRIND) {
> // code that's easier to leak check
> } else {
> // normal code
> }
Um... I don't know the answer, but doesn't running different code inside
Valgrind to when "live" kind of defeat the point of leak checking...?
--
Paul
|
|
From: Robert W. <rj...@du...> - 2008-03-08 05:05:24
|
How about setting and then getting the validity bits? I haven't looked at the client requests in a while. Is this still possible? Regards, Robert. On Mar 7, 2008, at 8:12 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Fri, 7 Mar 2008, Hien Le wrote: > >> Can the client-request mechanism be used to detect which Valgrind >> tool >> is active? > > Interesting... I don't think so. > > Nick > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2008-03-08 04:12:44
|
On Fri, 7 Mar 2008, Hien Le wrote: > Can the client-request mechanism be used to detect which Valgrind tool > is active? Interesting... I don't think so. Nick |
|
From: Hien Le <Hi...@me...> - 2008-03-07 21:07:55
|
Can the client-request mechanism be used to detect which Valgrind tool
is active?
I'm using client-requests in my source as follows:
if(RUNNING_ON_VALGRIND) {
// code that's easier to leak check
} else {
// normal code
}
The first block gives more accurate MemCheck results but is slow so I'd
like the "normal code" to execute if I'm using Callgrind.
Thanks,
Hien
|
|
From: Nicholas N. <nj...@cs...> - 2008-03-07 20:24:15
|
On Fri, 7 Mar 2008, Andi Kleen wrote: > But I doubt that any CPU you can find in the last 20 years or so > had a 12 cycle L1 latency. Especially not a x86 CPU. That would just be > horrible in performance. I tried Calibrator with an Athlon (K7 model 4) a few years back and got L1/L2 worst-case latencies of 12 cycles and 206 cycles. My understanding is that L1 misses costing ~10 cycles and L2 misses costing ~100 cycles or mroe (both in the worst case) is typical. That's why so much research has been done relating to cache performance. Nick |
|
From: Nicholas N. <nj...@cs...> - 2008-03-07 20:04:55
|
On Fri, 7 Mar 2008, Josef Weidendorfer wrote: > On Wednesday 05 March 2008, Nicholas Nethercote wrote: >> ps: Valgrind's main logging mechanism suffers from the same problem, as do >> Cachegrind and Callgrind. The fix is equally simple for Cachegrind and >> Callgrind. > > Yes. > There still is an issue here: you get all the counters happening before > the fork duplicated in the output of the parent and the child. I am not > sure this is the right thing. > It probably would be better to clear the counters in the child directly > after the fork. Maybe -- there's two clear possibilities that make sense. It's unclear to me which is correct. Clearing the counters is more difficult, because it requires the tool to notice it's been forked. >> For the core it's more difficult, because the output doesn't happen all in >> one hit at the end, rather it happens gradually. I guess when a fork >> happens, if we're logging to file and a %p specifier is present in the >> --log-file option, then a new logging file should be opened. Sigh. > > It is even more difficult if the child sometimes afterwards does an exec, > and VG does follow the new executable. Then, the new log file started after > the exec will overwrite the file already written to between fork and exec. Is that a problem? It might be a little inefficient (although the new flag --child-silent-after-fork can help), but I don't see how it would cause a correctness problem? > Hmm... does the log file mechanism concatenate existing files? No. Nick |
|
From: Mehmet B. <mb...@gm...> - 2008-03-07 18:50:25
|
Calibrator results sound about right to me. Are you looking at a manual for a newer architecture? Because those data sheet values are way too small for old architectures (if only they were correct !!!). For recent architectures, I would believe these values might be correct tough. Just for fun: here's (http://people.cs.vt.edu/~mehmetb/drop/Estimation.pdf) how close I got to estimating performance using HW counter stats. On a second look, I did pretty good :-) X axis is different problem sizes (matrices). Y is the time per problem. The red curve is the baseline. Than I did some optimizations and measured the results (blue curve) and I estimated the expected performance improvements (black curve) by using cache event stats (nothing fancy: time_def = num_event * event_latency). I will appreciate all comments/suggestions... -Memo On Fri, Mar 7, 2008 at 5:58 AM, Andi Kleen <an...@fi...> wrote: > "Mehmet Belgin" <mb...@gm...> writes: > > > (Calibrator estimates for an Athlon machine) > > Assuming you mean a K8, but K7 is similar > > > L1 latency : 12 cycles > > It should be <= 4 cycles actually. > > > L2 latency : 162 cycles > > That looks far too slow. Normally it should be <20 cycles > (minimum 13 cycles) according to data sheets. > > Looks to me like calibrator is not very accurate. > > -Andi > |
|
From: Mehmet B. <mb...@gm...> - 2008-03-06 16:11:49
|
As promised: (Calibrator estimates for an Athlon machine) L1 latency : 12 cycles L2 latency : 162 cycles TLB latency : 28 cycles Note that, while using HW counters, the L2 misses incurred by TLB misses are also counted in the same way as L2 misses due to poor locality. So the value for TLB miss excludes this implicit latency. Thanks, -Memo On Sat, Mar 1, 2008 at 1:10 AM, Mehmet Belgin <mb...@gm...> wrote: > I didn't say there's something wrong with the calibrator. It worked fine > for me to estimate cache miss latencies. I am traveling right now, but will > be happy to share my results (for an athlon machine) when I get back to > home... I really liked the ps graphs it generates, they tell a lot. > -Memo > > > On Fri, Feb 29, 2008 at 6:31 PM, Nicholas Nethercote < > nj...@cs...> wrote: > > > On Fri, 29 Feb 2008, Nguyen Vu Hung wrote: > > > > > Calibrator[1] is a small utility helps finding the relationship > > > between cache miss latency, cycles and performance loss in time[3]. It > > > also has a ( quite out-of-date ) database[2] of tested CPUs. > > > > > > Mehmet, would you share your result? What is wrong with Calibrator ? > > > > Calibrator is good for giving you the worst-case latencies of L1 and L2 > > cache misses. The tricky thing with cache misses is that often machines > > can > > do other stuff while waiting for the cache miss to be serviced. But > > exactly > > how much depends on a lot of factors to do with the exact program being > > run. > > That's why it's so hard to estimate this kind of thing. > > > > Nick > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > |
|
From: Bobby K. <rd...@kr...> - 2008-03-06 13:43:40
|
Hi!
I posted last week about valgrind and excessive complaints about the
network data that my application receives via SSL.
Many thanks to those who posted suggestions. In particular, Christoph
Bartoschek nailed it.
My problem was caused by a combination of uninitialized data in
libcrypto. Previous posts had suggested to re-compile openssl with
-DPURIFY which helped a bit. Christoph also suggested some code mods
to initialize some data in libcrypto/libssl. They were:
1) In bn_rand.c add at line 141: memset(buf, 0, bytes); =20
buf = (unsigned char *)OPENSSL_malloc(bytes);
if (buf == NULL)
{
BNerr(BN_F_BNRAND,ERR_R_MALLOC_FAILURE);
goto err;
}
memset(buf, 0, bytes);
2) bn_mont.c: Initialize tmod variable declared at line 392
memset(&tmod, 0, sizeof(tmod));
Basically, what I think was happening was that the uninitialized data
was essentially polluting (as far as valgrind is concerned) the data I
received because it was derived from or calculated from the various
uninitialized data down in the bowels of libssl/libcrypto.
Adding -DPURIFY and the above code mods nearly eliminated all of the
warnings.
I also temporarily removed the seeding of the PRNG from my app and
that completed the job of eliminating all unnecessary warnings. Now,
the valgrind warnings that do appear are well deserved.
Thanks,
Bobby
|
|
From: Nicholas N. <nj...@cs...> - 2008-03-05 22:23:15
|
On Wed, 5 Mar 2008, Oliver Gerlich wrote: > I have some problems with using Massif 3.3.0 on a process which does some > fork() calls. The process doesn't actually call exec() after forking - the > new long-running child basically does an endless loop with a sleep inside. > Problem is, when running this under Massif, the massif.out.<pid> files seem > to be corrupted: Turns out this is an easy fix, fortunately. Here's the problem: Massif's output, by default, goes to a file called "massif.out.<pid>", where <pid> is its pid. Currently, this file name is determined when Massif starts up. However, when you fork, the child ends up with a different pid, but it (erroneously) inherits the already-determined file name, which uses the parent's pid. As a result, both the parent and the child write to the same file at termination. This can cause file corruption (which you saw) or one process to overwrite the data of the other process (which you also saw). The fix is to determine the output file name at termination, when the file is written, instead of start-up. Then you end up with two massif.out.<pid> files, one for the parent and one for the child. Can you try the attached patch and let me know if it fixes the problem? (And thanks for giving such a detailed and well-explained bug report!) Nick ps: Valgrind's main logging mechanism suffers from the same problem, as do Cachegrind and Callgrind. The fix is equally simple for Cachegrind and Callgrind. For the core it's more difficult, because the output doesn't happen all in one hit at the end, rather it happens gradually. I guess when a fork happens, if we're logging to file and a %p specifier is present in the --log-file option, then a new logging file should be opened. Sigh. |
|
From: Oliver G. <ol...@gm...> - 2008-03-05 14:23:01
|
Hello, I have some problems with using Massif 3.3.0 on a process which does some fork() calls. The process doesn't actually call exec() after forking - the new long-running child basically does an endless loop with a sleep inside. Problem is, when running this under Massif, the massif.out.<pid> files seem to be corrupted: when running ms_print on them, I usually get an error like this: Line 1136: expected "snapshot" line, got: pty The offending part in the file looks like this: ... #----------- snapshot=52 #----------- time=38429472 mem_heap_B=441711 mem_heap_extra_B=34113 mem_stacks_B=0 heap_tree=empty pty #----------- snapshot=53 #----------- ... (line 1136 indeed is the "pty" line). I'm not really interested in the child's memory usage, but this error also prevents to analyze the parent. So I used --trace-children=no and --child-silent-after-fork=yes , but that didn't help (ms_print still fails). I'm somewhat out of ideas... Do you see what is going wrong here? So for testing this, I made a short example app (it's attached) and let it run under Massif. Strangely, it now seems to _only_ notice the 3kb allocated in a child, and it ignores the 60MB allocated in the parent process! Only if I don't fork(), the big allocation is correctly shown. Massif is started with > valgrind --tool=massif --child-silent-after-fork=yes ./vg-massif-children Here's what ms_print gives when fork() is used: > Number of snapshots: 4 > Detailed snapshots: [2 (peak)] > > -------------------------------------------------------------------------------- > n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) > -------------------------------------------------------------------------------- > 0 0 0 0 0 0 > 1 110,003 3,008 3,000 8 0 > 2 116,675 3,008 3,000 8 0 > 99.73% (3,000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. > ->99.73% (3,000B) 0x80485B5: doFork (vg-massif-children.c:27) > ->99.73% (3,000B) 0x80486B6: main (vg-massif-children.c:65) > > -------------------------------------------------------------------------------- > n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) > -------------------------------------------------------------------------------- > 3 116,675 0 0 0 0 Do you have an idea what could cause this sub-problem (ie. that malloc in main process is ignored if there's a fork())? Thanks, Oliver Gerlich |