You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(9) |
2
(15) |
3
|
4
(5) |
5
(2) |
6
(7) |
|
7
(2) |
8
(2) |
9
(7) |
10
(3) |
11
(14) |
12
(4) |
13
|
|
14
(2) |
15
(2) |
16
(6) |
17
(6) |
18
(5) |
19
|
20
|
|
21
(2) |
22
(1) |
23
(4) |
24
(4) |
25
|
26
(1) |
27
(1) |
|
28
(4) |
29
(24) |
30
(4) |
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-11 12:39:26
|
On Thu, 11 Nov 2004, Tom Hughes wrote: > Broadly speaking the memory map under valgrind looks like this: That's a much better explanation... ignore mine; I forgot to mention shadow memory at all. N |
|
From: Tom H. <th...@cy...> - 2004-11-11 12:36:12
|
In message <e34...@ma...>
Jeroen Janssen <jer...@gm...> wrote:
>>> ==6928== Warning: client syscall shmat tried to modify addresses
>>> 0xB0000000-0xB0010000
>>> shmat <at> top: Invalid argument
>>> ==6928==
>>> ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>>You're trying to attach a shared memory segment at an address that is
>>in the part of the address space that valgrind reserves to itself. This
>>won't work.
>
> Ok, that makes sense.. Is there an overview of the address space that
> is available/used under valgrind?
Not really, and it isn't even fixed in the current CVS code as we now
try and load as high up as possible on systems which support position
independent executables. It will also depend on what tool you are using.
Broadly speaking the memory map under valgrind looks like this:
CLIENT_BASE +-------------------------+
| client address space |
: :
: :
| client stack |
client_end +-------------------------+
| redzone |
shadow_base +-------------------------+
| |
: shadow memory for tools :
| (may be 0 sized) |
shadow_end +-------------------------+
valgrind_base +-------------------------+
| kickstart executable |
| valgrind heap vvvvvvvvv| (barely used)
- -
| valgrind .so files |
| and mappings |
- -
| valgrind stack ^^^^^^^^^|
valgrind_last +-------------------------+
: kernel :
The exact position of the boundaries is variable however - the amount
of shadow space will depend on the tool for example. Plus the position
of the final boundary depends on how your kernel was built and how
much space it wants.
In 2.2.0 the value of valgrind_base is fixed based on the assumption
that you have a 3G+1G configuration with 1G of kernel space and 2G of
user space.
The CVS code now tries to adjust valgrind_base based on what the
kernel configuration is and hence where valgrind_last is.
> Btw, note that the program run above is a test program of valgrind
> itself, maybe it can also be 'fixed' to use a "(valgrind) correct"
> shared memory segment?
It does, or at least should do. It seems to work on all my systems.
What version of valgrind are you using when it fails?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-11 12:22:03
|
On Thu, 11 Nov 2004, Jeroen Janssen wrote: > Ok, that makes sense.. Is there an overview of the address space that > is available/used under valgrind? In 2.2.0, the client gets 0x0..0xafffffff, Valgrind gets 0xb0000000..0xbfffffff, the kernel gets 0xc0000000..0xffffffff. In the CVS version, if your system supports position-independent executables, valgrind uses (S-0x10000000)..(S-1), where S is the start of the kernel's memory (usually 0xc0000000, but can be different, even 0xffffffff on some systems. > Btw, note that the program run above is a test program of valgrind > itself, maybe it can also be 'fixed' to use a "(valgrind) correct" > shared memory segment? I'm not sure what you mean, but the test may well be deliberately asking for something that Valgrind cannot provide. N |
|
From: Jeroen J. <jer...@gm...> - 2004-11-11 11:54:06
|
>> ==6928== Warning: client syscall shmat tried to modify addresses >> 0xB0000000-0xB0010000 >> shmat <at> top: Invalid argument >> ==6928== >> ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > >You're trying to attach a shared memory segment at an address that is >in the part of the address space that valgrind reserves to itself. This >won't work. Ok, that makes sense.. Is there an overview of the address space that is available/used under valgrind? Btw, note that the program run above is a test program of valgrind itself, maybe it can also be 'fixed' to use a "(valgrind) correct" shared memory segment? --- Jeroen Janssen |
|
From: Tom H. <th...@cy...> - 2004-11-11 11:18:58
|
In message <e34...@ma...>
Jeroen Janssen <jer...@gm...> wrote:
> ==6928== Coregrind, a rudimentary error detector for x86-linux.
> ==6928== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
> ==6928== Using valgrind-2.2.0, a program supervision framework for x86-linux.
> ==6928== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==6928== For more details, rerun with: -v
> ==6928==
> shmat 0: addr=...
> ==6928== Warning: client syscall shmat tried to modify addresses
> 0xB0000000-0xB0010000
> shmat @ top: Invalid argument
> ==6928==
> ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
You're trying to attach a shared memory segment at an address that is
in the part of the address space that valgrind reserves to itself. This
won't work.
> Does this problem sound familiar to anyone? (I think this might look
> like http://bugs.kde.org/show_bug.cgi?id=79282 but that should have
> already been solved I think).
It is the same as that bug, but that bug is not solved as such - it
was closed as INVALID because there is nothing we can do.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeroen J. <jer...@gm...> - 2004-11-11 11:03:46
|
Hello, I'm trying to run a program that uses shmat (fox example, the valgrind test program as_shm in corecheck\tests). However, I get a valgrind warning and an "Invalid argument" error stopping the program. See below for the valgrind output: ==6928== Coregrind, a rudimentary error detector for x86-linux. ==6928== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==6928== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==6928== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==6928== For more details, rerun with: -v ==6928== shmat 0: addr=... ==6928== Warning: client syscall shmat tried to modify addresses 0xB0000000-0xB0010000 shmat @ top: Invalid argument ==6928== ==6928== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Note that I'm running Suse-9.1. Does this problem sound familiar to anyone? (I think this might look like http://bugs.kde.org/show_bug.cgi?id=79282 but that should have already been solved I think). Best regards, Jeroen Janssen |
|
From: Nicholas N. <nj...@ca...> - 2004-11-11 08:32:46
|
On Wed, 10 Nov 2004, Scott Mills wrote: > It's well documented that Valgrind - cachegrind will slow execution of a > program 20 -- 100x than normal. My question is... > > How is the integrity of the performance metrics (how long was spent in a > certain routine, etc.) preserved with such a slowdown in the execution time? > Does the bulk of the overhead happen after the execution of the target > program? Does the tool compensate for the lag in some way? It varies from tool to tool, but the performance metric integrity is not maintained at all; there is no compensation. The client's original code is transformed, and added instrumentation code is intermingled, sometimes very heavily. So I don't think Valgrind would be much good with real-time apps, for example. If you give more details about why you are asking this question, we might be able to give you more specific information. HTH N |
|
From: Scott M. <sm...@no...> - 2004-11-10 21:21:51
|
Hi, I'm very new to this tool, so forgive me for the basic nature of this question. It's well documented that Valgrind - cachegrind will slow execution of a program 20 -- 100x than normal. My question is... How is the integrity of the performance metrics (how long was spent in a certain routine, etc.) preserved with such a slowdown in the execution time? Does the bulk of the overhead happen after the execution of the target program? Does the tool compensate for the lag in some way? Thx in advance, Scott. |
|
From: Tom H. <th...@cy...> - 2004-11-10 12:04:55
|
In message <1099923616.20931.81.camel@narttu>
Michael Widenius <mo...@my...> wrote:
> The problem is that the test suite creates ands drop a lot of tables
> with a lot of index. In MySQL/MyISAM every active index uses a rw-lock,
> which will overflow the coregrind internal rw-lock table, because this
> doesn't reuse destroyed locks.
>
> The following patch fixes the problem by reusing destroyed locks when
> all locks in the 'rw_remap_orig' array has been used up.
Alternatively you could use the CVS code which no longer uses a fixed
size table of RW locks.
BTW patches/bug fixes are best handled by opening a bug or by sending
mail to the developers list - preferably by opening a bug.
Thanks for the patch,
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Michael W. <mo...@my...> - 2004-11-10 11:24:24
|
Hi!
I found a problem with running valgrind 2.2 with the MySQL test suite.
The problem is that the test suite creates ands drop a lot of tables
with a lot of index. In MySQL/MyISAM every active index uses a rw-lock,
which will overflow the coregrind internal rw-lock table, because this
doesn't reuse destroyed locks.
The following patch fixes the problem by reusing destroyed locks when
all locks in the 'rw_remap_orig' array has been used up.
-----------
*** valgrind-2.2.0/coregrind/vg_libpthread.c Mon Aug 30 00:02:27 2004
--- valgrind-2.2.0-new/coregrind/vg_libpthread.c Mon Nov 8 16:02:29
2004
***************
*** 2918,2924 ****
typedef
struct {
! int initted; /* != 0 --> in use; sanity check only
*/
int prefer_w; /* != 0 --> prefer writer */
int nwait_r; /* # of waiting readers */
int nwait_w; /* # of waiting writers */
--- 2918,2925 ----
typedef
struct {
! /* -1 destroyed, 0 not initialized, 1 in use; sanity check only
*/
! int initted;
int prefer_w; /* != 0 --> prefer writer */
int nwait_r; /* # of waiting readers */
int nwait_w; /* # of waiting writers */
***************
*** 2964,2987 ****
*/
static vg_rwlock_t* rw_remap ( pthread_rwlock_t* orig )
{
! int res, i;
vg_rwlock_t* vg_rwl;
vg_pthread_rwlock_t* vg_orig;
res = __pthread_mutex_lock(&rw_remap_mx);
my_assert(res == 0);
for (i = 0; i < rw_remap_used; i++) {
if (rw_remap_orig[i] == orig)
break;
}
if (i == rw_remap_used) {
if (rw_remap_used == VG_N_RWLOCKS) {
! res = __pthread_mutex_unlock(&rw_remap_mx);
! my_assert(res == 0);
! barf("VG_N_RWLOCKS is too low. Increase and recompile.");
}
! rw_remap_used++;
rw_remap_orig[i] = orig;
rw_remap_new[i].initted = 0;
if (0) printf("allocated rwlock %d\n", i);
--- 2965,2997 ----
*/
static vg_rwlock_t* rw_remap ( pthread_rwlock_t* orig )
{
! int res, i, empty_pos;
vg_rwlock_t* vg_rwl;
vg_pthread_rwlock_t* vg_orig;
res = __pthread_mutex_lock(&rw_remap_mx);
my_assert(res == 0);
+ empty_pos= rw_remap_used;
for (i = 0; i < rw_remap_used; i++) {
if (rw_remap_orig[i] == orig)
break;
+ if (rw_remap_new[i].initted < 0)
+ empty_pos= i; /* Use destroyed mutex
*/
}
if (i == rw_remap_used) {
if (rw_remap_used == VG_N_RWLOCKS) {
! if (empty_pos == rw_remap_used) {
! /* All positions are in use; abort */
! res = __pthread_mutex_unlock(&rw_remap_mx);
! my_assert(res == 0);
! barf("VG_N_RWLOCKS is too low. Increase and recompile.");
! }
! else
! i= empty_pos; /* Reuse found
position */
}
! if (i == rw_remap_used)
! rw_remap_used++;
rw_remap_orig[i] = orig;
rw_remap_new[i].initted = 0;
if (0) printf("allocated rwlock %d\n", i);
***************
*** 3042,3048 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3052,3058 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3076,3082 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3086,3092 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3114,3120 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3124,3130 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3146,3152 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3156,3162 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3174,3180 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3184,3190 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3249,3255 ****
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (!rwl->initted) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
--- 3259,3265 ----
rwl = rw_remap ( orig );
res = __pthread_mutex_lock(&rwl->mx);
my_assert(res == 0);
! if (rwl->initted <= 0) {
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return EINVAL;
***************
*** 3259,3265 ****
my_assert(res == 0);
return EBUSY;
}
! rwl->initted = 0;
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return 0;
--- 3269,3275 ----
my_assert(res == 0);
return EBUSY;
}
! rwl->initted = -1; /* Can be reused */
res = __pthread_mutex_unlock(&rwl->mx);
my_assert(res == 0);
return 0;
--------------
Regards,
Monty
CTO of MySQL AB
|
|
From: Erik T. <er...@th...> - 2004-11-09 13:27:42
|
On Tue, 9 Nov 2004 13:36:01 +0100 Erik Thiele <er...@th...> wrote: okay. after figuring out that i cannot valgrind even a NOP qt program, i looked how the qt-designer was linked (which runs under valgrind) and i manually linked all libs in the same order than this qt-designer. now valgrind seems to run and i see other problems of my own which i have to fix. let me know if any kind of output or report can be of use to you for fixing the valgrind problem |
|
From: Erik T. <er...@th...> - 2004-11-09 12:36:05
|
On Tue, 9 Nov 2004 13:16:56 +0100 Erik Thiele <er...@th...> wrote: > > goofy valgrind # ./autogen.sh > running: aclocal > aclocal: configure.in: 14: macro `AM_PROG_CC_C_O' not found in library okok i fixed that one. now i have: erik@goofy:/goofylocal/erik/coding/mister$ valgrind --version valgrind-2.3.0.CVS but it didn't improve my situation, see: the error with -lpthread: erik@goofy:/goofylocal/erik/coding/mister$ g++ -Wl,-rpath,/usr/qt/3/lib -o zeitterminal main.o -L/usr/qt/3/lib -L/usr/X11R6/lib -lpthread -lqt -lXext -lX11 -lm erik@goofy:/goofylocal/erik/coding/mister$ valgrind --tool=memcheck ./zeitterminal ==24408== Memcheck, a memory error detector for x86-linux. ==24408== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==24408== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==24408== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==24408== For more details, rerun with: -v ==24408== ==24408== Invalid free() / delete / delete[] ==24408== at 0x1B904B4C: free (vg_replace_malloc.c:152) ==24408== by 0x1C2A7D8F: free_mem (in /lib/libc-2.3.4.so) ==24408== by 0x1C2A7AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so) ==24408== by 0x1B8FEC6F: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117) ==24408== Address 0x1C0C9D28 is not stack'd, malloc'd or (recently) free'd ==24408== ==24408== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 65 from 3) ==24408== malloc/free: in use at exit: 675937 bytes in 6605 blocks. ==24408== malloc/free: 86245 allocs, 79641 frees, 4252287 bytes allocated. ==24408== For a detailed leak analysis, rerun with: --leak-check=yes ==24408== For counts of detected errors, rerun with: -v erik@goofy:/goofylocal/erik/coding/mister$ the error without -lpthread: erik@goofy:/goofylocal/erik/coding/mister$ g++ -Wl,-rpath,/usr/qt/3/lib -o zeitterminal main.o -L/usr/qt/3/lib -L/usr/X11R6/lib -lqt -lXext -lX11 -lm erik@goofy:/goofylocal/erik/coding/mister$ valgrind --tool=memcheck ./zeitterminal ==24695== Memcheck, a memory error detector for x86-linux. ==24695== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==24695== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==24695== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==24695== For more details, rerun with: -v ==24695== ==24695== valgrind: vg_libpthread.c:2340 (open64): Assertion `open64_ptr != ((void *)0) && open64_ptr != dlsym(libpthread_handle, "open64")' failed. ==24695== Please report this bug at: valgrind.kde.org ==24695== Invalid free() / delete / delete[] ==24695== at 0x1B904B4C: free (vg_replace_malloc.c:152) ==24695== by 0x1C288D8F: free_mem (in /lib/libc-2.3.4.so) ==24695== by 0x1C288AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so) ==24695== by 0x1B8FEC6F: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117) ==24695== Address 0x1C174AA0 is not stack'd, malloc'd or (recently) free'd ==24695== ==24695== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 59 from 2) ==24695== malloc/free: in use at exit: 701598 bytes in 5604 blocks. ==24695== malloc/free: 70860 allocs, 65257 frees, 3968315 bytes allocated. ==24695== For a detailed leak analysis, rerun with: --leak-check=yes ==24695== For counts of detected errors, rerun with: -v erik@goofy:/goofylocal/erik/coding/mister$ |
|
From: Erik T. <er...@th...> - 2004-11-09 12:17:02
|
On Tue, 09 Nov 2004 09:30:49 +0000
Tom Hughes <th...@cy...> wrote:
> In message <200...@th...>
> Erik Thiele <er...@th...> wrote:
>
> > On Tue, 09 Nov 2004 09:00:27 +0000
> > Tom Hughes <th...@cy...> wrote:
> >
> >> In message <200...@th...>
> >> Erik Thiele <er...@th...> wrote:
> >>
> >> > i dunno know what's going on, but it sais i shall report the problem.
> >> > any clues how i can valgrind my program???
> >>
> >> This is a known problem which I believe is now finally fixed in the
> >> current CVS code.
> >
> > is there a workaround or should i switch to CVS version?
>
> Hard to say - it's very dependent on what version of libc you
> are using and how your program is linked.
>
> If you are using libraries that are linked against libpthread but
> are not linking against libpthread yourself then adding -lpthread to
> your link line may help but there is no guarantee.
ok... now i got autoconf problems with cvs valgrind :)
goofy valgrind # ./autogen.sh
running: aclocal
aclocal: configure.in: 14: macro `AM_PROG_CC_C_O' not found in library
error: while running 'aclocal'
goofy valgrind # aclocal --version
aclocal (GNU automake) 1.4-p6
...
goofy valgrind #
anyway, here is the log of the valgrind-2.2.0 problem which you already
know as you said. maybe it is of help anyway:
erik@goofy:/goofylocal/erik/coding/mister$ cat zeitterminal.pro
TEMPLATE = app
LANGUAGE = C++
CONFIG += moc debug
SOURCES += main.cpp
erik@goofy:/goofylocal/erik/coding/mister$ cat main.cpp
#include <qapplication.h>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
return 0;
}
erik@goofy:/goofylocal/erik/coding/mister$ cat compile.sh
#!/bin/bash
set -e
qmake -o Makefile zeitterminal.pro
make
erik@goofy:/goofylocal/erik/coding/mister$ ./compile.sh
g++ -c -pipe -Wall -W -g -I/usr/qt/3/mkspecs/linux-g++ -I. -I/usr/qt/3/include -o main.o main.cpp
g++ -Wl,-rpath,/usr/qt/3/lib -o zeitterminal main.o -L/usr/qt/3/lib -L/usr/X11R6/lib -lqt -lXext -lX11 -lm
erik@goofy:/goofylocal/erik/coding/mister$ valgrind --tool=memcheck ./zeitterminal
==11822== Memcheck, a memory error detector for x86-linux.
==11822== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==11822== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==11822== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==11822== For more details, rerun with: -v
==11822==
==11822==
valgrind: vg_libpthread.c:2331 (open64): Assertion `open64_ptr != ((void *)0) && open64_ptr != open64' failed.
==11822== Please report this bug at: valgrind.kde.org
==11822== Invalid free() / delete / delete[]
==11822== at 0x1B905460: free (vg_replace_malloc.c:153)
==11822== by 0x1C288D8F: free_mem (in /lib/libc-2.3.4.so)
==11822== by 0x1C288AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so)
==11822== by 0x1B8FEC68: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
==11822== Address 0x1C174AA0 is not stack'd, malloc'd or (recently) free'd
==11822==
==11822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 59 from 2)
==11822== malloc/free: in use at exit: 701562 bytes in 5603 blocks.
==11822== malloc/free: 70859 allocs, 65257 frees, 3968273 bytes allocated.
==11822== For a detailed leak analysis, rerun with: --leak-check=yes
==11822== For counts of detected errors, rerun with: -v
erik@goofy:/goofylocal/erik/coding/mister$ g++ -Wl,-rpath,/usr/qt/3/lib -o zeitterminal main.o -L/usr/qt/3/lib -L/usr/X11R6/lib -lpthread -lqt -lXext -lX11 -lm
erik@goofy:/goofylocal/erik/coding/mister$ valgrind --tool=memcheck ./zeitterminal
==12040== Memcheck, a memory error detector for x86-linux.
==12040== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==12040== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==12040== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==12040== For more details, rerun with: -v
==12040==
==12040== Invalid free() / delete / delete[]
==12040== at 0x1B905460: free (vg_replace_malloc.c:153)
==12040== by 0x1C2B8D8F: free_mem (in /lib/libc-2.3.4.so)
==12040== by 0x1C2B8AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so)
==12040== by 0x1B8FEC68: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
==12040== Address 0x1C0DAD28 is not stack'd, malloc'd or (recently) free'd
==12040==
==12040== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 65 from 3)
==12040== malloc/free: in use at exit: 675765 bytes in 6603 blocks.
==12040== malloc/free: 86243 allocs, 79641 frees, 4252115 bytes allocated.
==12040== For a detailed leak analysis, rerun with: --leak-check=yes
==12040== For counts of detected errors, rerun with: -v
erik@goofy:/goofylocal/erik/coding/mister$ valgrind --version
valgrind-2.2.0
erik@goofy:/goofylocal/erik/coding/mister$ ldd ./zeitterminal
libpthread.so.0 => /lib/libpthread.so.0 (0x4002b000)
libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0x4007c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40733000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40741000)
libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5 (0x40806000)
libm.so.6 => /lib/libm.so.6 (0x408cf000)
libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgcc_s.so.1 (0x408f1000)
libc.so.6 => /lib/libc.so.6 (0x408fa000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libmng.so.1 => /usr/lib/libmng.so.1 (0x40a07000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a49000)
libpng.so.3 => /usr/lib/libpng.so.3 (0x40a65000)
libz.so.1 => /lib/libz.so.1 (0x40a95000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40aa6000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40aae000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40ab6000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x40aba000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x40ac3000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40ad5000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40b3e000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40b64000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40b6d000)
libdl.so.2 => /lib/libdl.so.2 (0x40b83000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40b86000)
erik@goofy:/goofylocal/erik/coding/mister$
|
|
From: Tom H. <th...@cy...> - 2004-11-09 09:31:11
|
In message <200...@th...>
Erik Thiele <er...@th...> wrote:
> On Tue, 09 Nov 2004 09:00:27 +0000
> Tom Hughes <th...@cy...> wrote:
>
>> In message <200...@th...>
>> Erik Thiele <er...@th...> wrote:
>>
>> > i dunno know what's going on, but it sais i shall report the problem.
>> > any clues how i can valgrind my program???
>>
>> This is a known problem which I believe is now finally fixed in the
>> current CVS code.
>
> is there a workaround or should i switch to CVS version?
Hard to say - it's very dependent on what version of libc you
are using and how your program is linked.
If you are using libraries that are linked against libpthread but
are not linking against libpthread yourself then adding -lpthread to
your link line may help but there is no guarantee.
Tom
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Erik T. <er...@th...> - 2004-11-09 09:24:23
|
On Tue, 09 Nov 2004 09:00:27 +0000 Tom Hughes <th...@cy...> wrote: > In message <200...@th...> > Erik Thiele <er...@th...> wrote: > > > i dunno know what's going on, but it sais i shall report the problem. > > any clues how i can valgrind my program??? > > This is a known problem which I believe is now finally fixed in the > current CVS code. is there a workaround or should i switch to CVS version? Erik |
|
From: Tom H. <th...@cy...> - 2004-11-09 09:00:57
|
In message <200...@th...>
Erik Thiele <er...@th...> wrote:
> i dunno know what's going on, but it sais i shall report the problem.
> any clues how i can valgrind my program???
This is a known problem which I believe is now finally fixed in the
current CVS code.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Erik T. <er...@th...> - 2004-11-09 08:40:29
|
hi. i dunno know what's going on, but it sais i shall report the problem. any clues how i can valgrind my program??? cu & thx erik valgrind --tool=memcheck --leak-check=yes -v ./zeitterminal ==11596== Memcheck, a memory error detector for x86-linux. ==11596== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==11596== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==11596== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==11596== Valgrind library directory: /usr/lib/valgrind ==11596== Command line ==11596== ./zeitterminal ==11596== Startup, with flags: ==11596== --tool=memcheck ==11596== --leak-check=yes ==11596== -v ==11596== Contents of /proc/version: ==11596== Linux version 2.4.26-gentoo-r9 (root@goofy) (gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)) #8 Fri Oct 22 16:25:50 CEST 2004 ==11596== Reading syms from /goofylocal/erik/coding/zeitterminal/zeitterminal (0x8048000) ==11596== Reading syms from /lib/ld-2.3.4.so (0x1B8E4000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) ==11596== Reading syms from /lib/ld-2.3.4.so (0xB1000000) ==11596== object doesn't have any debug info ==11596== Reading syms from /lib/libdl-2.3.4.so (0xB102B000) ==11596== Reading syms from /lib/libc-2.3.4.so (0xB102E000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so (0xB123B000) ==11596== Reading suppressions file: /usr/lib/valgrind/default.supp ==11596== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==11596== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==11596== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==11596== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==11596== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==11596== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==11596== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==11596== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==11596== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==11596== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==11596== ==11596== Reading syms from /usr/lib/valgrind/vg_inject.so (0x1B8FE000) ==11596== Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x1B901000) ==11596== TRANSLATE: 0x1B8F4FD0 redirected to 0x1B904530 ==11596== Reading syms from /usr/lib/libldap.so.2.0.130 (0x1B91D000) ==11596== Reading syms from /usr/lib/libsigc-1.2.so.5.0.5 (0x1B94B000) ==11596== Reading syms from /usr/lib/libpq.so.3.1 (0x1B954000) ==11596== Reading syms from /usr/lib/libgmp.so.3.3.3 (0x1B96E000) ==11596== Reading syms from /usr/qt/3/lib/libqt-mt.so.3.3.3 (0x1B99D000) ==11596== Reading syms from /usr/X11R6/lib/libXext.so.6.4 (0x1C055000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libX11.so.6.2 (0x1C064000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5.0.6 (0x1C12A000) ==11596== Reading syms from /lib/libm-2.3.4.so (0x1C1F4000) ==11596== Reading syms from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgcc_s.so.1 (0x1C216000) ==11596== Reading syms from /lib/libc-2.3.4.so (0x1C222000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/liblber.so.2.0.130 (0x1C330000) ==11596== Reading syms from /lib/libresolv-2.3.4.so (0x1C33D000) ==11596== Reading syms from /lib/libdl-2.3.4.so (0x1C34F000) ==11596== Reading syms from /usr/lib/libssl.so.0.9.7 (0x1C353000) ==11596== Reading syms from /usr/lib/libcrypto.so.0.9.7 (0x1C383000) ==11596== Reading syms from /lib/libcrypt-2.3.4.so (0x1C47B000) ==11596== Reading syms from /lib/libnsl-2.3.4.so (0x1C4A8000) ==11596== Reading syms from /usr/lib/valgrind/libpthread.so (0x1C4BD000) ==11596== Reading syms from /usr/lib/libmng.so.1.0.0 (0x1C4ED000) ==11596== Reading syms from /usr/lib/libjpeg.so.62.0.0 (0x1C530000) ==11596== Reading syms from /usr/lib/libpng.so.3.1.2.7 (0x1C54F000) ==11596== Reading syms from /lib/libz.so.1.2.1 (0x1C580000) ==11596== Reading syms from /usr/X11R6/lib/libXi.so.6.0 (0x1C591000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libXrender.so.1.2.2 (0x1C59A000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libXrandr.so.2.0 (0x1C5A3000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libXcursor.so.1.0.2 (0x1C5A8000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libXft.so.2.1.2 (0x1C5B4000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/libfreetype.so.6.3.4 (0x1C5C7000) ==11596== Reading syms from /usr/lib/libfontconfig.so.1.0.4 (0x1C630000) ==11596== Reading syms from /usr/X11R6/lib/libSM.so.6.0 (0x1C657000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/X11R6/lib/libICE.so.6.3 (0x1C661000) ==11596== object doesn't have any debug info ==11596== Reading syms from /usr/lib/libexpat.so.0.5.0 (0x1C67A000) ==11596== TRANSLATE: 0x1C281DB2 redirected to 0x1B904E4C ==11596== TRANSLATE: 0x1C281F64 redirected to 0x1B9053DA ==11596== TRANSLATE: 0x1C285EE0 redirected to 0x1B904740 ==11596== TRANSLATE: 0x1C1CA498 redirected to 0x1B904FDE ==11596== TRANSLATE: 0x1C1CA618 redirected to 0x1B905248 ==11596== TRANSLATE: 0x1C28254F redirected to 0x1B90586A ==11596== TRANSLATE: 0x1C237624 redirected to 0x1C4C5747 ==11596== TRANSLATE: 0x1C1C8A6C redirected to 0x1B905746 ==11596== TRANSLATE: 0x1C1C8A14 redirected to 0x1B905590 ==11596== TRANSLATE: 0x1C282015 redirected to 0x1B90592D ==11596== Reading syms from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 (0x1B90A000) ==11596== object doesn't have any debug info ==11596== TRANSLATE: 0x1C2870A0 redirected to 0x1B904C30 ==11596== TRANSLATE: 0x1B8F5470 redirected to 0x1B904C30 ==11596== valgrind: vg_libpthread.c:2331 (open64): Assertion `open64_ptr != ((void *)0) && open64_ptr != open64' failed. ==11596== Please report this bug at: valgrind.kde.org ==11596== TRANSLATE: 0x1C2E21F4 redirected to 0x1C4C5A05 ==11596== Invalid free() / delete / delete[] ==11596== at 0x1B905460: free (vg_replace_malloc.c:153) ==11596== by 0x1C308D8F: free_mem (in /lib/libc-2.3.4.so) ==11596== by 0x1C308AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so) ==11596== by 0x1B8FEC68: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117) ==11596== Address 0x1C479820 is not stack'd, malloc'd or (recently) free'd ==11596== ==11596== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 79 from 2) ==11596== ==11596== 1 errors in context 1 of 1: ==11596== Invalid free() / delete / delete[] ==11596== at 0x1B905460: free (vg_replace_malloc.c:153) ==11596== by 0x1C308D8F: free_mem (in /lib/libc-2.3.4.so) ==11596== by 0x1C308AA5: __GI___libc_freeres (in /lib/libc-2.3.4.so) ==11596== by 0x1B8FEC68: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117) ==11596== Address 0x1C479820 is not stack'd, malloc'd or (recently) free'd --11596-- --11596-- supp: 2 _dl_relocate_object/dl_open_worker --11596-- supp: 77 dl_relocate_object/dl_main ==11596== ==11596== IN SUMMARY: 1 errors from 1 contexts (suppressed: 79 from 2) ==11596== ==11596== malloc/free: in use at exit: 708752 bytes in 5805 blocks. ==11596== malloc/free: 71059 allocs, 65255 frees, 3975858 bytes allocated. ==11596== ==11596== searching for pointers to 5805 not-freed blocks. ==11596== checked 16811756 bytes. ==11596== ==11596== ==11596== 1600 bytes in 1 blocks are possibly lost in loss record 242 of 262 ==11596== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133) ==11596== by 0x1C1B5056: std::__new_alloc::allocate(unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5.0.6) ==11596== by 0x1C1B4DA8: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5.0.6) ==11596== by 0x1C1B4BEA: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5.0.6) ==11596== ==11596== LEAK SUMMARY: ==11596== definitely lost: 0 bytes in 0 blocks. ==11596== possibly lost: 1600 bytes in 1 blocks. ==11596== still reachable: 706952 bytes in 5803 blocks. ==11596== suppressed: 200 bytes in 1 blocks. ==11596== Reachable blocks (those to which a pointer was found) are not shown. ==11596== To see them, rerun with: --show-reachable=yes --11596-- TT/TC: 0 tc sectors discarded. --11596-- 23361 tt_fast misses. --11596-- translate: new 21749 (354571 -> 4458354; ratio 125:10) --11596-- discard 1 (23 -> 320; ratio 139:10). --11596-- chainings: 13656 chainings, 2 unchainings. --11596-- dispatch: 39850000 jumps (bb entries); of them 7433932 (18%) unchained. --11596-- 1511/181264 major/minor sched events. --11596-- reg-alloc: 4203 t-req-spill, 808803+28308 orig+spill uis, --11596-- 112121 total-reg-rank --11596-- sanity: 1457 cheap, 59 expensive checks. --11596-- ccalls: 87918 C calls, 57% saves+restores avoided (296178 bytes) --11596-- 121860 args, avg 0.89 setup instrs each (26276 bytes) --11596-- 0% clear the stack (263754 bytes) --11596-- 30442 retvals, 33% of reg-reg movs avoided (19518 bytes) |
|
From: Josef W. <Jos...@gm...> - 2004-11-08 12:43:50
|
On Saturday 06 November 2004 13:53, Nicholas Nethercote wrote: > On Sat, 6 Nov 2004, Tom Hughes wrote: > >> I thought valgrind could do coverage testing, but a bit more research > >> led me to believe that I need callgrind to do so. > .... > You can sort of use Cachegrind, and ignore everything except the "Ir" > (instruction read) events -- the annotations will tell you, for every > line, how many instructions were executed for it. Use --show=Ir option to > the cg_annotate script. > > The downsides of this are that it doesn't save coverage information in a > file, so you only get the coverage for a single run of the program. Also, > it doesn't give percentage coverage figures. Callgrind might be able to > do percentages, I can't remember. These are visualization issues: KCachegrind can load multiple files produced by Cachegrind or Callgrind, and adds them up. It also can show percentages, but probably the wrong ones: You want executed instructions related to all instructions for coverage, yes? Josef |
|
From: Josef W. <Jos...@gm...> - 2004-11-08 12:39:11
|
On Saturday 06 November 2004 12:06, Tom Hughes wrote: > In message <200...@fr...> > > Brad Hards <br...@fr...> wrote: > > I thought valgrind could do coverage testing, but a bit more research led > > me to believe that I need callgrind to do so. > > I don't believe there is any valgrind tool for coverage testing at > the moment - it has been suggested but I don't think anybody has > written one. I don't think callgrind will help will it? Cachegrind and Callgrind both only give you some information that some code has been executed, but not how much not-executed code with debug-info exists, i.e. code which should be covered by tests. I thought that gcov could deliver this information (?), but still there is a format conflict then. I once wrote a VG skin outputing static information of executables: The first time it touches a new executable/library, it dumps out a file with all instructions for which debug info exists. I did it this way as it was the simplest for me. See kcachegrind.sf.net/stagrind-0.0.1.tar.gz It is a little hacky, because it uses some function not officially available for VG tools. This could be loaded together with data from cachegrind/callgrind into KCachegrind. To get coverage info, you still need a formula to combine the information, like "percentage of executed to all instructions with debug info". This needs a formula with operator ">", which is unfortunately not supported in current KCachegrind (but should be easy to add). > > At this stage, I can't make callgrind 0.9.9 configure against the current > > CVS (valgrind --version says valgrind-2.3.0.CVS). Everything needed is adding a include path for compilation. But better stay with VG 2.2.0. Josef > I'd suggest sticking with 2.2.0 if you want to use callgrind. There > are a lot of changes going on in CVS at the moment so it's quite likely > that a third party tool like callgrind will have problems building > against it. > > Tom |
|
From: Tom H. <th...@cy...> - 2004-11-07 16:54:04
|
In message <761...@ma...>
Logan Gabriel <log...@gm...> wrote:
> I have come across a strange behaviour in valgrind. It seems that if
> I call strerror_r from a forked process that was spawned in a thread I
> get complaints about an invalid memory access. What is strange is if
> I make the same strerror_r call from outside of the forked process I
> do not get any memory complaints.
>
> ==9878== Thread 2:
> ==9878== Invalid read of size 4
> ==9878== at 0x1B96F272: getenv (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B968779: guess_category_value (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B967D38: __dcigettext (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B9679E4: __dcgettext_internal (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B9BF1C8: strerror_r (in /lib/libc-2.3.2.so)
> ==9878== by 0x8048677: blowup_thread_main (test.c:62)
> ==9878== by 0x1B90B9F0: thread_wrapper (vg_libpthread.c:867)
> ==9878== by 0xB000EF61: do__quit (vg_scheduler.c:1872)
> ==9878== Address 0x52BFEA3C is not stack'd, malloc'd or (recently) free'd
Good grief. You're the third person in as many days to run into this
which is pretty impressive considering this bug has been in the code
forever and only one person has ever reported it before this weekend.
See bug 85625 for my analysis and a patch which I think will fix it.
You might also want to consider whether you really want to be doing
this at all - if you fork in a threaded program and then don't do
an exec then you are leaking the stacks of the other threads in the
child process as they will not be deallocated.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Logan G. <log...@gm...> - 2004-11-07 16:12:11
|
Hello list;
I have come across a strange behaviour in valgrind. It seems that if
I call strerror_r from a forked process that was spawned in a thread I
get complaints about an invalid memory access. What is strange is if
I make the same strerror_r call from outside of the forked process I
do not get any memory complaints.
==9878== Thread 2:
==9878== Invalid read of size 4
==9878== at 0x1B96F272: getenv (in /lib/libc-2.3.2.so)
==9878== by 0x1B968779: guess_category_value (in /lib/libc-2.3.2.so)
==9878== by 0x1B967D38: __dcigettext (in /lib/libc-2.3.2.so)
==9878== by 0x1B9679E4: __dcgettext_internal (in /lib/libc-2.3.2.so)
==9878== by 0x1B9BF1C8: strerror_r (in /lib/libc-2.3.2.so)
==9878== by 0x8048677: blowup_thread_main (test.c:62)
==9878== by 0x1B90B9F0: thread_wrapper (vg_libpthread.c:867)
==9878== by 0xB000EF61: do__quit (vg_scheduler.c:1872)
==9878== Address 0x52BFEA3C is not stack'd, malloc'd or (recently) free'd
I have verified this behaviour on SuSE 9.1 with valgrind 2.0.0 and on
Redhat 8.0 with valgrind 2.2.0. Both produce slightly different, but
more a less the same output.
I have attached a simple program that can reproduce the output on my
system each time.
-- snip --
#define _REENTRANT
#define _THREAD_SAFE
#include <stdio.h>
#include <stdarg.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
void create_blowup_thread (void);
void *blowup_thread_main (void *data);
void
create_blowup_thread(void)
{
int error;
pthread_t dummy_thread_handle;
pthread_attr_t create_detached_attr;
if ((pthread_attr_init(&create_detached_attr)) != 0)
{
printf("Unable to create attr.\n");
exit(EXIT_FAILURE);
}
if ((pthread_attr_setdetachstate(&create_detached_attr,
PTHREAD_CREATE_DETACHED)) != 0)
{
printf("Unable to set detach state.\n");
exit(EXIT_FAILURE);
}
error = pthread_create(&dummy_thread_handle, &create_detached_attr,
blowup_thread_main, NULL);
if (error != 0)
{
printf("Unable to create thread.\n");
exit(EXIT_FAILURE);
}
sleep(5);
exit(EXIT_SUCCESS);
}
void *
blowup_thread_main(data)
void *data;
{
char *buf;
int error;
switch (error = fork())
{
case -1:
printf("Unable to fork.\n");
break;
case 0:
buf = malloc(1024);
strerror_r(2, buf, 1023);
exit(EXIT_SUCCESS);
break;
default:
break;
}
return NULL;
}
int
main(argc, argv)
int argc;
char **argv;
{
create_blowup_thread();
exit(EXIT_SUCCESS);
}
-- snip --
Compile with:
gcc -o test test.c -lpthread -g
|
|
From: Sinan Y. <asm...@ya...> - 2004-11-06 15:10:48
|
Hi! is there a way to disable deadlock detection in valgrind ? ===== __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2004-11-06 12:54:03
|
On Sat, 6 Nov 2004, Tom Hughes wrote: >> I thought valgrind could do coverage testing, but a bit more research led >> me to believe that I need callgrind to do so. > > I don't believe there is any valgrind tool for coverage testing at > the moment - it has been suggested but I don't think anybody has > written one. You can sort of use Cachegrind, and ignore everything except the "Ir" (instruction read) events -- the annotations will tell you, for every line, how many instructions were executed for it. Use --show=Ir option to the cg_annotate script. The downsides of this are that it doesn't save coverage information in a file, so you only get the coverage for a single run of the program. Also, it doesn't give percentage coverage figures. Callgrind might be able to do percentages, I can't remember. N |
|
From: Tom H. <th...@cy...> - 2004-11-06 12:33:43
|
In message <200...@we...>
Sinan YILDIRIM <asm...@ya...> wrote:
> Main thread is executing this code :
> ...
> ...
> delete 2ndThread;
> ...
> ...
>
>
> Our 2nd Thread's destructor is coded like this :
>
> 2ndThread::~2ndThread()
> {
> quit = true;
> sem_wait(wait_sem);
> ...
> ...
> ...
> }
>
> 2nd Thread's thread loop is like this:
>
> 2ndThread::threadMethod()
> {
> while(!quit)
> {
> wait_timer_interrupt();
> ...
> ...
> ...
> }
>
> sem_post(wait_sem);
> pthread_exit();
> }
That code does not appear to be thread safe as you are writing to quit
in one thread and reading from it in another without any kind of locking.
> When i use valgrind for tracing memory leaks, valgrind
> exits my program execution ans gives a warning :
[ snipped ]
> ==3861==
> ==3861== Warning: pthread scheduler exited due to
> deadlock
>
> I couldn't find any deadlock state. Is it possible for
> valgrind to stop interval timers before program exit ?
> Because my 2ndThread is waiting on
> "wait_timer_interrupt()" function and if linux's
> interval timer is stopped by valgrind, there may be a
> deadlock...
It's a bug in valgrind - it doesn't consider signals when deciding
whether the process is deadlocked. The problem is that if you do
consider them then you pretty much have to remove the deadlock
detection altogether as you would only be able to consider the
process as deadlocked if all signals were blocked.
Actually I guess only signals with handlers can break a deadlock
so maybe it isn't that bad.
It's a bug anyway, and you're the second person to mention it
recently so could you please raise a bug for it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sinan Y. <asm...@ya...> - 2004-11-06 11:54:34
|
Hi all,
I have a problem about valgrind scheduler. I'd like to
share it with you and discuss the solutions.
I am using pthreads library. I have created 2 threads
. One of them is the main program thread, the other
one is the thread which was created by the main
program thread.
At program exit, i try to kill the second thread on
main thread scope.
Main thread is executing this code :
...
...
delete 2ndThread;
...
...
Our 2nd Thread's destructor is coded like this :
2ndThread::~2ndThread()
{
quit = true;
sem_wait(wait_sem);
...
...
...
}
2nd Thread's thread loop is like this:
2ndThread::threadMethod()
{
while(!quit)
{
wait_timer_interrupt();
...
...
...
}
sem_post(wait_sem);
pthread_exit();
}
The 2nd thread is a thread that wakes with the timer
events. It wakes every 10 miliseconds. I have used
linux's setitimer for doing this. For setting 10 ms
timer interval ; i coded :
...
...
struct sigaction signal_action;
struct itimerval timer;
memset(&signal_action,0,sizeof(signal_action));
signal_action.sa_handler = (void
(*)(int))timer_handler;
sigaction(SIGALRM,&signal_action,NULL);
timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = TIMER_INTERVAL * 1000 ;
timer.it_interval.tv_sec = 0 ;
timer.it_interval.tv_usec = TIMER_INTERVAL * 1000;
setitimer(ITIMER_REAL,&timer,NULL);
...
...
My timer handler function is :
void timer_handler(U32 signal_no)
{
sem_post(timer_semaphore);
}
And the "wait_timer_interrupt()" function called from
the threadMethod of the 2ndThread is :
void wait_timer_interrupt(void)
{
sem_wait(timer_semaphore);
}
My problem is:
When i use valgrind for tracing memory leaks, valgrind
exits my program execution ans gives a warning :
Thread 1: status = WaitCV, associated_mx = 0x34516160,
associated_cv = 0x34516178
==3861== at 0x34152EC1: pthread_cond_wait
(vg_libpthread.c:1454)
==3861== by 0x34156C6A: sem_wait
(vg_libpthread.c:2769)
==3861== by 0x804B512: bsem_wait (bthread.c:295)
==3861== by 0x80508DE: 2ndThread:.~2ndThread()
(timerthread.cpp:61)
==3861== by 0x804EF44: test_1()
(numerika_test.cpp:36)
==3861== by 0x804F4E3:
test_1__main__Test::TestFunction()
(numerika_test.cpp:94)
==3861== by 0x804BF93:
TestRegistery::runGroup(SimpleString const&)
(testregistery.cpp:138)
==3861== by 0x804C2F6: TestRegistery::runList()
(testregistery.cpp:230)
==3861== by 0x804BCD2: CppEntry (entry.cpp:9)
Thread 2: status = WaitCV, associated_mx = 0x345160E0,
associated_cv = 0x345160F8
==3861== at 0x34152EC1: pthread_cond_wait
(vg_libpthread.c:1454)
==3861== by 0x34156C6A: sem_wait
(vg_libpthread.c:2769)
==3861== by 0x804B512: bsem_wait (bthread.c:295)
==3861== by 0x8049F7F: wait_timer_interrupt
(btimer.c:38)
==3861== by 0x8050C70: 2ndThread::threadMethod()
(timerthread.cpp:183)
==3861== by 0x8050E99:
ThreadRoot::GeneralThreadEntry(void*)
(thread_root.cpp:25)
==3861== by 0x341519F0: thread_wrapper
(vg_libpthread.c:867)
==3861== by 0xB000EF61: do__quit
(vg_scheduler.c:1872)
Thread 3: status = WaitJoiner, associated_mx = 0x0,
associated_cv = 0x0
==3861== at 0x34151772: thread_exit_wrapper
(vg_libpthread.c:745)
==3861== by 0x34151A00: thread_wrapper
(vg_libpthread.c:873)
==3861== by 0xB000EF61: do__quit
(vg_scheduler.c:1872)
==3861==
==3861== Warning: pthread scheduler exited due to
deadlock
I couldn't find any deadlock state. Is it possible for
valgrind to stop interval timers before program exit ?
Because my 2ndThread is waiting on
"wait_timer_interrupt()" function and if linux's
interval timer is stopped by valgrind, there may be a
deadlock...
I couldn't find any solutions...
Waiting for your helps!
Thanks so much!
=====
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
|