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
(1) |
2
(8) |
3
(9) |
4
(6) |
5
(13) |
6
(18) |
7
(2) |
|
8
(1) |
9
(6) |
10
(4) |
11
(6) |
12
(11) |
13
(3) |
14
|
|
15
(4) |
16
(5) |
17
(11) |
18
(3) |
19
(31) |
20
(2) |
21
(5) |
|
22
(3) |
23
(4) |
24
(1) |
25
(4) |
26
(7) |
27
(2) |
28
(6) |
|
29
(2) |
30
(2) |
31
(4) |
|
|
|
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-07 17:08:26
|
Nicholas wrote: > On Thu, 5 May 2005, Jeroen N. Witmond wrote: > >> memcheck/tests/x86/scalar fails because >> - line numbers do not match. I removed one line from the source (see >> previous mails) but the line numbers are off by three. >> - the format of some stack trace lines has changed: "__libc_start_main >> (...libc...)" vs. "__libc_start_main (in /...libc...)". >> - One error is not reported: >> - Syscall param sigaction(act) points to unaddressable byte(s) >> - at 0x........: syscall (in /...libc...) >> - by 0x........: __libc_start_main (in /...libc...) >> - by 0x........: ... >> - Address 0x........ is not stack'd, malloc'd or (recently) free'd > > This one should be fixed now. > You are right. It is fixed in both valgrind 2.4.0, and valgrind 3.0.0, where I first found it. (Nowadays, I should not use the name svn when I mean 3.0.0; it could cause confusion :-) Jeroen. |
|
From: Arne B. <abr...@xy...> - 2005-05-07 15:37:00
|
Hi all,
hope you guys can help me: I'm using a dynamic loaded module as part
of the net-snmp daemon. This module writes data into an xmlfile using
libxml2. When I run snmpd under valgrind, it displays three
memoryleaks after stopping the daemon.
I can't really see which are the memoryleaks exactly, because there
are (partly) no filenames/linenumbers given, I think this is because
of the callbacks.
The thing is, writing exactly the same data from an independent tool
using the same writing function does not yield any memory leaks.
Through commenting out parts of my module, I tracked the leaks down
into the xmlfile writing function, which makes use of a couple of
libxml2 functions.
Any ideas?
Arne
Here's my system setup:
Redhat 9.0 with newest updates
- couple of packages upgraded independently:
beecrypt-3.1.0-3
popt-1.9.1-0.3
db4-4.1.25-14
python-2.2.3-7
elfutils-0.95-2
elfutils-libelf-0.76-3
rpm-4.3.1-0.3
libpcap-0.8.3-3
libselinux-1.11.4-1
libxml2-2.6.19-1
lm_sensors-2.6.5-5
yum-2.2.0-1
Kernel 2.4.20-8 SMP
Processors Intel Xeon CPU 2.40GHz, Hyperthreading
Involved software versions:
valgrind-2.4.0
libxml2-2.6.19-1
net-snmp-5.2.1
Libc (rpm -qa | grep libc):
glibc-kernheaders-2.4-8.10
glibc-devel-2.3.2-27.9.7
glibc-common-2.3.2-27.9.7
glibc-2.3.2-27.9.7
Here's valgrinds output:
-----8<-----
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 346 from 16)
malloc/free: in use at exit: 453983 bytes in 16227 blocks.
malloc/free: 36957 allocs, 20730 frees, 2090457 bytes allocated.
For counts of detected errors, rerun with: -v
searching for pointers to 16227 not-freed blocks.
checked 2243900 bytes.
84 bytes in 1 blocks are definitely lost in loss record 66 of 129
at 0x1B903534: malloc (vg_replace_malloc.c:130)
by 0x1C6CC96E: ???
by 0x1C70EF3B: ???
by 0x1C70F112: ???
by 0x1C66BF97: ???
by 0x1C66C356: ???
by 0x1C67B163: ???
by 0x1C713C6F: ???
by 0x1C61862B: ???
by 0x1C615083: ???
by 0x1C6151F7: ???
by 0x1BA54CEC: process_set_group (table_array.c:654)
19664 (40 direct, 19624 indirect) bytes in 1 blocks are definitely lost in loss record 92 of 129
at 0x1B903534: malloc (vg_replace_malloc.c:130)
by 0x1C713922: ???
by 0x1C713BA0: ???
by 0x1C713CA7: ???
by 0x1C61862B: ???
by 0x1C615083: ???
by 0x1C6151F7: ???
by 0x1BA54CEC: process_set_group (table_array.c:654)
by 0x1BADF775: _ba_for_each (container_binary_array.c:312)
by 0x1BA55018: process_set_requests (table_array.c:806)
by 0x1BA55377: netsnmp_table_array_helper_handler (table_array.c:849)
by 0x1BA25037: netsnmp_call_handler (agent_handler.c:423)
396 (200 direct, 196 indirect) bytes in 1 blocks are definitely lost in loss record 95 of 129
at 0x1B903534: malloc (vg_replace_malloc.c:130)
by 0x1C66778A: ???
by 0x1C667DA0: ???
by 0x1C68D00E: ???
by 0x1C67B152: ???
by 0x1C713C6F: ???
by 0x1C61862B: ???
by 0x1C615083: ???
by 0x1C6151F7: ???
by 0x1BA54CEC: process_set_group (table_array.c:654)
by 0x1BADF775: _ba_for_each (container_binary_array.c:312)
by 0x1BA55018: process_set_requests (table_array.c:806)
LEAK SUMMARY:
definitely lost: 324 bytes in 3 blocks.
indirectly lost: 19820 bytes in 42 blocks.
possibly lost: 0 bytes in 0 blocks.
still reachable: 424495 bytes in 15246 blocks.
suppressed: 9344 bytes in 936 blocks.
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --show-reachable=yes
-----8<-----
Explanation:
process_set_group is part of the netsnmplibs and calls a function from
my dynamic module by issuing a
context->tad->cb->set_action(ag);
(line 654 in table_array.c). My funtion does some stuff and finally
writes the xmlfile.
Suppressions enabled:
Bugs in libpthread, librpm and thousands of
uninitialized jumps in libsnmp and snmpd
|
|
From: Robert W. <rj...@du...> - 2005-05-06 21:08:24
|
> Depends on what you call "real applications." Some serious engineering, > analysis, chemistry+physics, and statistics codes won't work properly > under such a vex/valgrind-3. Such codes care about precision, track > it before+during+after the calculations, and make dynamic choices > based on observed trends in numerical error. They will get a different > answer under vex/valgrind-3, and execute different code while doing so. BLAS does this, and a lot of scientific codes use BLAS (and/or LAPACK, which is based on BLAS.) Regards, Robert. |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 20:42:56
|
On Thu, 5 May 2005, Jeroen N. Witmond wrote: > memcheck/tests/x86/scalar fails because > - line numbers do not match. I removed one line from the source (see > previous mails) but the line numbers are off by three. > - the format of some stack trace lines has changed: "__libc_start_main > (...libc...)" vs. "__libc_start_main (in /...libc...)". > - One error is not reported: > - Syscall param sigaction(act) points to unaddressable byte(s) > - at 0x........: syscall (in /...libc...) > - by 0x........: __libc_start_main (in /...libc...) > - by 0x........: ... > - Address 0x........ is not stack'd, malloc'd or (recently) free'd This one should be fixed now. N |
|
From: John R.
|
Julian Seward wrote: > Vex/valgrind-3 simulates the x87 FPU in much more detail than > the 2.4 line. In order to reduce the complexity of this simulation, > vex does all floating point at 64-bits (IEEE double) regardless > of the FPU's control-word settings, but it "pretends" to the > program to be running the FPU in its default 80-bit mode. > > I've tested this extensively on a large amount of FP code, and it > appears that the differences between 64-bit and 80-bit precision > are pretty minimal for real applications. For one thing, > any program which actually relies on 80-bit precision to get > the right answer is inherently unportable and will not work on > (eg) PowerPC; nor will it work if recompiled on x86 to use > SSE-based floating point. Depends on what you call "real applications." Some serious engineering, analysis, chemistry+physics, and statistics codes won't work properly under such a vex/valgrind-3. Such codes care about precision, track it before+during+after the calculations, and make dynamic choices based on observed trends in numerical error. They will get a different answer under vex/valgrind-3, and execute different code while doing so. This will cause a very large "false negative" report from memcheck. IEEE double extended precision (C/gcc long double) also provides a larger exponent range than plain double, and this can be the most important reason for using long double; the extra precision may be "don't care." Some PowerPC compilers implement long double as two ordinary doubles, with a usual implied value of (hi + lo * 2**d) with d <= -53. Although this does not provide all of the expected benefits for IEEE arithmetic (no expanded exponent range, no strict adherence to rounding rules, confuses software that expects -53==d, ...), in many "real applications" it does provide enough additional precision to justify the costs. So there are important practical exceptions to the claim that x86 80-bit FP (expressed in C as long double) is not portable to PowerPC. -- John Reiser, jreiser@BitWagon.com |
|
From: Julian S. <js...@ac...> - 2005-05-06 17:15:34
|
Jeroen Thanks for that. We are slowly working to make the regression test system more robust, so that it produces more repeatable results across a wider range of linux distros. And, of course, fix any genuine errors it throws up. On my SuSE 9.1 box I now get: == 172 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) (vex r1168, valgrind r3625) Could you send me the relevant .stderr.diff and .stdout.diff files for the failures you mention? Also, if you wanted to continue to track the failure rate, that would be very useful. Currently the nightly builds on my base machine "phoenix ( SuSE 9.1 )" are for 2.4.0; I will change this over to auto-build the 3 line instead. As the regtest system becomes more robust I would hope that results on all x86-linux distros converge. J > == 173 tests, 7 stderr failures, 1 stdout failure ================= > memcheck/tests/leak-tree (stderr) > memcheck/tests/writev (stderr) > memcheck/tests/x86/scalar (stderr) > corecheck/tests/fdleak_fcntl (stderr) > none/tests/faultstatus (stderr) > none/tests/tls (stdout) > none/tests/tls (stderr) > none/tests/x86/int (stderr) |
|
From: Jason E. <ja...@ca...> - 2005-05-06 17:04:42
|
On Fri, May 06, 2005 at 10:26:35AM -0500, Nicholas Nethercote wrote:
>
> One downside of such allocations is that if your allocator doesn't have
> any redzones or metadata between blocks, you can't detect an overrun from
> one block into another, because it's all considered addressable by
> Memcheck.
Ahh, good point. I do have optional red zones embedded in the separators
that delimit user-allocated regions:
RRRR....RRRR
---------
RRRR....RRRR
----------
RRRR....RRRR
However, I was making the mistake of both telling valgrind that the
allocations (-----) have red zones (RRRR), and that the red zones are
allocated as part of the separators (RRRR....RRRR).
I've fixed my code to never tell valgrind that the red zones are allocated,
and it longer trips on the assertions, as long as red zones are enabled.
However, if red zones are disabled, my code still trips on both assertions
that the original patch addressed. In that case, memory looks like:
....
--------
....
------------
....
And valgrind has been told that the user allocations (----) and the
separators (....) are allocated. None of the allocations overlap, and I'm
no longer making the mistake of telling valgrind that red zones are
allocated.
So, as near as I can tell, the patch is still relevant, though my code no
longer trips on the bad assertions.
Thanks,
Jason
|
|
From: Avery F. <av...@po...> - 2005-05-06 16:06:43
|
On Fri, 2005-05-06 at 08:00 -0500, Nicholas Nethercote wrote: > > That output looks like the program has not yet exited, or Valgrind didn't > detect that it exited. Has the program definitely exited? Is Valgrind > still running? > > I know people have used Valgrind on daemons before, so I'm not aware of > any issues there. Is the program spawning any children -- does it make > any difference if you run with --trace-children=yes ? > > N It turns out the program was forking (I didn't think it was at first because it is largely threaded). valgrind was only watching the original process and not the one doing all the work. I've changed it around and gotten valgrind working now. Thanks, Avery |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 15:26:47
|
On Fri, 6 May 2005, Jason Evans wrote: > If I understand correctly, this is bad (overlapping): > > [------] > [-------] > > And this is bad (nested): > > [----------] > [----] > > But this is the scenario that is causing me trouble (adjacent): > > [------I------] > > The lc_shadows assertion requires there to be a gap of at least one byte > between allocations; merely being non-overlapping isn't good enough to > avoid triggering the assertion: > > [------] [------] > > Is it in fact important to valgrind that there be gaps between allocations? Off the top of my head, I'd guess no, and that the lc_shadows assertion is too restrictive. (I don't know about the lc_markstack assertion, that might be a bug.) One downside of such allocations is that if your allocator doesn't have any redzones or metadata between blocks, you can't detect an overrun from one block into another, because it's all considered addressable by Memcheck. N |
|
From: Jason E. <ja...@ca...> - 2005-05-06 15:18:54
|
On Thu, May 05, 2005 at 11:06:03PM -0700, Jeremy Fitzhardinge wrote:
> Jason Evans wrote:
>
> >========================================================================
> >diff -ru valgrind-2.4.0.orig/memcheck/mac_leakcheck.c valgrind-2.4.0/memcheck/mac_leakcheck.c
> >--- valgrind-2.4.0.orig/memcheck/mac_leakcheck.c 2005-03-10 22:28:15.000000000 -0800
> >+++ valgrind-2.4.0/memcheck/mac_leakcheck.c 2005-05-02 16:16:22.659375486 -0700
> >@@ -589,7 +588,7 @@
> > /* Sanity check -- make sure they don't overlap */
> > for (i = 0; i < lc_n_shadows-1; i++) {
> > sk_assert( lc_shadows[i]->data + lc_shadows[i]->size
> >- < lc_shadows[i+1]->data );
> >+ <= lc_shadows[i+1]->data );
> > }
> >
> > if (lc_n_shadows == 0) {
> >========================================================================
> >
> >I ran into these problems when adding VALGRIND_{MALLOC,FREE}LIKE_BLOCK()
> >calls to a malloc library that I implemented. The malloc library
> >completely replaces all malloc(3)-related APIs. In order to avoid UMRs, I
> >have to tell valgrind that the separators between regions are allocated,
> >and the same applies to data structures that are stored in cached free
> >regions.
> >
> >
> It's a bit more subtle than that. Valgrind has an assumption that
> malloc blocks are not nested, so you can't have a user-defined allocated
> block within a malloced block. The workaround is to use mmap() to
> allocate memory for your malloc replacement.
If I understand correctly, this is bad (overlapping):
[------]
[-------]
And this is bad (nested):
[----------]
[----]
But this is the scenario that is causing me trouble (adjacent):
[------I------]
The lc_shadows assertion requires there to be a gap of at least one byte
between allocations; merely being non-overlapping isn't good enough to
avoid triggering the assertion:
[------] [------]
Is it in fact important to valgrind that there be gaps between allocations?
Thanks,
Jason
P.S. As for my malloc implementation, it does use mmap(), and it does take
care to avoid ever telling valgrind that allocations overlap/nest
(which BTW made adding the valgrind macro calls very tricky). It's a
complete malloc replacement, rather than an allocator that builds on
top of the system malloc.
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-06 13:33:49
|
> On Fri, 6 May 2005, Jeroen N. Witmond wrote: > >> One small nitpick: there shoud be no slash following "svn co >> svn://anonsvn.kde.org/home/kde/trunk/valgrind". With the slash, I get >> this >> error: "svn: Malformed network data"; without the slash, it works as >> expected. > > It works for me with the slash. Could something else have gone wrong when > you tried it? > I guess so. I just tried it again with the slash, and now the checkout works as expected (revision 410022). Sorry to have bothered you. Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 13:20:49
|
On Wed, 4 May 2005, Naba Kumar wrote:
> void
> update_callback (ValgrindRecord *r, other info ...)
> {
> switch valgrind_record_get_type (r)
> {
> case VALGRIND_RECORD_MEMLEAK:
> ... update mem leak report ...
> case VALGRIND_RECORD_MEMCORRUPT:
> ... update mem corruption report ...
> }
> }
>
> [snip]
>
> I understand that valgrind could not be operated in the same process
> space as the main program and hence the difficulty in making it a
> library. It's one unfortunate situation that I hope you people could
> come around :).
Yes, that is a challenge. Something like a socket-based approach, passing
packets describing errors, could be the way to do it. I wouldn't hold
your breath for someone to implement it, though, since there has been
little demand for such a thing so far.
N
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 13:09:19
|
On Thu, 5 May 2005, Eric Hanchrow wrote: > I checked out the above, ran "autogen.sh", and then ran "./configure > --prefix=/usr/local/stow/valgrind-svn". So far, so good. Then I did > "make all check install", which failed because the file > coregrind/demangle/ansidecl.h was missing. (I think that file comes > from gcc.) Looks like they got lost in KDE's CVS-->Subversion conversion. I just tried to add them but discovered I don't have permission to commit to that branch! I've told the relevant KDE people, hopefully they'll give me permission soon and it will be fixed soon. Thanks for letting us know about this. > I imagine that I can grab a copy of that file (and a > couple of others in that directory that are similarly missing) from > somewhere or other, but that doesn't seem like the right thing to do. That should be fine as a temporary workaround; grab them from any recent version of Valgrind, I don't think they've changed in a long time. N |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 13:00:09
|
On Thu, 5 May 2005, Avery Fay wrote: > I'm trying to use valgrind 2.4.0 on Debian to fix some memory problems. > When I run my program, everything appears ok, but when the program exits > nothing happens. Nothing is printed and in the case of massif, no files > are generated. I know that valgrind works on other programs (I tried ls > at least). The following is all I ever get: > > ==11136== Massif, a space profiler for x86-linux. > ==11136== Copyright (C) 2003, Nicholas Nethercote > ==11136== Using valgrind-2.4.0, a program supervision framework for > x86-linux. > ==11136== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et > al. > ==11136== For more details, rerun with: -v > ==11136== > > And then nothing. Any idea what could be causing this? I'm running > valgrind on a daemon, so I'm guessing it might have to do with the way > it's exiting. Can I just run kill on the pid? That output looks like the program has not yet exited, or Valgrind didn't detect that it exited. Has the program definitely exited? Is Valgrind still running? I know people have used Valgrind on daemons before, so I'm not aware of any issues there. Is the program spawning any children -- does it make any difference if you run with --trace-children=yes ? N |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 12:57:18
|
On Fri, 6 May 2005, Jeroen N. Witmond wrote: > One small nitpick: there shoud be no slash following "svn co > svn://anonsvn.kde.org/home/kde/trunk/valgrind". With the slash, I get this > error: "svn: Malformed network data"; without the slash, it works as > expected. It works for me with the slash. Could something else have gone wrong when you tried it? N |
|
From: Julian S. <js...@ac...> - 2005-05-06 11:10:01
|
> while trying and playing with valgrind3 from cvs I ran with emulation > warnings enabled and encountered this message : > > ==18820== Emulation warning: unsupported action: > ==18820== Selection of non-80-bit x87 FP precision > > What exactly does this mean ? Does valgrind/vex not yet support 32Bit > floating point ? Will it ever ? Vex/valgrind-3 simulates the x87 FPU in much more detail than the 2.4 line. In order to reduce the complexity of this simulation, vex does all floating point at 64-bits (IEEE double) regardless of the FPU's control-word settings, but it "pretends" to the program to be running the FPU in its default 80-bit mode. I've tested this extensively on a large amount of FP code, and it appears that the differences between 64-bit and 80-bit precision are pretty minimal for real applications. For one thing, any program which actually relies on 80-bit precision to get the right answer is inherently unportable and will not work on (eg) PowerPC; nor will it work if recompiled on x86 to use SSE-based floating point. If, later in the day, the lack of genuine 80-bit FP support turns out to be a critical problem, then perhaps it can be added. Note that 80-bit loads/stores (fldt/fstpt) behave as you would expect, correctly reading/writing an 80-bit image. So, to answer your question, if your code is attempting to set the FPU's precision level to 64 or 32-bits, V ignores this and shows the above message. I don't believe this should cause you any problems in practice. > PS: What further information do you need to resolve this error > "m_debuglog.c:129:3: #error Unknown platform" ? (Im running on x86 > linux...) Uh, I don't see how you got that. Are your valgrind and vex trees up to date? One thing is, since both are works-in-progress, you really need to 'svn up' both of them at once and rebuild both. J |
|
From: Jeremy F. <je...@go...> - 2005-05-06 09:11:59
|
Duncan Sands wrote:
>Maybe it's worth giving more of an explanation here. I've noticed while floating around on the internet
>that people thing valgrind is just being pedantic when giving this warning and target < source. There are
>two problems:
>
>(1) if copying is done from largest address to smallest address. I don't know of any memcpy that does this.
>
>
The some optimisation guide (AMD? Via?) recommends it for some cases.
>(2) if memcpy zeroes out the target before copying. This has been shown to improve the performance of memcpy
>on some intel architectures, due to cache effects. Of course it is fatal if there is any overlap between
>source and target. Most memcpy's don't do this kind of trick, but it's worth keeping in mind.
>
>
I think it's common on the PPC, because the dcbz instruction zeros a
cache line in preparation for the destination write (this is based on 5
year old PPC experience, so I don't know what's best on a modern
implementation).
J
|
|
From: Jeremy F. <je...@go...> - 2005-05-06 09:11:59
|
Jason Evans wrote:
>I've run into two problems with valgrind that the following patch works
>around:
>
>========================================================================
>diff -ru valgrind-2.4.0.orig/memcheck/mac_leakcheck.c valgrind-2.4.0/memcheck/mac_leakcheck.c
>--- valgrind-2.4.0.orig/memcheck/mac_leakcheck.c 2005-03-10 22:28:15.000000000 -0800
>+++ valgrind-2.4.0/memcheck/mac_leakcheck.c 2005-05-02 16:16:22.659375486 -0700
>@@ -431,7 +431,6 @@
> lc_do_leakcheck(i);
>
> sk_assert(lc_markstack_top == -1);
>- sk_assert(lc_markstack[i].state == IndirectLeak);
>
> lc_markstack[i].state = Unreached; /* Return to unreached state,
> to indicate its a clique
>@@ -589,7 +588,7 @@
> /* Sanity check -- make sure they don't overlap */
> for (i = 0; i < lc_n_shadows-1; i++) {
> sk_assert( lc_shadows[i]->data + lc_shadows[i]->size
>- < lc_shadows[i+1]->data );
>+ <= lc_shadows[i+1]->data );
> }
>
> if (lc_n_shadows == 0) {
>========================================================================
>
>I ran into these problems when adding VALGRIND_{MALLOC,FREE}LIKE_BLOCK()
>calls to a malloc library that I implemented. The malloc library
>completely replaces all malloc(3)-related APIs. In order to avoid UMRs, I
>have to tell valgrind that the separators between regions are allocated,
>and the same applies to data structures that are stored in cached free
>regions.
>
>I don't understand why the IndirectLeak assertion fails for my code, but
>I'm guessing that it's an assertion that is only valid for valgrind's own
>malloc replacement.
>
>
It's a bit more subtle than that. Valgrind has an assumption that
malloc blocks are not nested, so you can't have a user-defined allocated
block within a malloced block. The workaround is to use mmap() to
allocate memory for your malloc replacement.
J
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-06 08:12:54
|
> I checked out the above, ran "autogen.sh", and then ran "./configure > --prefix=/usr/local/stow/valgrind-svn". So far, so good. Then I did > "make all check install", which failed because the file > coregrind/demangle/ansidecl.h was missing. FWIW, I have just checked out svn://anonsvn.kde.org/home/kde/trunk/valgrind (note: the trunk, not the tagged version), and it configures and compiles without problems (on x86 debian/sarge). File coregrind/demangle/ansidecl.h is present in the source tree. Regards, Jeroen. |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-06 07:42:29
|
> On Thu, 5 May 2005, Nicholas Nethercote wrote: > >> I tried last night, the KDE CVS was still usable but read-only. I >> didn't >> change the Valgrind site instructions because KDE hadn't changed their's >> so I >> didn't know how to access anonymous SVN :) > > Ok, I've updated the page now. > One small nitpick: there shoud be no slash following "svn co svn://anonsvn.kde.org/home/kde/trunk/valgrind". With the slash, I get this error: "svn: Malformed network data"; without the slash, it works as expected. Regards, Jeroen. |
|
From: Dennis L. <pla...@tz...> - 2005-05-05 22:22:26
|
Hi, while trying and playing with valgrind3 from cvs I ran with emulation warnings enabled and encountered this message : ==18820== Emulation warning: unsupported action: ==18820== Selection of non-80-bit x87 FP precision What exactly does this mean ? Does valgrind/vex not yet support 32Bit floating point ? Will it ever ? greets Dennis PS: What further information do you need to resolve this error "m_debuglog.c:129:3: #error Unknown platform" ? (Im running on x86 linux...) -- Dennis Lubert <pla...@tz...> |
|
From: Avery F. <av...@po...> - 2005-05-05 22:11:35
|
Hi, I'm trying to use valgrind 2.4.0 on Debian to fix some memory problems. When I run my program, everything appears ok, but when the program exits nothing happens. Nothing is printed and in the case of massif, no files are generated. I know that valgrind works on other programs (I tried ls at least). The following is all I ever get: ==11136== Massif, a space profiler for x86-linux. ==11136== Copyright (C) 2003, Nicholas Nethercote ==11136== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==11136== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==11136== For more details, rerun with: -v ==11136== And then nothing. Any idea what could be causing this? I'm running valgrind on a daemon, so I'm guessing it might have to do with the way it's exiting. Can I just run kill on the pid? I'm not subscribe so please CC any replies. Thanks, Avery |
|
From: Eric H. <of...@bl...> - 2005-05-05 18:21:01
|
I checked out the above, ran "autogen.sh", and then ran "./configure
--prefix=/usr/local/stow/valgrind-svn". So far, so good. Then I did
"make all check install", which failed because the file
coregrind/demangle/ansidecl.h was missing. (I think that file comes
from gcc.) I imagine that I can grab a copy of that file (and a
couple of others in that directory that are similarly missing) from
somewhere or other, but that doesn't seem like the right thing to do.
What, then, is the recommended way of building valgrind from
Subversion?
--
If there were a little guy running around inside the computer
executing our programs, he would probably have as long and
plaintive a tale to tell about his job as a federal government
employee.
-- Paul Graham
|
|
From: Tom H. <to...@co...> - 2005-05-05 16:28:01
|
In message <B1A...@nl...>
William Fulton <Wil...@ub...> wrote:
> Is helgrind no longer a valid tool, or maybe it needs configuring in?
To quote the NEWS file:
* On the downside, Valgrind can no longer report misuses of the POSIX
PThreads API. It also means that Helgrind currently does not work.
We hope to fix these problems in a future release.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <Wil...@ub...> - 2005-05-05 16:15:43
|
Is helgrind no longer a valid tool, or maybe it needs configuring in?
William
$ valgrind --version
valgrind-2.4.0
$ valgrind --tool=3Dhelgrind ls -l
Can't open tool "helgrind": =
/home/fultonwi/install/valgrind/lib/valgrind/vgskin_helgrind.so: cannot =
open shared object file: No such file or directory
valgrind: couldn't load tool
Available tools:
memcheck
addrcheck
cachegrind
corecheck
massif
lackey
none
$=20
--=20
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
|