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: Nicholas N. <nj...@cs...> - 2005-05-05 14:52:03
|
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. N |
|
From: Nicholas N. <nj...@cs...> - 2005-05-05 14:11:55
|
On Thu, 5 May 2005, Tom Hughes wrote: >> Does this imply that both valgrind and kde need to update their websites? >> http://valgrind.org/devel/cvs_svn.html and >> http://developer.kde.org/source/anoncvs.html > > Probably, but as the change only occurred last night you might want to > give people a few hours to catch up ;-) 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 :) N |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-05 12:10:29
|
Running make regtest in valgrind-svn (vex revision 1159 and valgrind revision 3623) on debian/sarge results in the following errors. == 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) uname -a returns Linux DoornRoosje 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux memcheck/tests/writev fails because the output does not contain the procedure names (writev, readv, do_writev and do_readv). Ditto for corecheck/tests/fdleak_fcntl and fcntl. 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 none/tests/faultstatus fails in tests 5 .. 9 because of "vex x86->IR: unhandled instruction bytes". Ditto for one/tests/x86/int, which also runs into a signal 4 (SIGILL) instead of signal 11 (SIGSEGV). none/tests/tls fails because of + Process terminating with default action of signal 11 (SIGSEGV) + GPF (Pointer out of bounds?) If you need more information or bug reports for any or these problems, please let me know. Regards, Jeroen. |
|
From: Tom H. <to...@co...> - 2005-05-05 10:03:13
|
In message <13869.194.109.230.85.1115284919.squirrel@194.109.230.85>
Jeroen N. Witmond <jn...@xs...> wrote:
> "Tom Hughes" <to...@co...> wrote:
>
>> I believe it has been turned off as KDE have moved to subversion now.
>
> Does this imply that both valgrind and kde need to update their websites?
> http://valgrind.org/devel/cvs_svn.html and
> http://developer.kde.org/source/anoncvs.html
Probably, but as the change only occurred last night you might want to
give people a few hours to catch up ;-)
>> All new valgrind development is now in the valgrind subversion
>> repository anyway.
>
> Does that mean that bugfixes in the stable valgrind-2.4 line are also in
> subversion?
They will make their way to subversion yes. I'm not sure anybody is
actually doing any work on fixes to the 2.4 line anyway. I haven't
seen any commits there since the 2.4.0 release. If it did prove
necessary to do a 2.4.1 release then it would be done from the KDE
repository though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-05 09:22:10
|
"Tom Hughes" <to...@co...> wrote: > In message <21163.194.109.230.85.1115275842.squirrel@194.109.230.85> > Jeroen N. Witmond <jn...@xs...> wrote: > >> I am trying to access the valgrind cvs repository, but I keep getting >> error >> >> cvs [diff aborted]: connect to anoncvs.kde.org(134.2.170.97):2401 >> failed: >> Connection refused >> >> Can anybody help me out? > > I believe it has been turned off as KDE have moved to subversion now. Does this imply that both valgrind and kde need to update their websites? http://valgrind.org/devel/cvs_svn.html and http://developer.kde.org/source/anoncvs.html > > All new valgrind development is now in the valgrind subversion > repository anyway. Does that mean that bugfixes in the stable valgrind-2.4 line are also in subversion? Jeroen. |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-05 09:17:06
|
> While building valgrind-cvs on a Pentium III in debian/sarge (a.k.a. > debian/testing), memcheck/tests/scalar.c fails to compile because of > "/usr/include/asm/ipc.h:10: error: field `__user' has incomplete type". > This can be fixed by removing the #include <asm/ipc.h>. The same problem and fix apply to valgrind-svn, file memcheck/tests/x86/scalar.c. Regards, Jeroen Index: memcheck/tests/x86/scalar.c =================================================================== --- memcheck/tests/x86/scalar.c (revision 3623) +++ memcheck/tests/x86/scalar.c (working copy) @@ -14,7 +14,6 @@ // PRE_MEM_READ/PRE_MEM_WRITE calls. (Note that Memcheck and Addrcheck will // always issue an error message immediately before these seg faults occur). -#include <asm/ipc.h> #include <sched.h> #include <signal.h> |
|
From: Tom H. <to...@co...> - 2005-05-05 07:24:01
|
In message <21163.194.109.230.85.1115275842.squirrel@194.109.230.85>
Jeroen N. Witmond <jn...@xs...> wrote:
> I am trying to access the valgrind cvs repository, but I keep getting error
>
> cvs [diff aborted]: connect to anoncvs.kde.org(134.2.170.97):2401 failed:
> Connection refused
>
> Can anybody help me out?
I believe it has been turned off as KDE have moved to subversion now.
All new valgrind development is now in the valgrind subversion
repository anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-05 06:50:50
|
I am trying to access the valgrind cvs repository, but I keep getting error cvs [diff aborted]: connect to anoncvs.kde.org(134.2.170.97):2401 failed: Connection refused Can anybody help me out? Thanks, Jeroen. |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-04 22:09:16
|
While building valgrind-cvs on a Pentium III in debian/sarge (a.k.a. debian/testing), memcheck/tests/scalar.c fails to compile because of "/usr/include/asm/ipc.h:10: error: field `__user' has incomplete type". This can be fixed by removing the #include <asm/ipc.h>. While looking for more info on this error, I noticed that web page http://valgrind.org/support/bug_reports.html does not contain a link to a search page for existing valgrind bug reports. Should one be added to this page? Regards, Jeroen. |
|
From: Jeffrey S. <fe...@no...> - 2005-05-04 15:43:42
|
the parser in Alleyoop is pretty robust and supports all past versions of valgrind from 1.0's format up through 2.4 (at least in CVS... forget if I've made a release supporting 2.4 yet or not) it's also an incremental state parser so should be relatively nice for other apps to use (e.g. no blocking the ui, etc). Jeff On Wed, 2005-05-04 at 12:15 +0200, Josef Weidendorfer wrote: > On Wednesday 04 May 2005 08:07, Naba Kumar wrote: > > > Here's how I imagine the KDevelop plug-in works: you invoke Valgrind > > > somehow, and KDevelop works out what options to pass to Valgrind, > > > then runs Valgrind (and the user program under it), then collects > > > the output somehow, parses it, and presents it to the programmer > > > in the IDE somehow. > > > > There is nothing wrong in doing it the hard way, except that every IDE > > would be implementing it (which is a waste to begin with) and all of > > them would be struggling to maintain their parsers. Ask any developer > > who has maintained such CLI output (meant for human readability) parsers > > for a reasonable time how much fun it is. > > You can start by copying the parser from KDevelop or contact them for joined > efforts, and make the library with the API you propose yourself, basing it on > valgrind-listener; this is part of Valgrind itself, a redirection utility for > valgrinds output. It is perfect to put the CLI parser in there, and provide a > library instead. > If the API is simple and easy enough, the patched valgrind-listener (as a > library, and with the CLI parser) can be put back into Valgrind. And if the > parser is part of the valgrind package, I am sure that it will be kept up to > date for CLI changes. > I think this is even better than the "displayer plugin". > > No idea if this works bidirectional (e.g. for attaching to gdb). > > > The whole point of the suggestion is to make life easier for the IDE > > developers at the cost of offering some helpful API from valgrind. Even > > if full blown library interface is not feasible, as I mentioned earlier, > > having some sort of predictable and machine-readable output from > > valgrind would still be useful. > > > > Thanks. > > > > Regards, > > -Naba > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 great events, 4 > > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: David F. <dav...@bl...> - 2005-05-04 10:58:40
|
It might be worthwhile perusing the gdb <-> DDD interface. --david |
|
From: Josef W. <Jos...@gm...> - 2005-05-04 10:20:33
|
On Wednesday 04 May 2005 08:07, Naba Kumar wrote: > > Here's how I imagine the KDevelop plug-in works: you invoke Valgrind > > somehow, and KDevelop works out what options to pass to Valgrind, > > then runs Valgrind (and the user program under it), then collects > > the output somehow, parses it, and presents it to the programmer > > in the IDE somehow. > > There is nothing wrong in doing it the hard way, except that every IDE > would be implementing it (which is a waste to begin with) and all of > them would be struggling to maintain their parsers. Ask any developer > who has maintained such CLI output (meant for human readability) parsers > for a reasonable time how much fun it is. You can start by copying the parser from KDevelop or contact them for joined efforts, and make the library with the API you propose yourself, basing it on valgrind-listener; this is part of Valgrind itself, a redirection utility for valgrinds output. It is perfect to put the CLI parser in there, and provide a library instead. If the API is simple and easy enough, the patched valgrind-listener (as a library, and with the CLI parser) can be put back into Valgrind. And if the parser is part of the valgrind package, I am sure that it will be kept up to date for CLI changes. I think this is even better than the "displayer plugin". No idea if this works bidirectional (e.g. for attaching to gdb). > The whole point of the suggestion is to make life easier for the IDE > developers at the cost of offering some helpful API from valgrind. Even > if full blown library interface is not feasible, as I mentioned earlier, > having some sort of predictable and machine-readable output from > valgrind would still be useful. > > Thanks. > > Regards, > -Naba > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Naba K. <kh...@gm...> - 2005-05-04 06:19:40
|
Hi Nicholas,
On Wed, 2005-05-04 at 07:42, Nicholas Nethercote wrote:
> So what would that look like?
>
Okay, the kind of API we (the IDE developers) would generally prefer is
a sort of async updates from valgrind library while it executes the
process under scrutiny. There needs to be additional API to meaningfully
interpret the delivered data.
Now, I know little about the kind of data valgrind reports, but as an
example let's take the memory corruption/leak reports which are usually
accompanied by stack snapshots. Here is a rough sketch of such an API.
/* We begin by invoking valgrind to run the process: */
int valgrind_execute (update_callback, options, additional info ..);
/* The IDE updates its UI based on the callback. */
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 ...
}
}
/* Record functions */
ValgrindStackTrace* st = valgrind_record_get_stack(ValgrindRecord *r);
... Other functions to retrieve record information ...
/* Stack functions */
int valgrind_stack_get_length(ValgrindRecord *r);
ValgrindFrame* sf = valgrind_stack_get_frame(ValgrindRecord *r, int
index);
... Other stack and frame operations ...
Well, that was overly simplified view of the API in a language that I am
used to, but I hope you get the point.
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 :).
>
> Here's how I imagine the KDevelop plug-in works: you invoke Valgrind
> somehow, and KDevelop works out what options to pass to Valgrind,
> then runs Valgrind (and the user program under it), then collects
> the output somehow, parses it, and presents it to the programmer
> in the IDE somehow.
>
There is nothing wrong in doing it the hard way, except that every IDE
would be implementing it (which is a waste to begin with) and all of
them would be struggling to maintain their parsers. Ask any developer
who has maintained such CLI output (meant for human readability) parsers
for a reasonable time how much fun it is.
The whole point of the suggestion is to make life easier for the IDE
developers at the cost of offering some helpful API from valgrind. Even
if full blown library interface is not feasible, as I mentioned earlier,
having some sort of predictable and machine-readable output from
valgrind would still be useful.
Thanks.
Regards,
-Naba
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-04 02:12:14
|
On Tue, 3 May 2005, Naba Kumar wrote: >>> 3) API interface: This is the best and most preferred way for >>> the integration. In this case, valgrind offers a library that >>> an Anjuta plugin proxies to the IDE's internal interfaces. >> >> Out of interest, what does the API look like? Do you have a webpage >> describing it? >> > I think you misunderstood me. I was suggesting to have a library in > valgrind (e.g libvalgrind or something) that will give the necessary API > to IDE developers. So what would that look like? N |
|
From: Julian S. <js...@ac...> - 2005-05-03 18:40:53
|
Hi Joern Thanks for the bug report. > This lead me to believe that it is probably the shrd insruction that > looses validity information: Your analysis is right. Up to and including 2.4.0, memcheck approximated the behaviour of shrd/shld (but is exact for the normal shift insns). I can reproduce what you say using 2.4.0. Good news is that the 3.X line uses a new compilation pipeline which is significantly more accurate, not just for sh[lr]d but also for floating point and vector instructions. And so it runs your program without the false warning. 3.0 is still a work in progress, but is fairly solid on x86 and so you may want to use it instead. See http://www.valgrind.org/devel/cvs_svn.html for details on how to check it out of svn and build; it's easy. J (irrelevant details ...) 3.0's translation into IR of the offending insn is ... 0x80484C1: shrdl %cl, %esi, %ebx ------ IMark(0x80484C1, 3) ------ PUT(56) = 0x80484C1:I32 t25 = GET:I32(24) t26 = GET:I32(12) t27 = And8(GET:I8(4),0x1F:I8) t28 = 32HLto64(t25,t26) t29 = 64to32(Shr64(t28,t27)) t30 = 64to32(Shr64(t28,And8(Sub8(t27,0x1:I8),0x1F:I8))) PUT(32) = Mux0X(t27,GET:I32(32),0x1B:I32) PUT(36) = Mux0X(t27,GET:I32(36),t29) PUT(40) = Mux0X(t27,GET:I32(40),t30) PUT(44) = 0x0:I32 PUT(12) = t29 Because memcheck tracks exactly the behaviour of Shr64 and all the other primops, you get exact handling of shrdl "for free". |
|
From: Joern R. <joe...@st...> - 2005-05-03 18:03:07
|
I get false positives when running a gcc cross-compiler under valgrind 2.4.0 with the memcheck tool. It mallocs a simple bitmap, sets every bit in the bitmap, and later tests the bits. I have attached a stripped-down testcase. It appears that any 64-bit values that are fully initialized bit by bit are OK, as is testing any bit in the high part. However, the lowpart bits on the last (partially-initialized) 64 bit value generate a spurious error message from valgrind: ==7161== Conditional jump or move depends on uninitialised value(s) ==7161== at 0x804867B: check (valgrind-tst2.c:44) ==7161== by 0x8048736: main (valgrind-tst2.c:72) ==7161== ==7161== ERROR SUMMARY: 32 errors from 1 contexts (suppressed: 13 from 1) ==7161== malloc/free: in use at exit: 0 bytes in 0 blocks. ==7161== malloc/free: 1 allocs, 1 frees, 28 bytes allocated. ==7161== For counts of detected errors, rerun with: -v ==7161== No malloc'd blocks -- no leaks are possible. This lead me to believe that it is probably the shrd insruction that looses validity information: 0x080ca128 <verify_loop_structure+816>: shrd %cl,%edx,%eax $cl contains the lower 6 bit of the bit number, $edx the highpart, and $eax the lowpart of a 64 bit element. Only bit zero of the result is actually used - if any bit of this operation is used at all. The false positives are reproducible compiling the testcase with any of gcc 2.95.2 , 2.9.6 (redhat), 3.2.3 or 3.4.3 A further problem that I have observed is that there doesn't seem to be a way to attach gdb each time an error with identical backtrace is encountered. So when valgrind stops at the first iteration of a loop, you don't know if the problem is due to a special case in the first iteration, and the other instances are solely in other calls again at the first iteration, or if the problem appears in other iterations too. This is on Red Hat Enterprise Linux WS release 3 (Taroon Update 4) uname -a output: Linux linsvr1 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:31:57 EDT 2004 i686 athlon i386 GNU/Linux -bash-2.05b$ ls -l /lib/libc* -rwxr-xr-x 1 root root 1568524 Oct 22 2004 /lib/libc-2.3.2.so lrwxrwxrwx 1 root root 11 Sep 30 2004 /lib/libcap.so -> libcap.so.1 lrwxrwxrwx 1 root root 14 Sep 30 2004 /lib/libcap.so.1 -> libcap.so.1.10 -rwxr-xr-x 1 root root 10916 Jul 22 2004 /lib/libcap.so.1.10 lrwxrwxrwx 1 root root 17 Feb 6 03:38 /lib/libcom_err.so.2 -> libcom_err.so.2.0 -rwxr-xr-x 1 root root 5540 Oct 4 2004 /lib/libcom_err.so.2.0 -rwxr-xr-x 1 root root 23388 Oct 22 2004 /lib/libcrypt-2.3.2.so -rwxr-xr-x 1 root root 853564 Mar 8 2004 /lib/libcrypto.so.0.9.6b -rwxr-xr-x 1 root root 972156 Jun 22 2004 /lib/libcrypto.so.0.9.7a lrwxrwxrwx 1 root root 19 Feb 15 01:26 /lib/libcrypto.so.2 -> libcrypto.so.0.9.6b lrwxr-xr-x 1 root root 19 Sep 30 2004 /lib/libcrypto.so.4 -> libcrypto.so.0.9.7a lrwxrwxrwx 1 root root 17 Feb 6 03:38 /lib/libcrypt.so.1 -> libcrypt-2.3.2.so lrwxrwxrwx 1 root root 13 Feb 6 03:38 /lib/libc.so.6 -> libc-2.3.2.so |
|
From: Julian S. <js...@ac...> - 2005-05-03 17:44:48
|
All, As a result of recent memcheck hackery in the 3.0 line, I broke support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS client requests. I haven't fixed them; instead I am hoping to get rid of them altogether. They were introduced as an experimental hack, and as far as I know nobody ever used them. So my question is: does anybody use these? If you haven't a clue what this is about, it's a pretty safe bet you don't use them. J |
|
From: Naba K. <kh...@gm...> - 2005-05-03 13:28:18
|
Hi Nicholas, On Tue, 2005-05-03 at 18:00, Nicholas Nethercote wrote: > > 3) API interface: This is the best and most preferred way for > > the integration. In this case, valgrind offers a library that > > an Anjuta plugin proxies to the IDE's internal interfaces. > > Out of interest, what does the API look like? Do you have a webpage > describing it? > I think you misunderstood me. I was suggesting to have a library in valgrind (e.g libvalgrind or something) that will give the necessary API to IDE developers. The reason why I believe it's a better solution than parsing CLI output is that it is easier to track and manage API changes in a library than CLI format changes. Maintaining a parser of valgrind output, that could change arbitrarily, is surely not going to be easier. > > In case(2) and case(3), the integration requires developing > > an Anjuta plugin, but that is the least difficult part since > > it will hardly span more than one source file. > > Yes. And unless a very general mechanism (such as the "displayer" module) > can be implemented in Valgrind, I think this is the right way to do it: > have extra code in Anjuta to deal with Valgrind, rather than extra code in > Valgrind to deal with Anjuta. > The suggested code in valgrind is not to deal with Anjuta, but to have an easy way for any IDE to deal with valgrind. The anjuta-plugin thing I said was for Anjuta and not for valgrind. I was just highlighting the point that if valgrind offers such a library, many IDEs will find it much easier to implement their plugins. It was also a comment for someone interested to write such a plugin for Anjuta (reference to a previous message in the thread). The "displayer" thing you suggested is a nice approach. I hope we it is implemented soon. Thanks. Regards, -Naba |
|
From: Nicholas N. <nj...@cs...> - 2005-05-03 12:52:36
|
On Tue, 3 May 2005, Duncan Sands wrote: >> Right. Unfortunately you've hit a dark corner of Valgrind that doesn't >> work very well. > > By the way, local procedures are much more widely used in a language > like Ada, than in C. I guess Ada-interoperability is a dark corner, then :) You're only the second person I recall being stung by this. > As a data point, I ran all the ACATS tests (see the gcc testsuite/ada > directory) under valgrind, and the majority of failures were spurious, > coming from the trampoline problem. On the other hand, there are about > 1800 tests, and only about 50 triggered the trampoline problem (I don't > recall the exact number), so it's not that common either. That's good to know; thanks for the data point. N |
|
From: Nicholas N. <nj...@cs...> - 2005-05-03 12:31:09
|
On Tue, 3 May 2005, Naba Kumar wrote: > 1) The classic "run and show stdout/stderr in message pane": > This is the most basic way of 'integration' and doesn't even > need an implementation. The user can simply set up the tool in > preferences. Apart from showing the outputs, there is no > interaction between Anjuta and the tool. However, I believe, > this is not the kind of integration you are expecting. > > 2) CLI interface: If valgrind supports some kind of CLI interface > (ala gdb), and I am not sure if such interface is even required > for valgrind, Anjuta can have a plugin that proxies valgrind's > CLI interface to IDE's GUI (menus and windows). This is actually > a very complicated integration and rather prone to breakages. > If full blown CLI is not required for valgrind, at least > having a machine parsable outputs (e.g. xml) could make it easier. Valgrind does not support a CLI interface. Its output is currently text only, albeit fairly structured text that should be easy to parse. We have thought about possibilities for more flexible output, ie. by having replacing a "displayer" module/program that is given the raw outputs and displays them appropriately (eg. normally, or in XML, or graphically) but no work has been done on this. > 3) API interface: This is the best and most preferred way for > the integration. In this case, valgrind offers a library that > an Anjuta plugin proxies to the IDE's internal interfaces. Out of interest, what does the API look like? Do you have a webpage describing it? > In case(2) and case(3), the integration requires developing > an Anjuta plugin, but that is the least difficult part since > it will hardly span more than one source file. Yes. And unless a very general mechanism (such as the "displayer" module) can be implemented in Valgrind, I think this is the right way to do it: have extra code in Anjuta to deal with Valgrind, rather than extra code in Valgrind to deal with Anjuta. > I hope someone wishing to implementation such an integration would > find it useful. As I mentioned before, KDevelop's plug-in would definitely be worth looking at for anyone interested in this. Valgrind GUIs like Alleyoop and Valgui are worth looking at also. N |
|
From: Duncan S. <bal...@fr...> - 2005-05-03 11:23:59
|
>From the manual: "3.3.6 Overlapping source and destination blocks The following C library functions copy some data from one memory block to another (or something similar): memcpy(), strcpy(), strncpy(), strcat(), strncat(). The blocks pointed to by their src and dst pointers aren't allowed to overlap. Memcheck checks for this. For example: ==27492== Source and destination overlap in memcpy(0xbffff294, 0xbffff280, 21) ==27492== at 0x40026CDC: memcpy (mc_replace_strmem.c:71) ==27492== by 0x804865A: main (overlap.c:40) ==27492== by 0x40246335: __libc_start_main (../sysdeps/generic/libc-start.c:129) ==27492== by 0x8048470: (within /auto/homes/njn25/grind/head6/memcheck/tests/overlap) ==27492== You don't want the two blocks to overlap because one of them could get partially trashed by the copying." 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. (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. All the best, Duncan. |
|
From: Duncan S. <bal...@fr...> - 2005-05-03 07:22:48
|
> > I guess my pointer to the local function is actually a pointer to the
> > trampoline code, so I guess I can use that as the start address. Any
> > idea how much code a trampoline can contain? Does it actually vary
> > depending on the number of local variables used as function arguments?
>
> No idea, but I'd hope it's small, eg. only a handful of instructions.
> The good thing is that you can be conservative -- all that will happen is
> that Valgrind will flush any translations it is holding for that range of
> addresses, which could possibly slow it down. Try 100 bytes, or 1000, see
> if that helps.
>From gcc/config/i386/i386.h:
/* On the 386, the trampoline contains two instructions:
mov #STATIC,ecx
jmp FUNCTION
The trampoline is generated entirely at runtime. The operand of JMP
is the address of FUNCTION relative to the instruction following the
JMP (which is 5 bytes long). */
/* Length in units of the trampoline for entering a nested function. */
#define TRAMPOLINE_SIZE (TARGET_64BIT ? 23 : 10)
> > I said that wrong: my program explodes, valgrind produces a ton of error
> > messages, and everything exits. valgrind is not crashing in any way as
> > far as I can see. I guess the problem is that in the routine in
> > question there are two code paths each of which leads to the address
> > being taken of a (different) local procedure - presumably this is
> > why there are sometimes different trampolines at the same stack address.
> > It is to be expected that the program dies if the wrong one is called...
>
> Right. Unfortunately you've hit a dark corner of Valgrind that doesn't
> work very well. As the commentary on bug #69511 suggests, we don't have a
> good solution for this problem, since detecting it would be very
> expensive.
By the way, local procedures are much more widely used in a language
like Ada, than in C. As a data point, I ran all the ACATS tests (see
the gcc testsuite/ada directory) under valgrind, and the majority of
failures were spurious, coming from the trampoline problem. On the
other hand, there are about 1800 tests, and only about 50 triggered
the trampoline problem (I don't recall the exact number), so it's not
that common either.
All the best,
Duncan.
|
|
From: Naba K. <kh...@gm...> - 2005-05-03 05:33:19
|
Hi all, We have been forwarded this email in our mailing list and find it interesting. > This type of IDE integration is something that is of great interest to > us at LANL. We have launched a project called the Eclipse Parallel > Tools Platform (see http://www.eclipse.org/ptp/). Valgrind-based tools > being integrated into this environment would be of interest to us. To > start, doing an Eclipse Rich Client Interface for them would be great. > This would allow them to be used as standalone tools with GUIs or used > as plugins to the Eclipse IDE. We're always looking for folks who are > interested in collaborating on projects like this with us. If this > would be of interest to you, please contact me directly. We would definitely like to have such an integration and I will give a brief idea of how such integration is possible. However, we are rather resource limited and hence will not be in a position to implement it. If there are people interested in such integration, we will be glad to offer help with the implementation. There are basically three levels of integration currently possible with Anjuta (2.0). 1) The classic "run and show stdout/stderr in message pane": This is the most basic way of 'integration' and doesn't even need an implementation. The user can simply set up the tool in preferences. Apart from showing the outputs, there is no interaction between Anjuta and the tool. However, I believe, this is not the kind of integration you are expecting. 2) CLI interface: If valgrind supports some kind of CLI interface (ala gdb), and I am not sure if such interface is even required for valgrind, Anjuta can have a plugin that proxies valgrind's CLI interface to IDE's GUI (menus and windows). This is actually a very complicated integration and rather prone to breakages. If full blown CLI is not required for valgrind, at least having a machine parsable outputs (e.g. xml) could make it easier. 3) API interface: This is the best and most preferred way for the integration. In this case, valgrind offers a library that an Anjuta plugin proxies to the IDE's internal interfaces. In case(2) and case(3), the integration requires developing an Anjuta plugin, but that is the least difficult part since it will hardly span more than one source file. I hope someone wishing to implementation such an integration would find it useful. Thanks. Regards, -Naba |
|
From: Jason E. <ja...@ca...> - 2005-05-02 23:30:28
|
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.
The lc_shadows assertion fails because it assumes that allocations cannot
be directly adjacent.
Thanks,
Jason
P.S. As an aside, I must say that I am very impressed at how gracefully
valgrind deals with the application replacing malloc. My initial
assumption was that it wouldn't work at all.
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-02 18:38:30
|
On Mon, 2 May 2005, Duncan Sands wrote: > If I have a routine that uses a trampoline, and I call it twice in > succession, won't that put the trampolines at the same address > and cause a problem? Or will it be the same trampoline, so no > problem? If it's the same trampoline, I think it should work. >> As for using VALGRIND_DISCARD_TRANSLATIONS, I guess after you call a >> function that uses a trampoline, you should use this macro with an address >> range that would cover where the trampoline was, eg. start at the address >> of some local variable and go a few hundred bytes beyond that. I realise >> this is not a very elegant way to do it. > > I guess my pointer to the local function is actually a pointer to the > trampoline code, so I guess I can use that as the start address. Any > idea how much code a trampoline can contain? Does it actually vary > depending on the number of local variables used as function arguments? No idea, but I'd hope it's small, eg. only a handful of instructions. The good thing is that you can be conservative -- all that will happen is that Valgrind will flush any translations it is holding for that range of addresses, which could possibly slow it down. Try 100 bytes, or 1000, see if that helps. > I said that wrong: my program explodes, valgrind produces a ton of error > messages, and everything exits. valgrind is not crashing in any way as > far as I can see. I guess the problem is that in the routine in > question there are two code paths each of which leads to the address > being taken of a (different) local procedure - presumably this is > why there are sometimes different trampolines at the same stack address. > It is to be expected that the program dies if the wrong one is called... Right. Unfortunately you've hit a dark corner of Valgrind that doesn't work very well. As the commentary on bug #69511 suggests, we don't have a good solution for this problem, since detecting it would be very expensive. N |