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
(5) |
3
(7) |
4
(8) |
5
(3) |
|
6
(2) |
7
|
8
(2) |
9
(20) |
10
(2) |
11
(14) |
12
(21) |
|
13
(6) |
14
(9) |
15
(31) |
16
(7) |
17
(5) |
18
(14) |
19
(3) |
|
20
(6) |
21
(9) |
22
(19) |
23
(14) |
24
(16) |
25
(10) |
26
(3) |
|
27
(2) |
28
(1) |
29
(10) |
30
(6) |
31
(16) |
|
|
|
From: Klint G. <kg...@kg...> - 2005-03-21 22:50:58
|
On Thu, 17 Mar 2005 23:33:22 -0800, Jeremy Fitzhardinge <je...@go...> wrote: > Klint Gore wrote: > > >ok. I got the 2.4.0 rc4 from http://www.goop.org/~jeremy/valgrind/dist/ > >and it gives "segmentation fault" too. > > > >The diagnostics look the same as the original post. Is there anything > >else I can generate to try and find out what's happening? > > > Could you (re)post the full output of your valgrind command (with -v)? > Also, if you can make the binary available, with any non-standard > libraries it needs, available, that would help. attached is version numbers, valgrind output, ldd on program, gbd backtrace, strace. The binary is at http://abri.une.edu.au/staff/klint/hello.bz2 I dont think there are any non standard libraries. If any of the following dont seem to be standard, let me know and I'll add them to the download. The versions for the ldd listed libraries are libNoVersion-2.3.2.so libpthread-0.10.so libdl-2.3.2.so libc-2.3.2.so ld-2.3.2.so thanks, klint. +---------------------------------------+-----------------+ : Klint Gore : "Non rhyming : : EMail : kg...@kg... : slang - the : : Snail : A.B.R.I. : possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---------------------------------------+-----------------+ |
|
From: Nicholas N. <nj...@cs...> - 2005-03-21 15:32:02
|
On Mon, 21 Mar 2005, [iso-8859-1] Fabian M=FCller wrote: > valgrind: vg_libpthread.c:2303 (fcntl): Assertion `fcntl_ptr !=3D ((void = *)0) && fcntl_ptr !=3D fcntl' failed. > > I use valgrind version 2.2.0. Please try valgrind-2.4.0-rc4, at www.goop.org/~jeremy/valgrind/dist, in=20 which this bug has been fixed. N |
|
From: Julian S. <js...@ac...> - 2005-03-21 12:05:13
|
Basically it is a mistake to use MAP_FIXED at all, unless you have complete control of the address space. Which, in almost all programs you don't. A few years ago I worked on a project which did this, and our program started to fail on obscure Linux distros. We realised our mistake and reworked it to get rid of MAP_FIXED. J On Sunday 20 March 2005 16:19, Benny Cheung wrote: > Hi Tom, > > Tom Hughes <tom <at> compton.nu> writes: > > How do you know what address the region will be mapped at? If you're > > trying to use MAP_FIXED to force it then be aware that valgrind will > > fail attempts to map memory at some high addresses as only part of the > > address space is available for your program - some is reserved for > > valgrind to use. > > Yes I did. But after I remove the MAP_FIXED in mmap() the memory > (in 64MB chunks) still cannot be allocated. Maybe I need to change > it back to malloc(). > > > If you're talking about the TRANSLATE line for 0x1B8E4C30 then that > > is a function intercept and is nothing to do with any data access in > > your program. > > I see. That clears my doubt. Thanks a lot! > > > You need to look at how/when multibuff is allocated and what sort of > > memory it is pointing at. > > Turns out multibuff is not needed anyway (it is declared as > struct dsmmsg multibuff[BUFFSLOT] as global and then initialized > at a init function that causes the fault), but I still doubt why > the fault does not happen without using Valgrind. > > Best Regards, > Benny. > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: <mue...@gm...> - 2005-03-21 11:58:11
|
Hello, the error message is: $ valgrind --tool=memcheck ls -l [...] ==9077== Conditional jump or move depends on uninitialised value(s) ==9077== at 0x1B8F3074: strchr (in /lib/ld-2.2.4.so) ==9077== valgrind: vg_libpthread.c:2303 (fcntl): Assertion `fcntl_ptr != ((void *)0) && fcntl_ptr != fcntl' failed. ==9077== Please report this bug at: valgrind.kde.org ==9077== ==9077== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 2) ==9077== malloc/free: in use at exit: 11902 bytes in 7 blocks. ==9077== malloc/free: 10 allocs, 3 frees, 11954 bytes allocated. ==9077== For a detailed leak analysis, rerun with: --leak-check=yes ==9077== For counts of detected errors, rerun with: -v I use valgrind version 2.2.0. My Linux is Linux from Scratch. Kernel Version is 2.4.21. I have libc-2.2.4.so. My Prozessor: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping : 4 cpu MHz : 300.684 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov mmx bogomips : 599.65 Why does the error message show up? Thanx very much in advance for your feedback. Greetings, Fabian Müller |
|
From: Stefan K. <en...@ho...> - 2005-03-21 11:20:19
|
hi, I'd love to link back to valgrind page. so such a picture would be nice. Just one comment, most of this images are 88x32 pixels in size. I don't know why. If contributor could take that into account - it would be much easier to add that to the other images ;) Ciao Stefan -- http://www.buzztard.org > > Hi, > > On the new Valgrind website, we have some pretty artwork, including small > pictures at www.valgrind.org/gallery/artwork.html. That page suggests > using those pictures if you want to link to www.valgrind.org. > Unfortunately, the pictures alone don't tell people very much. What we'd > really like is versions of those pictures with some text that identifies > Valgrind -- eg "www.valgrind.org", or "Checked with Valgrind", or > something like that. > > If you're good at graphics, we'd love you to create such pictures, and send > them in to val...@va.... We'll put the best ones up on that page > at www.valgrind.org, and you can get a warm fuzzy feeling from helping us > spread the word about Valgrind. There aren't any particular rules about > picture sizes, or what text should be on there, or how closely you should > stick to the original pictures -- feel free to use your imagination. > > Another thing that would be cool is a set of icons based on that artwork. > In today's graphical world, having a standard, good set of Valgrind icons > would be very useful. > > More broadly, we'd be interested to see any and all sorts of derivatives > of the artwork. For example, perhaps somebody wants to make a T-shirt > logo? > > If you want copies of the existing artwork at high-resolution, you can > grab them with: > > svn co svn://www.valgrind.org/valgrind-www/images_src > > You'll need to have Subversion installed. > > Be warned that this directory contains 150MB of images, and so the above > command may take some time to complete. Included are a mix of PNG and XCF > (Gimp) format files. > > Also, if anyone is able to convert these pictures into SVG format, we'd > love to have copies. > > Thanks. > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-03-21 00:47:39
|
Hi, On the new Valgrind website, we have some pretty artwork, including small pictures at www.valgrind.org/gallery/artwork.html. That page suggests using those pictures if you want to link to www.valgrind.org. Unfortunately, the pictures alone don't tell people very much. What we'd really like is versions of those pictures with some text that identifies Valgrind -- eg "www.valgrind.org", or "Checked with Valgrind", or something like that. If you're good at graphics, we'd love you to create such pictures, and send them in to val...@va.... We'll put the best ones up on that page at www.valgrind.org, and you can get a warm fuzzy feeling from helping us spread the word about Valgrind. There aren't any particular rules about picture sizes, or what text should be on there, or how closely you should stick to the original pictures -- feel free to use your imagination. Another thing that would be cool is a set of icons based on that artwork. In today's graphical world, having a standard, good set of Valgrind icons would be very useful. More broadly, we'd be interested to see any and all sorts of derivatives of the artwork. For example, perhaps somebody wants to make a T-shirt logo? If you want copies of the existing artwork at high-resolution, you can grab them with: svn co svn://www.valgrind.org/valgrind-www/images_src You'll need to have Subversion installed. Be warned that this directory contains 150MB of images, and so the above command may take some time to complete. Included are a mix of PNG and XCF (Gimp) format files. Also, if anyone is able to convert these pictures into SVG format, we'd love to have copies. Thanks. |
|
From: Benny C. <bwl...@gm...> - 2005-03-20 16:22:02
|
Hi Tom, Tom Hughes <tom <at> compton.nu> writes: > How do you know what address the region will be mapped at? If you're > trying to use MAP_FIXED to force it then be aware that valgrind will > fail attempts to map memory at some high addresses as only part of the > address space is available for your program - some is reserved for > valgrind to use. Yes I did. But after I remove the MAP_FIXED in mmap() the memory (in 64MB chunks) still cannot be allocated. Maybe I need to change it back to malloc(). > If you're talking about the TRANSLATE line for 0x1B8E4C30 then that > is a function intercept and is nothing to do with any data access in > your program. I see. That clears my doubt. Thanks a lot! > You need to look at how/when multibuff is allocated and what sort of > memory it is pointing at. Turns out multibuff is not needed anyway (it is declared as struct dsmmsg multibuff[BUFFSLOT] as global and then initialized at a init function that causes the fault), but I still doubt why the fault does not happen without using Valgrind. Best Regards, Benny. |
|
From: Tom H. <to...@co...> - 2005-03-20 14:52:37
|
In message <loo...@po...>
Benny Cheung <bwl...@gm...> wrote:
> I am trying to use the latest stable version of Valgrind to debug
> my parallel program, which tends to use quite a lot of (virtual)
> memory. The 0x60000000 - 0x90000000 region is allocated using mmap().
How do you know what address the region will be mapped at? If you're
trying to use MAP_FIXED to force it then be aware that valgrind will
fail attempts to map memory at some high addresses as only part of the
address space is available for your program - some is reserved for
valgrind to use.
> My program works to finish for a small problem size without invoking
> the debugger, but having problems on large problem size. However,
> when Valgrind is invoked, I get this error no matter the problem size
> is small or large:
>
> ==21397== TRANSLATE: 0x2129C1D0 redirected to 0x2112C68C
> ==21397== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF040
> start
> ==21397== TRANSLATE: 0x21295080 redirected to 0x2112CCBC
> The file has 4 lines
> ==21397== TRANSLATE: 0x21295200 redirected to 0x2112D1E8
> ID is 0
> ID 0: Hostname is GD033A
> rsh -l benny GD034A "./sor1022 dsmid 1 port 17767 " &
> rsh -l benny GD035A "./sor1022 dsmid 2 port 17767 " &
> rsh -l benny GD036A "./sor1022 dsmid 3 port 17767 " &
> ==21397==
> ==21397== Process terminating with default action of signal 11 (SIGSEGV)
> ==21397== Bad permissions for mapped region at address 0x1B8E9444
> ==21397== at 0x80548B6: comm_init() (dsmcomm.cpp:903)
> ==21397== by 0x8049405: main (dsminit-sor.cpp:121)
> =
>
> The faulting statement is just an initialization of some array structures:
>
> for (i = 0; i < BUFFSLOT; i++)
> multbuff[i].ref = 0;
>
> At running this statement, the region 0x60000000 - 0x90000000 has not been
> mmap() yet.
>
> I'd like to ask is the address 0x1B8E9444 relocated to some place after
> 0x52BFF040 and then got the error? How to avoid this problem, and is it
> possible to manually instruct address redirection destination?
What makes you think 0x1B8E9444 is relocated? As far as I can see
valgrind is saing that your programs tried to write to that location
but that it was mapped read-only.
If you're talking about the TRANSLATE line for 0x1B8E4C30 then that
is a function intercept and is nothing to do with any data access in
your program.
You need to look at how/when multibuff is allocated and what sort of
memory it is pointing at.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Benny C. <bwl...@gm...> - 2005-03-20 13:42:44
|
Dear all, I am trying to use the latest stable version of Valgrind to debug my parallel program, which tends to use quite a lot of (virtual) memory. The 0x60000000 - 0x90000000 region is allocated using mmap(). My program works to finish for a small problem size without invoking the debugger, but having problems on large problem size. However, when Valgrind is invoked, I get this error no matter the problem size is small or large: ==21397== TRANSLATE: 0x2129C1D0 redirected to 0x2112C68C ==21397== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF040 start ==21397== TRANSLATE: 0x21295080 redirected to 0x2112CCBC The file has 4 lines ==21397== TRANSLATE: 0x21295200 redirected to 0x2112D1E8 ID is 0 ID 0: Hostname is GD033A rsh -l benny GD034A "./sor1022 dsmid 1 port 17767 " & rsh -l benny GD035A "./sor1022 dsmid 2 port 17767 " & rsh -l benny GD036A "./sor1022 dsmid 3 port 17767 " & ==21397== ==21397== Process terminating with default action of signal 11 (SIGSEGV) ==21397== Bad permissions for mapped region at address 0x1B8E9444 ==21397== at 0x80548B6: comm_init() (dsmcomm.cpp:903) ==21397== by 0x8049405: main (dsminit-sor.cpp:121) = The faulting statement is just an initialization of some array structures: for (i = 0; i < BUFFSLOT; i++) multbuff[i].ref = 0; At running this statement, the region 0x60000000 - 0x90000000 has not been mmap() yet. I'd like to ask is the address 0x1B8E9444 relocated to some place after 0x52BFF040 and then got the error? How to avoid this problem, and is it possible to manually instruct address redirection destination? Thanks in advance. Best Regards, Benny. |
|
From: Tom H. <to...@co...> - 2005-03-20 12:44:20
|
In message <200...@li...te>
Peter Seiderer <sei...@ci...> wrote:
> The following short test proramm produces a lot of output
> when running under valgrind-2.4.0.rc4 (on debiab-3.0, but similar on
> SuSE-8.2). Is this a valgrind or a libc/libpthread problem?
They are features of the pthread library you are using. The first one
can be suppressed and is for many version of the pthread library but
the supression obviously doesn'y match on your system.
The other's can't really be suppressed because the stack trace isn't
good enough to blame the threading library so any supression would be
far too general.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Peter S. <sei...@ci...> - 2005-03-20 12:20:48
|
The following short test proramm produces a lot of output
when running under valgrind-2.4.0.rc4 (on debiab-3.0, but similar on
SuSE-8.2). Is this a valgrind or a libc/libpthread problem?
#include <stdlib.h>
#include <pthread.h>
void *thread(void *args) {
return NULL;
}
int main(int argc, char *argv[]) {
pthread_t th;
pthread_create(&th, NULL, thread, NULL);
pthread_join(th, NULL);
return 0;
}
$ gcc -Wall -g -pthread valgrind_pthread.c
$ valgrind ./a.out
==22241== Memcheck, a memory error detector for x86-linux.
==22241== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==22241== Using valgrind-2.4.0.rc4, a program supervision framework for x86-linux.
==22241== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==22241== For more details, rerun with: -v
==22241==
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B991DA9: strstr (in /lib/libc-2.2.5.so)
==22241== by 0x1B910ADA: is_smp_system (in /lib/libpthread-0.9.so)
==22241== by 0x1B910CC0: pthread_initialize (in /lib/libpthread-0.9.so)
==22241== by 0x1B915DB6: (within /lib/libpthread-0.9.so)
==22241== by 0x1B90CC65: (within /lib/libpthread-0.9.so)
==22241== by 0x1B8EDCC6: call_init (in /lib/ld-2.2.5.so)
==22241== by 0x1B8EDD58: _dl_init (in /lib/ld-2.2.5.so)
==22241== by 0x1B8E5310: (within /lib/ld-2.2.5.so)
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x80484A3: main (valgrind_pthread.c:10)
==22241== Address 0x52BFEBE4 is on thread 1's stack
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x80484B4: main (valgrind_pthread.c:11)
==22241== Address 0x52BFEBD0 is on thread 1's stack
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x1B949E52: exit (in /lib/libc-2.2.5.so)
==22241== by 0x1B937154: __libc_start_main (in /lib/libc-2.2.5.so)
==22241== by 0x80483C0: (within /home/seiderer/test/a.out)
==22241== Address 0x52BFEBD0 is on thread 1's stack
==22241==
==22241== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 6 from 3)
==22241== malloc/free: in use at exit: 8160 bytes in 1 blocks.
==22241== malloc/free: 1 allocs, 0 frees, 8160 bytes allocated.
==22241== For counts of detected errors, rerun with: -v
==22241== searching for pointers to 1 not-freed blocks.
==22241== checked 98304 bytes.
==22241==
==22241== LEAK SUMMARY:
==22241== definitely lost: 8160 bytes in 1 blocks.
==22241== possibly lost: 0 bytes in 0 blocks.
==22241== still reachable: 0 bytes in 0 blocks.
==22241== suppressed: 0 bytes in 0 blocks.
==22241== Use --leak-check=full to see details of leaked memory.
$ cat /etc/debian_version
3.0
$ /lib/libc.so.6
GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease).
Compiled on a Linux 2.4.18 system on 2005-01-07.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.9 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bu...@gn...>.
--
------------------------------------------------------------------------
Peter Seiderer E-Mail: sei...@ci...
|
|
From: C W. <mf...@ds...> - 2005-03-20 11:11:08
|
My knowledge of stabs is very limited, but with a bit of guess work and some help from a bugzilla report I was able to get valgrind working on my free pascal programs by applying the attached patch to rc4. Colin |
|
From: C W. <mf...@ds...> - 2005-03-19 19:15:08
|
The current cvs version of lazarus compiled with freepascal gives the following problem: valgrind ./lazarus ==15093== Memcheck, a memory error detector for x86-linux. ==15093== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==15093== Using valgrind-2.4.0.rc4, a program supervision framework for x86-linux. ==15093== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. @@ unrecognized negative type -30 @@ parsing -30; gave NULL type ( remains) @@ parsing 543=-30; gave NULL type ( remains) Segmentation fault |
|
From: Nicholas N. <nj...@cs...> - 2005-03-19 16:36:04
|
On Sat, 19 Mar 2005, nithya prabha wrote: > I wish to draw a graph with time along the X-axis and the memory usage > along the Y- axis. With the massif utility,we get the memory usage for > each and every function. Strictly speaking, it gives the memory usage for call sites rather than functions, and it shows that for the 20 allocation sites that allocate the most memory, and the remainder get combined into a single "other" band. > I wish to know if there is way by which we can get only the total memory > usage alone raher having the individual function utilization. Just ignore the bands in the graph, and look only at the top line -- that is the total memory consumption. N |
|
From: nithya p. <vis...@ya...> - 2005-03-19 12:32:04
|
dear team, I wish to draw a graph with time along the X-axis and the memory usage along the Y- axis. With the massif utility,we get the memory usage for each and every function.I wish to know if there is way by which we can get only the total memory usage alone raher having the individual function utilization. thanks in advance nithya --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! |
|
From: Jeremy F. <je...@go...> - 2005-03-18 22:57:46
|
Alex Ivershen wrote:
> Jeremy, I found it. Somewhere somehow VKI_SIGVGKILL is getting
> blocked (I haven't found where yet). I added a line in do_setmask()
> line 690 - right after removing SIGKILL and SIGSTOP from the mask we
> should also remove SIGVGKILL. Everything fell into place, the app
> shuts down and cleans up its threads perfectly. You might wanna patch
> it into the current CVS head.
Could you confirm the changed I checked in last night fixes your problem?
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-18 20:18:12
|
On Fri, 18 Mar 2005, Craig Verge wrote: > Is the following memory leak reported by valgrind a bug in my code or a bug > with valgrind? I'm not sure how a user of pthread_create() could cause > this? > > ==751== 200 bytes in 1 blocks are definitely lost in loss record 305 of 332 > ==751== at 0x404DEE5B: (within > /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) > ==751== by 0x404E09F1: (within > /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) > ==751== by 0x404E0B24: __pthread_key_create (in > /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) > ==751== by 0x404E133E: (within > /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) > ==751== by 0x404DF72C: pthread_create (in > /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) > ==751== by 0x40EE0964: tenv::TenvAgInit::TenvAgInit() (agInit.cc:142) > ==751== by 0x40EE03D1: __static_initialization_and_destruction_0(int, > int) (agGlob.cc:56) > ==751== by 0x40EE045A: _GLOBAL__I__ZN4tenv8perProcTE (agGlob.cc:56) > ==751== by 0x40EE9FD4: (within /mnt/cmp/lib/libtenvag.so.1.3.0) > ==751== by 0x40EDF7FD: (within /mnt/cmp/lib/libtenvag.so.1.3.0) > ==751== by 0x4000B5C0: _dl_init_internal (in /lib/ld-2.3.2.so) > ==751== by 0x40000A8C: (within /lib/ld-2.3.2.so) I'm guessing it's a Valgrind bug. We had a 200-byte leak in our libpthread.so. It's normally suppressed but it seems that on your system valgrind's libpthread.so has been stripped, so the suppression won't match. If you try 2.4.0-rc4 (www.goop.org/~jeremy/valgrind/dist/), we now use the system libpthread, and the leak checker has been improved, so hopefully the problem will no longer be present. N |
|
From: Craig V. <cv...@no...> - 2005-03-18 20:10:58
|
Is the following memory leak reported by valgrind a bug in my code or a bug with valgrind? I'm not sure how a user of pthread_create() could cause this? ==751== 200 bytes in 1 blocks are definitely lost in loss record 305 of 332 ==751== at 0x404DEE5B: (within /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==751== by 0x404E09F1: (within /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==751== by 0x404E0B24: __pthread_key_create (in /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==751== by 0x404E133E: (within /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==751== by 0x404DF72C: pthread_create (in /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==751== by 0x40EE0964: tenv::TenvAgInit::TenvAgInit() (agInit.cc:142) ==751== by 0x40EE03D1: __static_initialization_and_destruction_0(int, int) (agGlob.cc:56) ==751== by 0x40EE045A: _GLOBAL__I__ZN4tenv8perProcTE (agGlob.cc:56) ==751== by 0x40EE9FD4: (within /mnt/cmp/lib/libtenvag.so.1.3.0) ==751== by 0x40EDF7FD: (within /mnt/cmp/lib/libtenvag.so.1.3.0) ==751== by 0x4000B5C0: _dl_init_internal (in /lib/ld-2.3.2.so) ==751== by 0x40000A8C: (within /lib/ld-2.3.2.so) This report used to look like the following: ==749== 200 bytes in 1 blocks are definitely lost in loss record 306 of 333 ==749== at 0x404DEE5B: (within /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==749== by 0x404E09F1: (within /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==749== by 0x404E0B24: __pthread_key_create (in /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==749== by 0x406E2842: (within /lib/libc-2.3.2.so) ==749== by 0x404E0E47: __pthread_once (in /mnt/image/opt/msp/tools/lib/valgrind/libpthread.so) ==749== by 0x406E2808: inet_ntoa (in /lib/libc-2.3.2.so) ==749== by 0x40EE9473: tenv::getOwnIp(unsigned&, unsigned char&, unsigned char&) (utils.cc:984) ==749== by 0x40EE0831: tenv::TenvAgInit::TenvAgInit() (agInit.cc:90) ==749== by 0x40EE03D1: __static_initialization_and_destruction_0(int, int) (agGlob.cc:56) ==749== by 0x40EE045A: _GLOBAL__I__ZN4tenv8perProcTE (agGlob.cc:56) ==749== by 0x40EE9F54: (within /mnt/image/opt/msp/lib/libtenvag.so.1.3.0) ==749== by 0x40EDF7FD: (within /mnt/image/opt/msp/lib/libtenvag.so.1.3.0) ==749== by 0x4000B5C0: _dl_init_internal (in /lib/ld-2.3.2.so) ==749== by 0x40000A8C: (within /lib/ld-2.3.2.so) But I replaced the use of "inet_ntoa" with "inet_ntop" and that changed the traceback. [root]# valgrind --version valgrind-2.0.0 Valgrind options used: --leak-check=yes --leak-resolution=high --num-callers=15 myProg What is happening? Two threads are created as part of a C++ global constructor via a call to pthread_create(). The leak is reported when the process is being terminated. There is a corresponding descructor which cancels the threads ( via pthread_cancel() )and does a pthread_join() on each before exiting. Cheers, Craig |
|
From: Nicholas N. <nj...@cs...> - 2005-03-18 20:08:46
|
On Fri, 18 Mar 2005, Shinni wrote: > Can i use valgrind for profiling memory usage ? > > is there any option in memcheck tool to know how much memory/swap space a > process is used for its entire execution ? > ( Like $time -f "%k" process , to know a process's memory usage? time command > gives me no result in my system) > > When i run valgrind memcheck tool for my program , i get the folowing > malloc related output (as in everyone's case).. > > ==2665== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) > ==2665== malloc/free: in use at exit: 3738920 bytes in 79 blocks. > ==2665== malloc/free: 6826 allocs, 6747 frees, 7862936 bytes allocated. > ==2665== For a detailed leak analysis, rerun with: --leak-check=yes > ==2665== For counts of detected errors, rerun with: -v > > Here , does the third line mean that the program used malloc 6826 times and > during its execution time , 7862 KB is allocated ? Are there any guidelines to > interpret the output valgrind gives? ( I'm a newbie * :( * ) > > I wanted to use valgrind for perfomance analysis of my programs. Is the info i > get like above is sufficient for this ? or is there any other way ? You can use the tool "Massif" (use --tool=massif). It produces output that is similar to, but not exactly the same as, what you are asking for. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-18 16:58:36
|
On Fri, 18 Mar 2005, Boris Mansencal wrote: > I am using current Valgrind version from CVS (on a Fedora Core 1 or 3 system, > Intel P4). > > Valgrind with Memcheck (or Addrcheck or even Massif) does not see any of my > memory allocation ! > It always reports : > ==11522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==11522== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==11522== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > ==11522== For counts of detected errors, rerun with: -v > ==11522== No malloc'd blocks -- no leaks are possible. > > I use option : --leak-check=yes. > I have only one processus (so no need to use --trace-children=yes as reported > in the FAQ). > > On a very sinple program valgrind do report memory allocation. > But It does not on my main application. > I have not yet found a simple test case that reproduce this odd behavior. > > Any idea ? You haven't told us anything about your program. In your Massif output you have these lines: ==23355== --alloc-fn=memory_alloc ==23355== --alloc-fn=memory_calloc ==23355== --alloc-fn=memory_realloc Does your program use a custom allocator, rather than the standard malloc()? If so, you'll have to use the client requests for these (see the manual sections 2.7 and 3.7). The --alloc-fn option is for indicating when functions wrap functions that do allocation. > Besides, Valgrind with Massif sometime dies on the same application. > Here is the output : > [...] > --23355-- allocs: 0 > --23355-- INTERNAL ERROR: Valgrind received a signal 8 (SIGFPE) - exiting > --23355-- si_code=1 Fault EIP: 0xF6DB4FD3; Faulting address: 0xF6DB4FD3 > --23355-- esp=0xF050AF20 That's a bug, although it only occurs with -v so it's not critical. I'll fix it over the weekend. N |
|
From: Shinni <pcs...@ni...> - 2005-03-18 16:57:34
|
Hi, I have a doubt similar to Dimitri's qn. Can i use valgrind for profiling memory usage ? is there any option in memcheck tool to know how much memory/swap space a process is used for its entire execution ? ( Like $time -f "%k" process , to know a process's memory usage? time command gives me no result in my system) When i run valgrind memcheck tool for my program , i get the folowing malloc related output (as in everyone's case).. ==2665== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==2665== malloc/free: in use at exit: 3738920 bytes in 79 blocks. ==2665== malloc/free: 6826 allocs, 6747 frees, 7862936 bytes allocated. ==2665== For a detailed leak analysis, rerun with: --leak-check=yes ==2665== For counts of detected errors, rerun with: -v Here , does the third line mean that the program used malloc 6826 times and during its execution time , 7862 KB is allocated ? Are there any guidelines to interpret the output valgrind gives? ( I'm a newbie * :( * ) I wanted to use valgrind for perfomance analysis of my programs. Is the info i get like above is sufficient for this ? or is there any other way ? Thank you for your time Regards shinni |
|
From: Tom H. <to...@co...> - 2005-03-18 16:35:47
|
In message <423...@la...>
Boris Mansencal <bor...@la...> wrote:
> I am using current Valgrind version from CVS (on a Fedora Core 1 or 3
> system, Intel P4).
>
> Valgrind with Memcheck (or Addrcheck or even Massif) does not see any
> of my memory allocation !
> It always reports :
> ==11522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==11522== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==11522== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==11522== For counts of detected errors, rerun with: -v
> ==11522== No malloc'd blocks -- no leaks are possible.
Is your program statically linked? If it is then valgrind won't be
able to see any of the calls to malloc/free etc.
> ==23355== Contents of /proc/version:
> ==23355== Linux version 2.6.9-1.667
> (bhc...@tw...) (gcc version 3.4.2 20041017 (Red
> Hat 3.4.2-6.fc3)) #1 Tue Nov 2 14:41:25 EST 2004
> ==23355== census: 0 ms (took 0 ms)
> ==23355== Reading syms from
> /net/tera4/mansenca/toger/girl/src/test-toger (0x8048000)
> ==23355== object doesn't have a dynamic symbol table
> ==23355== Reading syms from
> /net/tera4/mansenca/tools/lib/valgrind/stage2 (0xF0000000)
> ==23355== Reading syms from /lib/ld-2.3.3.so (0xF1000000)
> ==23355== object doesn't have any debug info
> ==23355== Reading syms from
> /net/tera4/mansenca/tools/lib/valgrind/vgskin_massif.so (0xF6DB0000)
> ==23355== Reading syms from /lib/tls/libc-2.3.3.so (0xF6EC1000)
> ==23355== object doesn't have any debug info
> ==23355== Reading syms from /lib/libdl-2.3.3.so (0xF6FE9000)
> ==23355== object doesn't have any debug info
> ==23355==
There's no obvious sign of it reading symbols for libc there, although
it might be in the bit you snipped. That might suggest a static link.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Boris M. <bor...@la...> - 2005-03-18 16:22:02
|
Hi, I am using current Valgrind version from CVS (on a Fedora Core 1 or 3 system, Intel P4). Valgrind with Memcheck (or Addrcheck or even Massif) does not see any of my memory allocation ! It always reports : ==11522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==11522== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11522== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==11522== For counts of detected errors, rerun with: -v ==11522== No malloc'd blocks -- no leaks are possible. I use option : --leak-check=yes. I have only one processus (so no need to use --trace-children=yes as reported in the FAQ). On a very sinple program valgrind do report memory allocation. But It does not on my main application. I have not yet found a simple test case that reproduce this odd behavior. Any idea ? Besides, Valgrind with Massif sometime dies on the same application. Here is the output : ==23355== Massif, a space profiler for x86-linux. ==23355== Copyright (C) 2003, Nicholas Nethercote ==23355== Using valgrind-2.4.0.rc4, a program supervision framework for x86-linux. ==23355== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==23355== Valgrind library directory: /usr/labri/mansenca/tools/lib/valgrind ==23355== Command line ==23355== ./test-toger ==23355== 10.0 ==23355== 30.0 ==23355== 5.0 ==23355== 1.5 ==23355== ../../Tests/00000296_5th.pnm ==23355== Startup, with flags: ==23355== --tool=massif ==23355== -v ==23355== --alloc-fn=memory_alloc ==23355== --alloc-fn=memory_calloc ==23355== --alloc-fn=memory_realloc ==23355== Contents of /proc/version: ==23355== Linux version 2.6.9-1.667 (bhc...@tw...) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Tue Nov 2 14:41:25 EST 2004 ==23355== census: 0 ms (took 0 ms) ==23355== Reading syms from /net/tera4/mansenca/toger/girl/src/test-toger (0x8048000) ==23355== object doesn't have a dynamic symbol table ==23355== Reading syms from /net/tera4/mansenca/tools/lib/valgrind/stage2 (0xF0000000) ==23355== Reading syms from /lib/ld-2.3.3.so (0xF1000000) ==23355== object doesn't have any debug info ==23355== Reading syms from /net/tera4/mansenca/tools/lib/valgrind/vgskin_massif.so (0xF6DB0000) ==23355== Reading syms from /lib/tls/libc-2.3.3.so (0xF6EC1000) ==23355== object doesn't have any debug info ==23355== Reading syms from /lib/libdl-2.3.3.so (0xF6FE9000) ==23355== object doesn't have any debug info ==23355== [...] ==23355== ==23355== census: 51101 ms (took 0 ms) ==23355== Total spacetime: 0 ms.B ==23355== heap: (n/a) ==23355== heap admin: (n/a) ==23355== stack(s): 0% --23355-- allocs: 0 --23355-- INTERNAL ERROR: Valgrind received a signal 8 (SIGFPE) - exiting --23355-- si_code=1 Fault EIP: 0xF6DB4FD3; Faulting address: 0xF6DB4FD3 --23355-- esp=0xF050AF20 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 2291767228 ==23355== at 0xF6DB4FD3: print_summary (ms_main.c:1776) ==23355== by 0xF6DB517D: vgSkin_fini (ms_main.c:1809) ==23355== by 0xF006DA5E: vgSkinInternal_fini (vg_toolint.c:36) ==23355== by 0xF0030C40: vgPlain_shutdown_actions (vg_main.c:2683) ==23355== by 0xF0087C44: vgArch_thread_wrapper (core_os.c:77) sched status: running_tid=0 Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-18 15:30:20
|
On Thu, 17 Mar 2005, Xavier WARIN (OSIRIS-EDF) wrote: > My program written in C++ named risk.so (loaded by python) can't be mapped : > warning: mmap failed on > /local/xwarin/electricity_derivatives-1-1-1/ED/Risk-BU/lib/risk.so > ==16896== no symbols or debug info loaded > > It is a huge .so file : due to debug information it grows to 400 MB > I looked into the mailing list and saw that i could change a variable > KICKSTART_BASE to 0xa0000000 in coregrind/Makefile.am. > I tried this fix up but it didn't improve. > > Any idea ? Should i take the latest snapshot of the code or an older valgrind > version. It probably won't make that much difference; this mis-handling of large .so files is still an unfixed problem (see bugs.kde.org/show_bug.cgi?id=82301). You could try moving KICKSTART_BASE lower, eg. 0x90000000, that might work. N |
|
From: Igmar P. <mai...@jd...> - 2005-03-18 09:09:45
|
> Any idea ? Should i take the latest snapshot of the code or an older > valgrind version. Get 2.4.0rc4, that should probably fix it. Igmar |