You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(9) |
3
(6) |
4
(4) |
5
(2) |
|
6
(6) |
7
(6) |
8
(4) |
9
(8) |
10
(4) |
11
(5) |
12
(2) |
|
13
(1) |
14
(11) |
15
(3) |
16
(12) |
17
(2) |
18
(12) |
19
(6) |
|
20
|
21
(11) |
22
(10) |
23
(7) |
24
(6) |
25
(11) |
26
(6) |
|
27
(1) |
28
(11) |
29
(3) |
30
(3) |
|
|
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 13:20:14
|
I cannot build valgrind, neither version 2.0.0 nor 2.1.1, using gcc-3.3.3-r6 The error message I receive is: error: can't find a register in class `BREG' while reloading `asm' For all the details, as well as a proposed solution, please see <a href="http://bugs.gentoo.org/show_bug.cgi?id=54068">Gentoo Bug #54068</a> Thanks, Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Kurien M. <km...@en...> - 2004-06-15 13:52:11
|
Hello,
I am having trouble running my program through Valgrind. It seems to
hang after a few seconds when run with valgrind. When the hung process
is attached via gdb this is what I have:
Program received signal SIGINT, Interrupt.
vg_do_syscall3 (syscallno=4294966784, arg1=2, arg2=1075618368, arg3=86)
at vg_mylibc.c:92
92 }
(gdb) bt
#0 vg_do_syscall3 (syscallno=4294966784, arg1=2, arg2=1075618368,
arg3=86) at vg_mylibc.c:92
#1 0x00000056 in ?? ()
Cannot access memory at address 0x1
(gdb)
#0 vg_do_syscall3 (syscallno=4294966784, arg1=2, arg2=1075618368,
arg3=86) at vg_mylibc.c:92
#1 0x00000056 in ?? ()
(gdb) bt
#0 vg_do_syscall3 (syscallno=4294966784, arg1=2, arg2=1075618368,
arg3=86) at vg_mylibc.c:92
#1 0x00000056 in ?? ()
(gdb) info locals
__res = 4294966784
(gdb) info threads
(gdb)
Do you have any suggestions in getting past this problem?
The original problem with the program is that it ends with a
segmentation fault with backtrace:
#0 0x00000001 in ?? ()
#1 0x413f7cd0 in AV_Scene::render(RE_Renderer*, double, int)
(this=0x8537f90, renderer=0x80b6bb8, time=47.301000000000002, quality=1)
at AV_Scene.cpp:730
#2 0x4131b042 in CL_Client::render(double, double*) (this=0x808ecc8,
currentPlayerTime=-1, currentPresentationTimep=0x0) at CL_Client.cpp:897
#3 0x4131ab5b in CL_Client::idle(double, double*) (this=0x808ecc8,
currentPlayerTime=-1, currentPresentationTimep=0x0) at CL_Client.cpp:759
#4 0x4131d862 in idle (table=0x808ab9c, currentPlayerTime=-1,
currentPresentationTimep=0x0) at CL_Client.cpp:1891
#5 0x0805031c in SigmaClient::play() (this=0x808ab78) at
SigmaClient.cpp:1328
#6 0x080505e9 in SigmaClient::loop() (this=0x808ab78) at
SigmaClient.cpp:1376
#7 0x0805548b in run (argc=2, argv=0xbfffef34) at
SigmaClientMain.cpp:73
#8 0x08055638 in main (argc=2, argv=0xbfffef34) at
SigmaClientMain.cpp:107
#9 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
and the line 730 in AV_Scene.cpp is a function call.
729: while (m_eventHolder->popEvent (&event)) {
730: manageEvent (&event);
731: }
I was expecting to located this corruption (in the code segment?) using
valgrind.
Any hints would be of great help.
Thanks
Kurien
|
|
From: Sebastian K. <Seb...@so...> - 2004-06-15 10:19:42
|
ozgun erdogan wrote: > >> Only 27%!? That's really bad, especially if its L2 -- remember that >> an L2 >> miss can cost 100s of cycles (206 in the worst case on my Athlon). > > > Is there a website (paper) that summarizes the cost of cache misses? You can measure it yourself. For example this little tool (made by a bunch of benchmark guys incl. me): http://www.sf.net/projects/later will tell you memory latency in ns (translating nanoseconds to cpu cycles is easy) with about 5-10% accuracy (run it as a user who has rioght to up process the priority). > I've read a paper that says the cost of accessing the memory is around > 15 CPU cyles... It must be 15-20 years old. Today it's around 100-120 cycles min. on Athnlon 64 and about 200-300 on Pentium 4. Those are good to best cases. In bad case, when TLB miss occurs multiple those numbers by 3. -- Sebastian Kaliszewski |
|
From: Nicholas N. <nj...@ca...> - 2004-06-15 08:25:10
|
On Mon, 14 Jun 2004, ozgun erdogan wrote: > Is there a website (paper) that summarizes the cost of cache misses? I've > read a paper that says the cost of accessing the memory is around 15 CPU > cyles... There are many. Google for eg. "cache miss cost" or "cache optimizations". > I don't think Cachegrind is doing anything wrong. You could say I'm > (basically) probing random memory that is 32 MB long. Right, in that case it sounds like Cachegrind is giving the right answers. Can you rethink your data structures? It could make an *enormous* speed difference. N |
|
From: ozgun e. <ku...@ho...> - 2004-06-14 20:54:52
|
>Only 27%!? That's really bad, especially if its L2 -- remember that an L2 >miss can cost 100s of cycles (206 in the worst case on my Athlon). Is there a website (paper) that summarizes the cost of cache misses? I've read a paper that says the cost of accessing the memory is around 15 CPU cyles... >99%? That is amazing. Either your program is pathologically bad, or >Cachegrind is doing something wrong. I don't think Cachegrind is doing anything wrong. You could say I'm (basically) probing random memory that is 32 MB long. Thanks, Ozgun. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Tom H. <th...@cy...> - 2004-06-14 16:26:03
|
In message <40C...@in...>
Salvador Eduardo Tropea <sal...@in...> wrote:
> BTW: Linux glibc 2.2.5 doesn´t make a copy of the string, the
> following test program shows it:
It won't make a copy of the string. That's the whole problem and is
why you need to allocate persistent storage for the string.
What is does do is have an allocated buffer that contains all the
pointers that have been passed to putenv. When the program exits that
buffer is freed and the pointer is lost so it winds up looking like
the memory given to putenv has been lost, which is has in fact, but
only for those few milliseconds during program exit.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Salvador E. T. <sal...@in...> - 2004-06-14 15:07:23
|
Hi All! I=B4m using XFree86 4.1.0-16woody3 and I=B4m getting a lot of reports=20 about leaks in XOpenIM. Around 390 blocks aren=B4t released. I double=20 checked that XCloseIM is called, so I guess it should release these block= s. I want to know if anybody had a similar problem. That=B4s because I=20 can=B4t be sure if the problem is in XLib or perhaps my code is doing=20 something wrong. Regards, SET P.S. XCloseIM is returning True so I think it successfully closed the IM.= --=20 Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: se...@co... se...@ie...=20 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013 |
|
From: Salvador E. T. <sal...@in...> - 2004-06-14 14:55:40
|
Tom Hughes wrote:
>>What=B4s the solution?
>> =20
>>
>
>I'm not sure there is a good one I'm afraid.
> =20
>
Thanks (also to Oswald). I=B4m currently using some suppressions to just =
avoid the message.
BTW: Linux glibc 2.2.5 doesn=B4t make a copy of the string, the following=
=20
test program shows it:
<-------------------
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
char s[]=3D"XXX=3DYYY", *x;
putenv(s);
x=3Dgetenv("XXX");
printf("%p vs %p\n",s,x);
x[1]=3D'p';
printf("s: %s\n",s);
return 0;
}
<-------------------
Here modifications to the value returned by getenv are reflected in the=20
value we passed to putenv, the pointers are the same.
Regards, SET
--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
|
|
From: Salvador E. T. <sal...@in...> - 2004-06-14 14:48:55
|
Salvador Eduardo Tropea wrote: >> with gcc -shared (so it would get an internal copy of referenced=20 >> builtins) >> and then linking a program against it with g++. If the shared=20 >> library was >> linked with g++ -shared, all worked OK - the single copy in libstdc++ = >> was >> used. > > I have reproduced something similar by linking a (dummy) shared library= > I can=C2=B4t follow you. Do you mean that the problem could be created = by=20 > mixing gcc and g++ calls? > Just "for the records": It was the problem, using the gcc wrapper to=20 compile/link C++ code produced some change in the order of libraries=20 during the link process. Using g++ for C++ files, gcc for C files and=20 g++ to link solved the problem. Thanks, SET --=20 Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: se...@co... se...@ie...=20 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013 |
|
From: Elijah P N. <ne...@ma...> - 2004-06-14 14:35:08
|
On Fri, 2004-06-11 at 14:01, Terry Song wrote: > Hi everyone > > I'm a new valgrind user, so my question might sound stupid. I'm > testing a visualisation program, its core is written in C++, while the > user interface and 3D rendering are in Xmt and OpenGL. I'm using > valgrind to check for errors of the program. Valgrind automatically > checks for errors in all source codes of the program, but I only need > it to check the C++ codes. I'm wondering how to tell valgrind to only > check the C++ codes, and not the Xmt or OpenGL codes. This is what --gen-suppressions=yes is for. It still checks all the code, but it doesn't report the errors that you've told it to ignore. Elijah |
|
From: Josef W. <Jos...@gm...> - 2004-06-14 13:22:42
|
On Friday 11 June 2004 10:04, ozgun erdogan wrote:
> Basically, the program goes through 15,388,813 blocks of input, and for
> every block, takes its mod with some very large prime. It then checks this
> bit array to see if there is a match. When the bloom filter size is 256 KB,
> Cachegrind tells me there are 477,221 L2 cache misses. (I know that
> Cachegrind models Pentium's cache, so that number is pretty reasonable.)
> Then, when I go ahead and try it on a 32 MB bloom filter, I get this:
>
> Dr D1mr D2mr Dw D1mw D2mw
> file:function
> ---------------------------------------------------------------------------
>------------------ 76,944,065 7,684,264 4,626,161 15,388,813 0
> 0
> scanner.c:ba_value
>
> Now, this means the data miss rate on my cache is only ~27%. Given the
> filter size and the even distribution, this doesn't make any sense to me. I
Hi,
what is the exact number that makes no sense to you?
I suppose ba_value is called 15 mio. times, and you wonder why this only makes
it to 4.6 mio. L2 misses? Perhaps the access order to the array is not as
random as you thought?
What would you like cachegrind to show you to have more trust into its
results?
Josef
> must be missing something. I compiled with -g and no optimizations. Here is
> ba_value's code:
>
> boolean ba_value(const bit arr[], const elem_t elem)
> {
> return( (arr[elem / BITS_SZ] & (1 << (elem % BITS_SZ))) ? TRUE:FALSE );
> }
>
> What may be going on? Any help would really be appreciated. Thanks,
>
> Ozgun.
>
> _________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-14 11:35:57
|
On Thu, 10 Jun 2004, David Fix wrote: > Hi folks, > > I just tried to compile Valgrind, but had the following problem... Any > thoughts? > Compiled on a Pentium III w/384mb > GCC 3.4.0 > GLIBC 2.3.2 > > > mc_main.c: At top level: > mc_main.c:773: error: conflicting types for 'vgMemCheck_helperc_LOADV4' > mc_include.h:130: error: previous declaration of 'vgMemCheck_helperc_LOADV4' > was here > mc_main.c:773: error: conflicting types for 'vgMemCheck_helperc_LOADV4' > mc_include.h:130: error: previous declaration of 'vgMemCheck_helperc_LOADV4' > was here Never seen that before. mc_include.h:130 looks like this: extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV4) ( Addr ); mc_main.c:773 looks like this: __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV4) ( Addr a ) they seem to match pretty well. Maybe it's a GCC bug? If you remove the __attribute__ part in both files, does the compile error go away? (Nb: that might fix the compile error, but it will break Valgrind.) It's weird that GCC is reporting the error twice. N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-14 09:42:55
|
On Mon, 14 Jun 2004, Karine Excoffier wrote: > As suggested in the following valgrind report, I send the full text I > get when trying to use valgrind. > Thanks for any information. This looks to be bug #82114 (bugs.kde.org/show_bug.cgi?id=82114). There's no fix as yet AFAIK. N > Linux distrib: 2.4.9-e.24smp (but program running with > LD_ASSUME_KERNEL=2.4.1 > > ==2937== Memcheck, a memory error detector for x86-linux. > ==2937== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. > ==2937== Using valgrind-2.1.1, a program supervision framework for > x86-linux. > ==2937== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. > ==2937== Valgrind library directory: /usr/lib/valgrind > ==2937== Command line > ==2937== ./ns-slapd > ==2937== -D > ==2937== /opt/sun/directoryserver/slapd-ps-rh6 > ==2937== Startup, with flags: > ==2937== --tool=memcheck > ==2937== -v > ==2937== --leak-check=yes > ==2937== --run-libc-freeres=no > ==2937== Reading syms from > /opt/sun/directory-server/5.2/bin/slapd/server/ns-slapd (0x8048000) > ==2937== object doesn't have a symbol table > ==2937== object doesn't have any debug info > ==2937== Reading syms from /lib/ld-2.2.4.so (0x3C000000) > ==2937== Reading syms from /lib/ld-2.2.4.so (0xB0000000) > ==2937== Reading syms from /lib/libdl-2.2.4.so (0xB002F000) > ==2937== Reading syms from /lib/i686/libc-2.2.4.so (0xB0033000) > ==2937== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so > (0xB0300000) > ==2937== Reading syms from /usr/lib/valgrind/stage2 (0xB8000000) > ==2937== object doesn't have any debug info > ==2937== Reading suppressions file: /usr/lib/valgrind/default.supp > ==2937== REDIRECT soname:libc.so.6(__GI___errno_location) to > soname:libpthread.so.0(__errno_location) > ==2937== REDIRECT soname:libc.so.6(__errno_location) to > soname:libpthread.so.0(__errno_location) > ==2937== REDIRECT soname:libc.so.6(__GI___h_errno_location) to > soname:libpthread.so.0(__h_errno_location) > ==2937== REDIRECT soname:libc.so.6(__h_errno_location) to > soname:libpthread.so.0(__h_errno_location) > ==2937== REDIRECT soname:libc.so.6(__GI___res_state) to > soname:libpthread.so.0(__res_state) > ==2937== REDIRECT soname:libc.so.6(__res_state) to > soname:libpthread.so.0(__res_state) > ==2937== REDIRECT soname:libc.so.6(stpcpy) to > *vgpreload_memcheck.so*(stpcpy) > ==2937== REDIRECT soname:libc.so.6(strnlen) to > *vgpreload_memcheck.so*(strnlen) > ==2937== REDIRECT soname:ld-linux.so.2(stpcpy) to > *vgpreload_memcheck.so*(stpcpy) > ==2937== REDIRECT soname:ld-linux.so.2(strchr) to > *vgpreload_memcheck.so*(strchr) > ==2937== > ==2937== Reading syms from /usr/lib/valgrind/vg_inject.so (0x3C01A000) > ==2937== Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so > (0x3C01D000) > ==2937== Reading syms from /usr/lib/valgrind/libpthread.so (0x3C023000) > ==2937== Reading syms from > /opt/sun/directory-server/5.2/lib/libslapd.so.1 (0x3C049000) > ==2937== object doesn't have a symbol table > ==2937== object doesn't have any debug info > ==2937== Reading syms from > /opt/sun/directory-server/5.2/lib/libfe.so (0x3C111000) > ==2937== object doesn't have a symbol table > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libssl3.so (0x3C141000) > ==2937== Reading syms from /opt/sun/private/lib/libnss3.so (0x3C161000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libssldap50.so > (0x3C1F9000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libldap50.so > (0x3C204000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libprldap50.so > (0x3C22F000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libsasl.so (0x3C235000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libplc4.so (0x3C24B000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libplds4.so (0x3C250000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libnspr4.so (0x3C254000) > ==2937== Reading syms from /lib/libdl-2.2.4.so (0x3C29C000) > ==2937== Reading syms from /opt/sun/private/lib/libicudata.so.2 > (0x3C2A1000) > ==2937== object doesn't have any debug info > ==2937== Reading syms from /opt/sun/private/lib/libicui18n.so.2 > (0x3CAB3000) > ==2937== Reading syms from /opt/sun/private/lib/libicuuc.so.2 > (0x3CB98000) > ==2937== Reading syms from /lib/libresolv-2.2.4.so (0x3CC07000) > ==2937== Reading syms from /lib/libcrypt-2.2.4.so (0x3CC1A000) > ==2937== Reading syms from > /opt/sun/directory-server/5.2/lib/libdb32.so (0x3CC4A000) > ==2937== object doesn't have a symbol table > ==2937== object doesn't have any debug info > ==2937== Reading syms from /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so > (0x3CCE3000) > ==2937== Reading syms from /lib/i686/libm-2.2.4.so (0x3CD27000) > ==2937== Reading syms from /lib/i686/libc-2.2.4.so (0x3CD4B000) > ==2937== warning: Valgrind's pthread_getschedparam is incomplete > ==2937== your program may misbehave as a result > ==2937== warning: Valgrind's pthread_setschedparam does nothing > ==2937== (scheduling not changeable) > ==2937== your program may misbehave as a result > ==2937== warning: Valgrind's pthread_cond_destroy is incomplete > ==2937== (it doesn't check if the cond is waited on) > ==2937== your program may misbehave as a result > ==2937== warning: Valgrind's pthread_cond_destroy is incomplete > ==2937== (it doesn't check if the cond is waited on) > ==2937== your program may misbehave as a result > ==2937== warning: Valgrind's pthread_cond_destroy is incomplete > ==2937== (it doesn't check if the cond is waited on) > ==2937== your program may misbehave as a result > ==2937== Reading syms from > /opt/sun/directory-server/5.2/lib/syntax-plugin.so (0x3C282000) > ==2937== object doesn't have a symbol table > ==2937== object doesn't have any debug info > ==2940== TRANSLATE: 0x3CDD2584 redirected to 0x3C01ED00 > proxy 2941 for tid 1 exited status -1, res 0 > got signal 17 in LWP 2937 (2937) > > valgrind: vg_signals.c:1557 (vg_async_signalhandler): Assertion > `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. > ==2937== at 0xB802D834: vgPlain_skin_assert_fail (in > /usr/lib/valgrind/stage2) > > sched status: > > Thread 1: status = WaitSys, associated_mx = 0x0, associated_cv = 0x0 > ==2937== at 0x3CE2BFD4: read (in /lib/i686/libc-2.2.4.so) > ==2937== by 0x3CDC7A55: _IO_file_read (fileops.c:838) > ==2937== by 0x3CDC7857: _IO_file_xsgetn (fileops.c:1065) > ==2937== by 0x3CDC8DCF: _IO_sgetn (genops.c:480) > > > 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. > > > -- > Karine EXCOFFIER > Directory Server Group - Grenoble (FRANCE) > Sun Microsystems Inc. > > |
|
From: Nicholas N. <nj...@ca...> - 2004-06-14 09:27:16
|
On Fri, 11 Jun 2004, Terry Song wrote: > I'm a new valgrind user, so my question might sound stupid. I'm testing > a visualisation program, its core is written in C++, while the user > interface and 3D rendering are in Xmt and OpenGL. I'm using valgrind to > check for errors of the program. Valgrind automatically checks for > errors in all source codes of the program, but I only need it to check > the C++ codes. I'm wondering how to tell valgrind to only check the C++ > codes, and not the Xmt or OpenGL codes. You can't, sorry. Valgrind/Memcheck has to check all code. It couldn't work otherwise. N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-14 09:23:34
|
On Fri, 11 Jun 2004, ozgun erdogan wrote: > Now, this means the data miss rate on my cache is only ~27%. Only 27%!? That's really bad, especially if its L2 -- remember that an L2 miss can cost 100s of cycles (206 in the worst case on my Athlon). > I was testing Cachegrind on an executable file (60 MB) constructed from > /usr/bin. Trying it on a random file, I get around 99.2% cache misses. > This is really amazing! Thanks to Cachegrind I realized there were some > fundamental problems with my assumptions. 99%? That is amazing. Either your program is pathologically bad, or Cachegrind is doing something wrong. N |
|
From: ozgun e. <ku...@ho...> - 2004-06-13 03:22:59
|
>I suppose ba_value is called 15 mio. times, and you wonder why this only >makes >it to 4.6 mio. L2 misses? Perhaps the access order to the array is not as >random as you thought? I was testing Cachegrind on an executable file (60 MB) constructed from /usr/bin. Trying it on a random file, I get around 99.2% cache misses. This is really amazing! Thanks to Cachegrind I realized there were some fundamental problems with my assumptions. Ozgun. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Tom H. <th...@cy...> - 2004-06-12 16:10:16
|
In message <D4D...@us...>
"Tamtoro, Ferry (MED)" <Fer...@me...> wrote:
> I installed version 2.1.1 and one of my program that used to work with 2.0
> does not work anymore.
In what way doesn't it work? If you tell us then we might be able
to help you get it working.
> So, I'm wondering if someone could please let me know if there's a way to
> modify valgrind to ignore some function calls?
No.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-06-12 16:10:16
|
In message <40C...@in...>
Salvador Eduardo Tropea <sal...@in...> wrote:
> That´s because buffer will be invalid as soon as you leave "Function"
> and putenv have a reference and not a copy.
> So you have to do something like it:
>
> void Function(char *val)
> {
> char buffer[20];
> snprintf(buffer,20,"VAR=%s",val);
> putenv(strdup(buffer));
> }
>
> But the valgrind is quite sure you leaked.
The reason for this appears to be that although libc takes a copy
of the pointer the structure in which that pointer is held is freed
when the programs exits and valgrind calls __libc_freeres to make
libc free it's resources.
It doesn't free the pointer you passed to putenv however as it can't
know how it was allocated. If you run with --run-libc-freeres=no then
you'll find that valgrind doesn't complain. That might cause other
problems however.
> What´s the solution?
I'm not sure there is a good one I'm afraid.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Oswald B. <os...@kd...> - 2004-06-11 22:42:49
|
On Fri, Jun 11, 2004 at 03:15:54PM -0300, Salvador Eduardo Tropea wrote: > What´s the solution? > there is no universal one. either always use the leaking version or make a configure check ... greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Tamtoro, F. (MED) <Fer...@me...> - 2004-06-11 22:33:48
|
I installed version 2.1.1 and one of my program that used to work with 2.0 does not work anymore. So, I'm wondering if someone could please let me know if there's a way to modify valgrind to ignore some function calls? Thanks, Ferry -----Original Message----- From: Nicholas Nethercote [mailto:nj...@he...]On Behalf Of Nicholas Nethercote Sent: Sunday, June 06, 2004 4:39 PM To: Tamtoro, Ferry (MED) Cc: 'val...@li...' Subject: Re: [Valgrind-users] Bypass a system / library function On Sun, 6 Jun 2004, Tamtoro, Ferry (MED) wrote: > I am new to valgrind and am hoping that someone can help me resolve a > problem I'm experiencing when I'm running my program using valgrind. > > When I'm running my program using valgrind, it crashes in the middle with > this error: > disInstr: unhandled instruction bytes: 0xF 0x17 0x10 0xF > > I believe this happens right after a call to a function in one of the Intel > libraries. So, I'm wondering if it's possible to setup valgrind to ignore > certain function calls, so that it does not try to instrument code around > that function? > It's different that suppressing errors, because I'm hoping to call that > function like when the program is not run using valgrind. > > Any help would be greatly appreciated. You don't way what version you're running, probably an old one. Try a new one (eg. 2.1.1) and it should be fixed. N |
|
From: Terry S. <So...@co...> - 2004-06-11 20:02:00
|
Hi everyone I'm a new valgrind user, so my question might sound stupid. I'm testing = a visualisation program, its core is written in C++, while the user = interface and 3D rendering are in Xmt and OpenGL. I'm using valgrind to = check for errors of the program. Valgrind automatically checks for = errors in all source codes of the program, but I only need it to check = the C++ codes. I'm wondering how to tell valgrind to only check the C++ = codes, and not the Xmt or OpenGL codes. Thanks a lot everyone Terry Song |
|
From: Salvador E. T. <sal...@in...> - 2004-06-11 18:15:55
|
Hi All!
May be my question is stupid but:
The glibc implementation of putenv doesn=B4t copy the string you pass.
It means that you can=B4t do it:
void Function(char *val)
{
char buffer[20];
snprintf(buffer,20,"VAR=3D%s",val);
putenv(buffer);
}
That=B4s because buffer will be invalid as soon as you leave "Function"=20
and putenv have a reference and not a copy.
So you have to do something like it:
void Function(char *val)
{
char buffer[20];
snprintf(buffer,20,"VAR=3D%s",val);
putenv(strdup(buffer));
}
But the valgrind is quite sure you leaked.
What=B4s the solution? In my current code I have:
char *b=3Dnew char[8+strlen(tmp)];
sprintf(b,"TMPDIR=3D%s",tmp);
putenv(b);
And valgrind reports the leak in the new, it means I have to use a=20
suppression for each point in the code where I do it and I can=B4t ask to=
=20
ignore all the pointers passed to putenv.
Is that the way to go?
Regards, SET
--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
|
|
From: ozgun e. <ku...@ho...> - 2004-06-11 08:05:10
|
hi,
I'm testing a program that uses bloom filters (a bit array used like a hash
table). Performance is very dependent on the CPU's cache size, and drops
down dramatically as I increase the bloom filter size. So, I need to know
the rate of cache hits/misses. Cachegrind seems to be exactly what I am
looking for, so I downloaded and ran it on my AMD 1.8 Ghz (64 KB L1 data
cache, 128 KB L2 cache).
Basically, the program goes through 15,388,813 blocks of input, and for
every block, takes its mod with some very large prime. It then checks this
bit array to see if there is a match. When the bloom filter size is 256 KB,
Cachegrind tells me there are 477,221 L2 cache misses. (I know that
Cachegrind models Pentium's cache, so that number is pretty reasonable.)
Then, when I go ahead and try it on a 32 MB bloom filter, I get this:
Dr D1mr D2mr Dw D1mw D2mw
file:function
---------------------------------------------------------------------------------------------
76,944,065 7,684,264 4,626,161 15,388,813 0 0
scanner.c:ba_value
Now, this means the data miss rate on my cache is only ~27%. Given the
filter size and the even distribution, this doesn't make any sense to me. I
must be missing something. I compiled with -g and no optimizations. Here is
ba_value's code:
boolean ba_value(const bit arr[], const elem_t elem)
{
return( (arr[elem / BITS_SZ] & (1 << (elem % BITS_SZ))) ? TRUE:FALSE );
}
What may be going on? Any help would really be appreciated. Thanks,
Ozgun.
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: David F. <36q...@sn...> - 2004-06-10 23:11:49
|
Hi folks, I just tried to compile Valgrind, but had the following problem... Any thoughts? Compiled on a Pentium III w/384mb GCC 3.4.0 GLIBC 2.3.2 mc_main.c: At top level: mc_main.c:773: error: conflicting types for 'vgMemCheck_helperc_LOADV4' mc_include.h:130: error: previous declaration of 'vgMemCheck_helperc_LOADV4' was here mc_main.c:773: error: conflicting types for 'vgMemCheck_helperc_LOADV4' mc_include.h:130: error: previous declaration of 'vgMemCheck_helperc_LOADV4' was here mc_main.c:798: error: conflicting types for 'vgMemCheck_helperc_STOREV4' mc_include.h:124: error: previous declaration of 'vgMemCheck_helperc_STOREV4' was here mc_main.c:798: error: conflicting types for 'vgMemCheck_helperc_STOREV4' mc_include.h:124: error: previous declaration of 'vgMemCheck_helperc_STOREV4' was here mc_main.c:823: error: conflicting types for 'vgMemCheck_helperc_LOADV2' mc_include.h:129: error: previous declaration of 'vgMemCheck_helperc_LOADV2' was here mc_main.c:823: error: conflicting types for 'vgMemCheck_helperc_LOADV2' mc_include.h:129: error: previous declaration of 'vgMemCheck_helperc_LOADV2' was here mc_main.c:846: error: conflicting types for 'vgMemCheck_helperc_STOREV2' mc_include.h:125: error: previous declaration of 'vgMemCheck_helperc_STOREV2' was here mc_main.c:846: error: conflicting types for 'vgMemCheck_helperc_STOREV2' mc_include.h:125: error: previous declaration of 'vgMemCheck_helperc_STOREV2' was here mc_main.c:867: error: conflicting types for 'vgMemCheck_helperc_LOADV1' mc_include.h:128: error: previous declaration of 'vgMemCheck_helperc_LOADV1' was here mc_main.c:867: error: conflicting types for 'vgMemCheck_helperc_LOADV1' mc_include.h:128: error: previous declaration of 'vgMemCheck_helperc_LOADV1' was here mc_main.c:890: error: conflicting types for 'vgMemCheck_helperc_STOREV1' mc_include.h:126: error: previous declaration of 'vgMemCheck_helperc_STOREV1' was here mc_main.c:890: error: conflicting types for 'vgMemCheck_helperc_STOREV1' mc_include.h:126: error: previous declaration of 'vgMemCheck_helperc_STOREV1' was here mc_main.c: In function `mc_rd_V4_SLOWLY': mc_main.c:975: warning: passing arg 4 of `vgPlain_skin_assert_fail' discards qualifiers from pointer target type mc_main.c: At top level: mc_main.c:1118: error: conflicting types for 'vgMemCheck_fpu_read_check' mc_include.h:133: error: previous declaration of 'vgMemCheck_fpu_read_check' was here mc_main.c:1118: error: conflicting types for 'vgMemCheck_fpu_read_check' mc_include.h:133: error: previous declaration of 'vgMemCheck_fpu_read_check' was here mc_main.c:1210: error: conflicting types for 'vgMemCheck_fpu_write_check' mc_include.h:132: error: previous declaration of 'vgMemCheck_fpu_write_check' was here mc_main.c:1210: error: conflicting types for 'vgMemCheck_fpu_write_check' mc_include.h:132: error: previous declaration of 'vgMemCheck_fpu_write_check' was here mc_main.c: In function `mc_is_valid_64k_chunk': mc_main.c:1433: warning: passing arg 4 of `vgPlain_skin_assert_fail' discards qualifiers from pointer target type mc_main.c: In function `mc_is_valid_address': mc_main.c:1450: warning: passing arg 4 of `vgPlain_skin_assert_fail' discards qualifiers from pointer target type mc_main.c: In function `vgSkin_pre_clo_init': mc_main.c:1693: warning: passing arg 1 of `vgPlain_track_new_mem_stack_4' from incompatible pointer type mc_main.c:1694: warning: passing arg 1 of `vgPlain_track_new_mem_stack_8' from incompatible pointer type mc_main.c:1695: warning: passing arg 1 of `vgPlain_track_new_mem_stack_12' from incompatible pointer type mc_main.c:1696: warning: passing arg 1 of `vgPlain_track_new_mem_stack_16' from incompatible pointer type mc_main.c:1697: warning: passing arg 1 of `vgPlain_track_new_mem_stack_32' from incompatible pointer type mc_main.c:1700: warning: passing arg 1 of `vgPlain_track_die_mem_stack_4' from incompatible pointer type mc_main.c:1701: warning: passing arg 1 of `vgPlain_track_die_mem_stack_8' from incompatible pointer type mc_main.c:1702: warning: passing arg 1 of `vgPlain_track_die_mem_stack_12' from incompatible pointer type mc_main.c:1703: warning: passing arg 1 of `vgPlain_track_die_mem_stack_16' from incompatible pointer type mc_main.c:1704: warning: passing arg 1 of `vgPlain_track_die_mem_stack_32' from incompatible pointer type make[3]: *** [mc_main.o] Error 1 make[3]: Leaving directory `/root/valgrind-2.0.0/memcheck' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/valgrind-2.0.0/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/valgrind-2.0.0' make: *** [all] Error 2 |
|
From: kirk j. <tu...@in...> - 2004-06-10 07:48:19
|
NN = nicholas nethercote
KJ = kirk johnson
NN > As a temporary workaround, you could try installing Valgrind
> 2.0.0, which lays out memory differently, and then plumbing in
> Massif (it wasn't added until 2.1.0), which will require some
> judicious copying and editing of configure.in and Makefile.am.
KJ > another option would be to try some version of the patch that's
> listed at the end of bug #82301.
i tried the approach listed at the end of bug #82301 -- i tweaked
VALGRIND_MAPSIZE to 256 MB and info.map_base to 0xa8000000 -- but it
didn't change the failure mode. in fact, even if i upped
VALGRIND_MAPSIZE to 512 MB (and made the corresponding change to
info.map_base), that still doesn't help. even worse, things still fail
at essentially the same point in the program execution.
digging a little deeper, it ends up being rather obvious why this is
-- the VG_(get_memory_from_mmap) code is allocating from between
VG_(valgrind_mmap_end) and VG_(valgrind_end), and the values of these
variables are not affected by the dinking around with VALGRIND_MAPSIZE
and info.map_base. said dinking _does_ cause the value of
VG_(valgrind_base) to change, but since that doesn't affect the range
of memory available for VG_(get_memory_from_mmap) to allocate from, it
doesn't address the problem at hand.
brief thought was given to the idea of replacing the calls to
perm_malloc with calls to VG_(malloc), but that wouldn't help either
-- in the end, memory allocated by VG_(malloc) is also coming out of
the pool managed by VG_(get_memory_from_mmap).
looking more closely at coregrind/vg_main.c, i see that
VG_(valgrind_mmap_end) and VG_(valgrind_end) are set up in
layout_client_space(). alas, the values assigned to these variables
appear to be out of my control -- VG_(valgrind_mmap_end) is coming
from the location of kickstart_end (apparently a "magic" symbol
defined by the linker/loader?), while VG_(valgrind_end) is coming from
the location at which main() is passed its arguments. thus, we're left
with a handful of possible solutions:
1) find a way to change the locations of kickstart_end and/or the
arguments that are passed to main(), thus increasing the amount of
space availble to VG_(get_memory_from_mmap). although this doesn't
_solve_ the problem, perhaps it puts it off far enough to work
around my immediate difficulties.
2) revise the memory allocation scheme such that once
VG_(get_memory_from_mmap) runs out of space between
VG_(valgrind_mmap_end) and VG_(valgrind_end), additional memory
segments can be allocated from elsewhere (either the same pool
that the client heap is being drawn from or from unused parts of
the VG_(valgrind_base) to VG_(valgrind_mmap_end) range). this
would seem to run at least partly counter to the
full-virtualization efforts (and may in fact be closer to how
things were done in valgrind-2.0.0; i haven't looked at the code
to see).
3) get lucky and discover that non-trivial numbers of XPt objects are
going non-live (and possibly being reallocated later); provide a
means of reclaiming these XPt objects and any associated memory
(e.g., free the child data, freelist the XPt objects). obviously
this only helps if non-trivial numbers of XPt objects are going
non-live, an assumption that i have not investigated further.
thoughts?
tx for the help,
kirk
|