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
|
|
2
(3) |
3
(14) |
4
(33) |
5
(1) |
6
(11) |
7
(4) |
8
(3) |
|
9
|
10
(13) |
11
(23) |
12
(4) |
13
(4) |
14
(7) |
15
(1) |
|
16
|
17
(29) |
18
(24) |
19
(5) |
20
(8) |
21
(8) |
22
(3) |
|
23
|
24
(1) |
25
(9) |
26
(4) |
27
(8) |
28
(7) |
29
(5) |
|
30
(6) |
31
(3) |
|
|
|
|
|
|
From: <fr...@be...> - 2005-10-07 13:58:30
|
Failed to add the mailinglist in my reply. Sorry.
----- Forwarded message from fr...@be... -----
Date: Fri, 07 Oct 2005 15:49:41 +0200
From: fr...@be...
Reply-To: fr...@be...
Subject: Re: [Valgrind-users] can't compile valgrind-3.0.1
To: Julian Seward <js...@ac...>
Quoting Julian Seward <js...@ac...>:
>
> It looks like
>
>> make[5]: Entering directory `/home/frank/valgrind-3.0.1/VEX'
>> i386-linux-gcc -Wall -g -o auxprogs/genoffsets auxprogs/genoffsets.c
>
> failed, and so you can't do:
>
>> ./auxprogs/genoffsets > pub/libvex_guest_offsets.h
>
> Why did the build of genoffsets fail? It is a simple C program.
It didn't fail to build. It was just build with
the wrong compiler. If it's a tool used in the build
process it mustn't use the host compiler
(i386-linux-gcc -> uclibc).
As a first cut i built it by hand using the local gcc and reran make.
Which had this result:
if i386-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../..
-I../../coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux
-I../../include -I/home/frank/valgrind-3.0.1/VEX/pub -DVGA_x86=1 -DVGO_linux=1
-DVGP_x86_linux=1 -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes
-Winline -Wall -Wshadow-O -g -Wno-long-long -MT syswrap-main.o -MD -MP -MF
".deps/syswrap-main.Tpo" -c -o syswrap-main.o syswrap-main.c; \
then mv -f ".deps/syswrap-main.Tpo" ".deps/syswrap-main.Po"; else rm -f
".deps/syswrap-main.Tpo"; exit 1; fi
syswrap-main.c: In function `getSyscallArgLayout':
syswrap-main.c:428: error: `OFFSET_x86_EAX' undeclared (first use in this
function)
syswrap-main.c:428: error: (Each undeclared identifier is reported only once
syswrap-main.c:428: error: for each function it appears in.)
syswrap-main.c:429: error: `OFFSET_x86_EBX' undeclared (first use in this
function)
syswrap-main.c:430: error: `OFFSET_x86_ECX' undeclared (first use in this
function)
syswrap-main.c:431: error: `OFFSET_x86_EDX' undeclared (first use in this
function)
syswrap-main.c:432: error: `OFFSET_x86_ESI' undeclared (first use in this
function)
syswrap-main.c:433: error: `OFFSET_x86_EDI' undeclared (first use in this
function)
syswrap-main.c:434: error: `OFFSET_x86_EBP' undeclared (first use in this
function)
make[4]: *** [syswrap-main.o] Error 1
make[4]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind/m_syswrap'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/frank/valgrind-3.0.1'
make: *** [all] Error 2
Regards,
Frank
----- End forwarded message -----
|
|
From: Julian S. <js...@ac...> - 2005-10-07 13:35:39
|
It looks like > make[5]: Entering directory `/home/frank/valgrind-3.0.1/VEX' > i386-linux-gcc -Wall -g -o auxprogs/genoffsets auxprogs/genoffsets.c failed, and so you can't do: > ./auxprogs/genoffsets > pub/libvex_guest_offsets.h Why did the build of genoffsets fail? It is a simple C program. J |
|
From: <fr...@be...> - 2005-10-07 13:17:57
|
Hi, i've a problem compiling valgrind-3.0.1: make distclean && ./configure --host=i386-linux --enable-tls && make [...] ar cru libdemangle.a cp-demangle.o cplus-dem.o demangle.o dyn-string.o safe-ctype.o i386-linux-ranlib libdemangle.a make[4]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind/m_demangle' Making all in m_dispatch make[4]: Entering directory `/home/frank/valgrind-3.0.1/coregrind/m_dispatch' make -C /home/frank/valgrind-3.0.1/VEX CC=i386-linux-gcc pub/libvex_guest_offsets.h make[5]: Entering directory `/home/frank/valgrind-3.0.1/VEX' i386-linux-gcc -Wall -g -o auxprogs/genoffsets auxprogs/genoffsets.c ./auxprogs/genoffsets > pub/libvex_guest_offsets.h /bin/sh: ./auxprogs/genoffsets: No such file or directory make[5]: *** [pub/libvex_guest_offsets.h] Error 127 make[5]: Leaving directory `/home/frank/valgrind-3.0.1/VEX' make[4]: *** [libvex_guest_offsets.h] Error 2 make[4]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind/m_dispatch' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/frank/valgrind-3.0.1/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/frank/valgrind-3.0.1' make: *** [all] Error 2 I also tried the recent svn but no luck either. make distclean && ./configure --host=i386-linux --enable-tls && make [...] make[4]: Leaving directory `/home/frank/valgrind/VEX' i386-linux-gcc -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -m32 -mpreferred-stack-boundary=2 -O2 -Wno-long-long -o memcheck -static -Wl,-defsym,valt_load_address=0xb0000000 -Wl,-T,../valt_load_address.lds -nodefaultlibs -nostartfiles -u _start mac_leakcheck.o mac_malloc_wrappers.o mc_main.o mac_shared.o mc_translate.o../coregrind/libcoregrind.a ../VEX/libvex.a -lgcc ../coregrind/libcoregrind.a(syswrap-x86-linux.o): In function `vgSysWrap_x86_linux_sys_syscall223_before': m_syswrap/syswrap-x86-linux.c:1900: undefined reference to `vgModuleLocal_linux_variant_PRE_sys_bproc' ../coregrind/libcoregrind.a(syswrap-x86-linux.o): In function `vgSysWrap_x86_linux_sys_syscall223_after': m_syswrap/syswrap-x86-linux.c:1912: undefined reference to `vgModuleLocal_linux_variant_POST_sys_bproc' collect2: ld returned 1 exit status make[3]: *** [memcheck] Error 1 make[3]: Leaving directory `/home/frank/valgrind/memcheck' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/frank/valgrind/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/frank/valgrind' Older svn version could be compiled but i ran into all kinds of problem when using them. With cachegrind i had a failed assertion every time i ran it. valgrind --tool=cachegrind ls ==6781== Cachegrind, an I1/D1/L2 cache profiler. ==6781== Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nethercote et al. ==6781== Using LibVEX rev 1410, a library for dynamic binary translation. ==6781== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==6781== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==6781== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==6781== For more details, rerun with: -v ==6781== --6781-- warning: Pentium with 12 K micro-op instruction trace cache --6781-- Simulating a 16 KB cache with 32 B lines Cachegrind: cg_main.c:486 (handleOneStatement): Assertion 'NULL == *storeAddrExpr' failed. ==6781== at 0xB0004134: panic (m_libcassert.c:175) ==6781== by 0xB0004133: vgPlain_assert_fail (m_libcassert.c:169) ==6781== by 0xB0000D18: handleOneStatement (cg_main.c:486) ==6781== by 0xB00013CE: cg_instrument (cg_main.c:694) ==6781== by 0xB004DB95: LibVEX_Translate (vex_main.c:465) ==6781== by 0xB0013181: vgPlain_translate (libvex_basictypes.h:162) ==6781== by 0xB001FFF2: handle_tt_miss (scheduler.c:591) ==6781== by 0xB0020383: vgPlain_scheduler (scheduler.c:712) ==6781== by 0xB003E9B3: vgModuleLocal_thread_wrapper (syswrap-linux.c:82) ==6781== by 0xB002E736: run_a_thread_NORETURN (syswrap-x86-linux.c:124) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==6781== at 0x40008A0: _dl_linux_resolve (in /lib/ld-uClibc-0.9.28.so) ==6781== by 0x4003388: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.28.so) ==6781== by 0x40036BE: (within /lib/ld-uClibc-0.9.28.so) ==6781== by 0x40008D4: _start (in /lib/ld-uClibc-0.9.28.so) Which version should i try? I would like to use memcheck/cachegrind and callgrind in a uclibc environment. TIA Frank |
|
From: Josef W. <Jos...@gm...> - 2005-10-06 22:46:25
|
Hi FYI, I just released the Callgrind port for Valgrind 3.0.x (with support for x86-64). Aside from the port, it has the same feature set as 0.9.12. Note that supporting the new architecture needs no changes to KCachegrind. Get it from http://kcachegrind.sourceforge.net/ Hoping for bug reports, feedback etc. Cheers, Josef PS: I fixed the final issue (detecting _dl_runtime_resolve even with a stripped ld.so) by comparing with the known code sequences (Thanks to John Reiser for the hint). |
|
From: Nicholas N. <nj...@cs...> - 2005-10-06 18:57:05
|
On Thu, 6 Oct 2005, Julian Seward wrote: >> Does Valgrind/memcheck work in profiling the C/C++ shared libraries >> dynamically loaded by a Java VM? > > I don't know. In theory it should. Johnny, you didn't give much output in your message. Can you give Valgrind's full output when run with the -v flag? Thanks. Nick |
|
From: Julian S. <js...@ac...> - 2005-10-06 18:32:39
|
> Does Valgrind/memcheck work in profiling the C/C++ shared libraries > dynamically loaded by a Java VM? I don't know. Try adding the flag --smc-check=all and see if that helps. J |
|
From: Johnny <joh...@ra...> - 2005-10-06 18:29:11
|
Hi Julian,
I used svn to get the trunk of Valgrind and it seems better with memory
management.
However, my server is a Java program and it terminates and gives me the
following error message when I try to start up.
at
jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lan
g.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at
jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang
.Object;)Ljava.lang.Object;(Unknown Source)
at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)L
java.lang.Object;(Unknown Source)
at
Does Valgrind/memcheck work in profiling the C/C++ shared libraries
dynamically loaded by a Java VM?
Thanks,
Johnny
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]
Sent: Sunday, October 02, 2005 2:59 PM
To: val...@li...
Cc: Johnny
Subject: Re: [Valgrind-users] Valgrind-3.0.1: VG_(get_memory_from_mmap):
newSuperblock's request for 2932736 bytes failed.
> Does anyone have any suggestions or ideas on how to get passed this?
Use the svn trunk instead, which has a completely new and more flexible
address space manager.
svn co svn://svn.valgrind.org/valgrind/trunk
./autogen.sh
./configure --prefix=
etc
Let us know if you have more success this way.
J
|
|
From: Manish M. <mma...@sp...> - 2005-10-06 17:15:52
|
Hello All, I ran the MySQL 5.0 tests and while running the the first test, Valgrind code dumped with the following stack trace. Can anyone help me interpret this result of what erroneous that has happened. Thanks -Manish [/tmp/mysql/extra] > ./resolve_stack_dump -s /tmp/mysql.sym -n /tmp/mysql.strace 0x80df566 handle_segfault + 566 0x841a17d __pthread_sighandler + 173 0x83f401d snm_10 + 5 0x8405b9a my_snprintf + 26 0x81649ff _ZN9MYSQL_LOG4openEPKc13enum_log_typeS1_10cache_typebmb + 1455 0x80e1d8f _Z22init_server_componentsv + 1007 0x80e2d7b main + 763 0x842a177 __libc_start_main + 439 0x8048161 _start + 33 (resolve_stack_dump is a mysql provided utility to map symbols (like 0x80df566) to appropriate function calls.) |
|
From: Irek S. <ij...@ii...> - 2005-10-06 04:28:39
|
> Interesting. Perhaps libdmallocxx.so somehow iterferes with VG > operation? [It doesn't appear to affect my VG-2.4 on a trivial test > case, but you can try linking without it and see if things improve.] Yes, the library did interfere. When I removed the library, then VG worked fine again. My apologies: I did use dmalloc to check my code, and then I forgot to remove "-ldmallocxx" from my Makefile. > It's been stripped. It still has a dynamic symbol table though, > which you can examine with "nm -D /usr/lib/libstdc++.so.6". This is useful information. Thanks. Paul, many thanks for responding to my post, and helping with the problem. Best, Irek |
|
From: Paul P. <ppl...@gm...> - 2005-10-06 03:07:17
|
On 10/5/05, Irek Szczesniak <ij...@ii...> wrote: > > Paul Pluzhnikov wrote: > > > Probably linking with libc.a or linking static malloc() ... > > What does 'nm simone | grep malloc' report? > > This command returns nothing, because I am not using malloc. The > program is written in C++. Well, this definitely confirms that you are *not* linking static malloc. The command 'ldd simone' says: > > > libdmallocxx.so =3D> /usr/lib/libdmallocxx.so (0x00c79000) Interesting. Perhaps libdmallocxx.so somehow iterferes with VG operation? [It doesn't appear to affect my VG-2.4 on a trivial test case, but you can try linking without it and see if things improve.] But 'nm -C /usr/lib/libstdc++.so.6' says: > > > nm: /usr/lib/libstdc++.so.6: no symbols > > which is a new thing on me. It's been stripped. It still has a dynamic symbol table though, which you can examine with "nm -D /usr/lib/libstdc++.so.6". Cheers, |
|
From: Irek S. <ij...@ii...> - 2005-10-06 02:34:06
|
Thank you, Paul, for your reply. Paul Pluzhnikov wrote: >> I used massif before with the same code and got some results. What >> am I doing wrong this time? > > Probably linking with libc.a or linking static malloc() > implementation from some other library. > What does 'nm simone | grep malloc' report? This command returns nothing, because I am not using malloc. The program is written in C++. The command 'nm -C simone | grep new' returns among other things this: > U operator new[](unsigned int) > U operator new(unsigned int) > 0804ba90 W operator new(unsigned int, void*) The command 'ldd simone' says: > libdmallocxx.so => /usr/lib/libdmallocxx.so (0x00c79000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x009e0000) > libm.so.6 => /lib/tls/libm.so.6 (0x006d7000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00aad000) > libc.so.6 => /lib/tls/libc.so.6 (0x005ab000) > /lib/ld-linux.so.2 (0x00591000) But 'nm -C /usr/lib/libstdc++.so.6' says: > nm: /usr/lib/libstdc++.so.6: no symbols which is a new thing on me. Thanks & best, Irek |
|
From: Robert W. <rj...@du...> - 2005-10-06 02:21:20
|
> I have a follow-up question on this. How does valgrind control core > compatibility with client request APIs? I noticed that there are some > version checking between core and tools, but I didn't find any version > information related to APIs in valgrind.h/memcheck.h. Specifically for > this new suppression API, what would be the expected behavior if older > version valgrind core is used on the executable containing the new API? > Could you comment on these? I think it just spits out a warning, but I don't recall off the top of my head. BTW: I haven't had any time to work on this, and probably won't be able to until the weekend. Also, after the patch is ready, it has to receive approval to be integrated into the main tree, which is not guaranteed. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Paul P. <ppl...@gm...> - 2005-10-06 02:08:02
|
On 10/5/05, Irek Szczesniak <ij...@ii...> wrote: > > > I used massif before with the same code and got some results. What am > I doing wrong this time? Probably linking with libc.a or linking static malloc() implementation from some other library. What does 'nm simone | grep malloc' report? Cheers, |
|
From: Yin, H. <hu...@me...> - 2005-10-06 00:11:31
|
I have a follow-up question on this. How does valgrind control core compatibility with client request APIs? I noticed that there are some version checking between core and tools, but I didn't find any version information related to APIs in valgrind.h/memcheck.h. Specifically for this new suppression API, what would be the expected behavior if older version valgrind core is used on the executable containing the new API? Could you comment on these? Thanks and regards, --Hui PS. If needed I'll be happy to help testing the patch for this support. >=20 > This isn't present in Valgrind at the moment, but I'd imagine=20 > it wouldn't be too difficult to add in via a new client=20 > request. Look in m_errormgr.c at=20 > load_one_suppressions_file() to see how suppressions are=20 > loaded. Add in a new entry point that adds a single=20 > suppression in the same way, add a new client request that=20 > calls this (look in m_scheduler/scheduler.c at=20 > do_client_request()) with, perhaps, a text string as an=20 > argument, and Bob's your uncle. >=20 > I imagine that your library initialization code would call this. >=20 > I'll look at doing something like this tonight or tomorrow=20 > night - way to busy at work at the moment. >=20 > Regards, > Robert. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads,=20 > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 |
|
From: Irek S. <ij...@ii...> - 2005-10-05 22:43:08
|
I have a question on the massif tool. I am using Valgrind v. 2.2.0 on Fedora 3, Linux 2.6.10. When I run my program with Valgrind with the massif tool, I get this results: > ==5848== Total spacetime: 0 ms.B > ==5848== heap: (n/a) > ==5848== heap admin: (n/a) > ==5848== stack(s): 0% The file massif.5848.txt has: > Command: ./simone > > (No heap memory allocated) And the image massif.5848.ps has a blank plot. I used massif before with the same code and got some results. What am I doing wrong this time? Thanks for reading! Best, Irek |
|
From: Tom H. <to...@co...> - 2005-10-04 23:36:00
|
In message <bd8...@ma...>
Harold Naparst <ha...@al...> wrote:
> > Somebody was working on a remote debugging stub or something so that
> > gdb would actually be controlling the simulated CPU with valgrind's
> > help but I have no idea what happened to that.
>
> Do you mean this part of your post? I certainly didn't intentionally remove
> it, but are you saying that it exists, it should exist, or it will exist,
> or your hoping I'll make it exist?
That was the bit I meant - it just shows really that this has come
up before and a solution was proposed and I believe somebody did some
work on it.
Doubtless if somebody finds this a significant enough issue then they
will spend some time working on it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harold N. <ha...@al...> - 2005-10-04 23:26:20
|
> Somebody was working on a remote debugging stub or something so that > gdb would actually be controlling the simulated CPU with valgrind's > help but I have no idea what happened to that. Tom, Do you mean this part of your post? I certainly didn't intentionally remove it, but are you saying that it exists, it should exist, or it will exist, or your hoping I'll make it exist? I honestly wish I were competent to write it, but I'm barely competent to use it, and most people would doubt even that. Harold |
|
From: Irek S. <ij...@ii...> - 2005-10-04 22:25:57
|
Nicholas Nethercote wrote:
>> Massif produces files massif.<pid>.ps and massif.<pid>.txt. I can
>> see in the massif.<pid>.ps image that indeed there is one function
>> that allocates a lot of memory. Unfortunately its name is cut
>> short, because it wouldn't fit into the image.
>
> Change the '16' in this line in massif/ms_main.c:
>
> if ( ! VG_(get_fnname)(xtree_snapshot->xpt->ip, buf2, 16)) {
>
> to something larger (anything less than 1024 should be ok).
Thank you for your response. I am happy that the author of massif
replied to my post! I made the change and got the name of the
function.
Thanks again & best,
Irek
|
|
From: Yin, H. <hu...@me...> - 2005-10-04 21:23:21
|
=20 > -----Original Message----- > From: val...@li...=20 > [mailto:val...@li...] On Behalf=20 > Of Robert Walsh > Sent: Tuesday, October 04, 2005 2:05 PM > To: Yin, Hui > Cc: val...@li... > Subject: Re: [Valgrind-users] suppression API support? >=20 > > I wonder whether it is possible for valgrind to take the > > suppression information via an api rather than via a > > suppression file. We are advocating the valgrind memcheck > > tool to our customer. All the user code from=20 > customers will be > > loaded into our software as shared libraries and=20 > get executed. > > If we use a suppresion file to suppress the error=20 > reports from > > our own code, then we have to ship suppression file to the > > customer. And we don't want to expose that information. It > > would be much desired if a valgrind api is available for > > adding suppression information from inside our software. Is > > this possible? >=20 > This isn't present in Valgrind at the moment, but I'd imagine=20 > it wouldn't be too difficult to add in via a new client=20 > request. Look in m_errormgr.c at=20 > load_one_suppressions_file() to see how suppressions are=20 > loaded. Add in a new entry point that adds a single=20 > suppression in the same way, add a new client request that=20 > calls this (look in m_scheduler/scheduler.c at=20 > do_client_request()) with, perhaps, a text string as an=20 > argument, and Bob's your uncle. >=20 > I imagine that your library initialization code would call this. >=20 > I'll look at doing something like this tonight or tomorrow=20 > night - way to busy at work at the moment. >=20 > Regards, > Robert. That'll be really great! Yes, our code would call this to add suppression information. I really appreciate your fast response. Hope this will benefit many other commercial users like us. Regards, --Hui >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads,=20 > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 |
|
From: Nicholas N. <nj...@cs...> - 2005-10-04 21:11:06
|
On Tue, 4 Oct 2005, Irek Szczesniak wrote:
> I have a question on the massif tool. Valgrind and massif have been
> working great showing that indeed there is a problem with my code.
> However, I am unable to trace where the problem exactly is. I am
> using Valgrind v. 2.2.0 on Fedora 3, Linux 2.6.10.
>
> Massif produces files massif.<pid>.ps and massif.<pid>.txt. I can see
> in the massif.<pid>.ps image that indeed there is one function that
> allocates a lot of memory. Unfortunately its name is cut short,
> because it wouldn't fit into the image.
Change the '16' in this line in massif/ms_main.c:
if ( ! VG_(get_fnname)(xtree_snapshot->xpt->ip, buf2, 16)) {
to something larger (anything less than 1024 should be ok).
Nick
|
|
From: Irek S. <ij...@ii...> - 2005-10-04 21:05:53
|
I have a question on the massif tool. Valgrind and massif have been working great showing that indeed there is a problem with my code. However, I am unable to trace where the problem exactly is. I am using Valgrind v. 2.2.0 on Fedora 3, Linux 2.6.10. Massif produces files massif.<pid>.ps and massif.<pid>.txt. I can see in the massif.<pid>.ps image that indeed there is one function that allocates a lot of memory. Unfortunately its name is cut short, because it wouldn't fit into the image. So I know this function is: x80621D3:__gnu_cxx::new_ When I used the nm command to find the symbol __gnu_cxx::new_, numerous symbols matched, and no symbol is reported to be at the address x80621D3. Moreover, this address in not mentioned in the massif.<pid>.txt file, so I cannot track down what this function is. If needed, you can find the output files of the massif tool here: http://www.iitis.gliwice.pl/~iszczesniak/massif.5718.pdf http://www.iitis.gliwice.pl/~iszczesniak/massif.5718.txt Thanks for reading. I would appreciate your help. Thank you & best, Irek |
|
From: Robert W. <rj...@du...> - 2005-10-04 21:05:20
|
> I wonder whether it is possible for valgrind to take the > suppression information via an api rather than via a > suppression file. We are advocating the valgrind memcheck > tool to our customer. All the user code from customers will be > loaded into our software as shared libraries and get executed. > If we use a suppresion file to suppress the error reports from > our own code, then we have to ship suppression file to the > customer. And we don't want to expose that information. It > would be much desired if a valgrind api is available for > adding suppression information from inside our software. Is > this possible? This isn't present in Valgrind at the moment, but I'd imagine it wouldn't be too difficult to add in via a new client request. Look in m_errormgr.c at load_one_suppressions_file() to see how suppressions are loaded. Add in a new entry point that adds a single suppression in the same way, add a new client request that calls this (look in m_scheduler/scheduler.c at do_client_request()) with, perhaps, a text string as an argument, and Bob's your uncle. I imagine that your library initialization code would call this. I'll look at doing something like this tonight or tomorrow night - way to busy at work at the moment. Regards, Robert. |
|
From: Yin, H. <hu...@me...> - 2005-10-04 20:42:26
|
Sorry, just noticed that I screwed up the subject line in previous post. ________________________________ From: val...@li... [mailto:val...@li...] On Behalf Of Yin, Hui Sent: Tuesday, October 04, 2005 1:21 PM To: val...@li... Subject: [Valgrind-users] opatch suppression support? =09 =09 I wonder whether it is possible for valgrind to take the suppression information via an api rather than via a suppression file. We are advocating the valgrind memcheck tool to our customer. All the user code from customers will be loaded into our software as shared libraries and get executed. If we use a suppresion file to suppress the error reports from our own code, then we have to ship suppression file to the customer. And we don't want to expose that information. It would be much desired if a valgrind api is available for adding suppression information from inside our software. Is this possible? =20 Is there other possible approach exploiting the fact that our own code and the user code have a clear boundary. All user code will be in the shared libraries. Is there an existing client request mechanism we can use to limit the memcheck or error report on shared libraries only? =20 I appreciate your help. =20 Regards, --Hui |
|
From: Julian S. <js...@ac...> - 2005-10-04 20:41:27
|
The usual way to get sigbus on an x86 machine is to have a file mapping where the mapping is longer than the file, and access memory in that overhang area at the end. I wonder if this is somehow related to the shm bugs that Tom just fixed today. Can you svn up and see if the behaviour has changed? J |
|
From: Julian S. <js...@ac...> - 2005-10-04 20:30:29
|
> > $ valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput > > <valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> I believe these phenomena are due to a valgrinded process forking but not execing. I looked briefly at the printing logic in m_main.c and that is the most obvious explaination. It's not unique to XML though. You get the same nonsensical multiple-endings if you run normally, if the process forks and then both the parent and child terminate without the child doing an exec. J |