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
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-24 14:13:26
|
On Wed, 24 Aug 2005, Christian Parpart wrote: > I'm having the following backtrace in my server's shutdown summary of VG: > > ==13271== 16 bytes in 1 blocks are still reachable in loss record 8 of 56 > ==13271== at 0x1B905E1A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so) > ==13271== by 0x1CFCB3A3: (within /lib/libdl-2.3.5.so) > ==13271== by 0x1CFCAD60: dlopen (in /lib/libdl-2.3.5.so) > > Well, I'm pretty pretty sure that I dlclose()'d every > module and plugin I've been loading, although, this is > somewhat far within dlopen() itself. > > So, might this be a dlopen() bug or did it expect *me* to > free some struct from him? I'd guess it's within dlopen(). And the block is still reachable, so it's not a true leak, so it's probably not worth worrying about. N |
|
From: Christian P. <tr...@ge...> - 2005-08-24 11:40:03
|
Hi all, I'm having the following backtrace in my server's shutdown summary of VG: =3D=3D13271=3D=3D 16 bytes in 1 blocks are still reachable in loss record 8= of 56 =3D=3D13271=3D=3D at 0x1B905E1A: calloc (in /usr/lib/valgrind/vgpreload_= memcheck.so) =3D=3D13271=3D=3D by 0x1CFCB3A3: (within /lib/libdl-2.3.5.so) =3D=3D13271=3D=3D by 0x1CFCAD60: dlopen (in /lib/libdl-2.3.5.so) =3D=3D13271=3D=3D by 0x1C56A580: System::Runtime::TLibrary::TLibrary(Sys= tem::TStringBase<char> const&, System::TStringBase<char> const&) (TLibrary.= cpp:38) =3D=3D13271=3D=3D by 0x1C56B6A1: System::Runtime::TLibraryMgr::loadLibra= ry(System::TStringBase<char> const&) (TLibraryMgr.cpp:92) =3D=3D13271=3D=3D by 0x1BA73A63: yacs::TServer::loadModule(System::TStri= ngBase<char> const&, System::TStringBase<char> const&) (TServer.cpp:518) =3D=3D13271=3D=3D by 0x1BA73748: yacs::TServer::loadModule(System::TStri= ngBase<char> const&) (TServer.cpp:511) =3D=3D13271=3D=3D by 0x806287B: loadModules(yacs::TServer*) (yacsd.cpp:2= 49) =3D=3D13271=3D=3D by 0x8064E14: spawnServer() (yacsd.cpp:310) =3D=3D13271=3D=3D by 0x80659FA: main (yacsd.cpp:388) Well, I'm pretty pretty sure that I dlclose()'d every=20 module and plugin I've been loading, although, this is somewhat far within dlopen() itself. So, might this be a dlopen() bug or did it expect *me* to free some struct from him? Regards, Christian Parpart. p.s.: this time, it has been run from an x86 (not amd64) |
|
From: Christian P. <tr...@ge...> - 2005-08-23 19:43:32
|
On Tuesday 23 August 2005 20:20, John Reiser wrote: > >> Complete coverage of i686 user-mode opcodes also matters to me. > > > > Why? > > Because I have my own compilers.=20 Huh? you've your *own* compilerS? interesting? Any way to look at them? I'm= =20 curious :D Regards, Christian Parpart. |
|
From: John R.
|
>> Complete coverage of i686 user-mode opcodes also matters to me. > Why? Because I have my own compilers. Also, even when clients use gcc, I could then recommend valgrind without having to add the caveat, "you might see some unhandled instruction bytes, which means that progress stops for some time while either valgrind adjusts its code or you adjust yours." And it's hard when the offending opcode is in glibc, such as 'fxtract' for *logb(). -- |
|
From: Nicholas N. <nj...@cs...> - 2005-08-23 15:50:46
|
On Fri, 19 Aug 2005, John Reiser wrote: > Complete coverage of i686 user-mode opcodes also matters to me. Why? Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-08-23 15:16:31
|
On Thu, 18 Aug 2005, Rob Holland wrote: > On Thu, 2005-08-18 at 23:13 +0100, Tom Hughes wrote: >> I'd be surprised if that works - that dlopen would normally return a >> handle for the existing C library which would meand the symbols have >> the same address and would get redirected again. > > It does work :) Something to note: Julian's planning on removing Valgrind's (currently small) dependence on glibc entirely, in which case you won't be able to use dlopen(). So as Tom said, what you need here are function wrappers rather than function replacements; Jeremy started adding support for them (see the bottom section of coregrind/m_redir.c, under "General function wrapping") but it's currently all commented out and I'm not sure if it was working properly. It's interesting, your tool is a bit different to the existing ones and so is stressing the core/tool interface in new ways. I'm keen to help you with this; if it's helpful I can take a look at the wrapping code, although my hacking time is limited. N |
|
From: Julian S. <js...@ac...> - 2005-08-23 09:32:40
|
On Tuesday 23 August 2005 05:40, Nicholas Nethercote wrote: > On Thu, 18 Aug 2005, Aghiles Kheffache wrote: > > I was wondering about the feasability of a project in Valgrind/Vex: > > tracking FPU operations that have a precision problems (such as adding a > > very small floating point number to a very large one). I am mainly > > interrested in 32 bit operations and I think that the 64 bit "limitation" > > in vex is not really a problem. > > > > Has somebody attempted this already ? > > The idea has been floated briefly before but I'm not aware of anyone who > has attempted it. It would be very interesting to see if this could be > made to work. I agree, it is interesting. It would help if you could describe in more detail what instrumentation you want to generate. One problem is, on x86, there is really no such thing as a 32-bit FP add; all FP math (on the x87) is at the native 80 bit width (kludged to 64 bits by V). And so all the FP expression trees in the IR are built with AddF64, MulF64, etc, and you have no way to know what was originally a C 'float' operation. Your scheme needs to take that into account. J |
|
From: Tom H. <to...@co...> - 2005-08-23 06:22:27
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> I would like to understand why Valgrind is considerably slower when
> built as a PIE.
We don't actually know for sure, and we haven't bothered looking at it
in detail as we plan to get rid of PIE mode completely.
There will be a small slow down because position independent code is
slightly less efficient, but that shoule be very small.
A bigger issue is that memcheck is inefficient at dealing with memory
above the 16Gb mark, but even restricting the client address space
to 16Gb doesn't completely remove the speed penalty.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-08-23 06:16:10
|
Hi, =20 I would like to understand why Valgrind is considerably slower when built as a PIE. =20 Can someone please explain? =20 Thanks, =20 Meir |
|
From: Nicholas N. <nj...@cs...> - 2005-08-23 04:40:50
|
On Thu, 18 Aug 2005, Aghiles Kheffache wrote: > I was wondering about the feasability of a project in Valgrind/Vex: tracking > FPU operations that have a precision problems (such as adding a very small > floating point number to a very large one). I am mainly interrested in 32 bit > operations and I think that the 64 bit "limitation" in vex is not really a > problem. > > Has somebody attempted this already ? The idea has been floated briefly before but I'm not aware of anyone who has attempted it. It would be very interesting to see if this could be made to work. N |
|
From: Julian S. <js...@ac...> - 2005-08-22 21:13:01
|
This message is a call for alpha testers for ppc32-linux Valgrind. As you probably know, Valgrind-3.0.X now supports both x86-linux and amd64-linux. Behind the scenes, there has also been a lot of work folding in Paul Mackerras' PowerPC work, and generally making the Valgrind-3.X line work on ppc32-linux. The 3.X line is beginning to be usable on (32-bit) ppc32-linux. I would like to advance matters rapidly enough that Valgrind-3.1.0, tentatively scheduled for late Oct/early Nov 05, lists ppc32-linux as an officially supported target. The code base is not at the stage where it is suitable for widespread use, but it is at the stage where it would benefit from testing by folks willing to build from SVN, try it out, report problems, and iterate until it works. The results will initially be disappointing. However we know from bringing up amd64-linux that this is a fast and effective way to get a new port up to speed. The current major shortcomings are: - memcheck works OK for small programs, but gives false errors for large (mozilla-sized) programs. Finding a small test case to reproduce these problems is a priority. - cachegrind doesn't work at all. The problems are well understood and fixing it should not be difficult. - Altivec instructions are not supported yet. The framework to do so is in place but has not yet been used. Having said that, I can run OpenOffice 1.1, mozilla, konqueror on Yellow Dog 4.0.1 running on a Mac Mini and also on a ppc970 box. And most of the regression tests now pass. So it's looking promising. J |
|
From: Rob H. <ti...@ge...> - 2005-08-22 12:54:06
|
On Fri, 2005-08-19 at 23:35 +0100, Rob Holland wrote: > Just in case the error wasn't unique to my code, I tried massif. It does > the same thing :/ Another developer has tried massif on his 64bit box and has the same errors. So, guessing it's a 32/64 bit buglet. Any clues? :) --=20 |
|
From: Madhu M K. <mm...@ya...> - 2005-08-20 16:17:14
|
Folks, To reiterate what other users have been saying, valgrind since the early yyyymmdd.tar.bz2 releases has been a tremendous resource for me. When I have come across issues, they have either been fixed soon or since I had access to code, I was able to develop functionality for them (re: automatic generation of suppressions into a file). I am very grateful to all of you for your time and effort. > While we certainly appreciate advanced users who push Valgrind to the > limit, like everyone else we have limited development resources and > so we have to concentrate on making Valgrind work well for the 99% > of the user base who are not "pushing the envelope". Sometimes that > means that bugs get fixed in a different order than one might like. While some of the email on this thread has been pretty inflammatory and one is tempted to talk about expectations from open source, the $$ one pays for using valgrind, the presumption involved in "fundamental" operations and silly ad hominem comments about school, but I digress. I'd like to bring to the discussion this article: http://www.jwz.org/doc/worse-is-better.html "Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface." Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Andy <val...@th...> - 2005-08-20 02:51:57
|
On Fri, 2005-08-19 at 07:10 -0700, John Reiser wrote: > >>Vex is just going to have to learn it, or else quit pretending to > >>support threads. > > > > > > I would refer you to bugs 109313 and 110505 where the lack of this > > instruction was previously reported and SVN revisions 1331 and 1337 > > where it was fixed. > > It is exceedingly reasonable to expect a product with version number 3.0 > to support *fundamental* operations. Valgrind disappoints. Maybe the Valgrind developers would consider using a non-floating point versioning scheme, which wouldn't lead to people implying the maturity of the software. Valgrind 95, Valgrind ME, Valgrind XP. Dates are popular, but developers have a nasty habit of specifying dates to 14 significant digits, being of the "release often" school. Valgrind-20050819214835 is hard to say. Although "Valgrind 2003 Datacenter Edition" has a nice ring to it. -- Andy <val...@th...> |
|
From: Christian P. <tr...@ge...> - 2005-08-19 23:10:46
|
On Friday 19 August 2005 15:47, Dirk Mueller wrote: > On Friday 19 August 2005 14:46, Tom Hughes wrote: > > them both on a 64 bit machine, rename /usr/bin/valgrind from each to > > something else and write a shell script to decide which one to start. > > Yeah, once again we're back to a valgrind shell wrapper ;) > > so the valgrind binary itself should move to libdir as well. I don't see > any other solution right now. *might* be - for now. But I really wish - as it is possible for other=20 tools/libs too - to see multi-ABI support in valgrind. Well, I didn't say to expect it in 3.1, but anyway ;) Regards, Christian Parpart. =2D-=20 01:08:44 up 149 days, 14:16, 5 users, load average: 0.46, 0.26, 0.26 |
|
From: Christian P. <tr...@ge...> - 2005-08-19 22:55:11
|
On Friday 19 August 2005 15:15, John Reiser wrote: > > please tell me *HOW* to disassemble instructions > > (gdb) x/i <address> # see "help data": x/FMT ADDR 'i'=3D=3D>instruction > > If you don't have a running program, or the address, handy, > then create one: > > $ cat foo.S > .byte 0xF0,0xF,0xC7,0xE,0,0,0,0,0,0,0,0 > $ gcc -c foo.S > $ gdb foo.o > (gdb) x/i 0 > 0x0: lock cmpxchg8b (%esi) Yeah, that's what I have been looking for. Thx. (As I don't seem to get the specs somehow) Regards, Christian Parpart. =2D-=20 00:53:40 up 149 days, 14:01, 5 users, load average: 0.48, 0.37, 0.34 |
|
From: Rob H. <ti...@ge...> - 2005-08-19 22:35:26
|
Just in case the error wasn't unique to my code, I tried massif. It does the same thing :/ tigger@xahn % valgrind --tool=3Dmassif =3D=3D26577=3D=3D Massif, a space profiler. =3D=3D26577=3D=3D Copyright (C) 2003, Nicholas Nethercote =3D=3D26577=3D=3D Using LibVEX rev 1338, a library for dynamic binary translation. =3D=3D26577=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D26577=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D26577=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D26577=3D=3D For more details, rerun with: -v =3D=3D26577=3D=3D=20 --26577-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --26577-- si_code=3D1; Faulting address: 0x4B96DE80; sp: 0x7015CDC0 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D26577=3D=3D at 0x70023C78: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D26577=3D=3D at 0x25719796: malloc (vg_replace_malloc.c:149) =3D=3D26577=3D=3D by 0x492AAE: lalloc (misc2.c:843) =3D=3D26577=3D=3D by 0x4929D9: alloc (misc2.c:742) =3D=3D26577=3D=3D by 0x492B69: vim_strsave (misc2.c:940) =3D=3D26577=3D=3D by 0x4B7ACB: set_string_option_global (option.c:4547) =3D=3D26577=3D=3D by 0x4B79FF: set_string_option_direct (option.c:4518) =3D=3D26577=3D=3D by 0x4B4D95: set_option_default (option.c:2870) =3D=3D26577=3D=3D by 0x4B4F42: set_options_default (option.c:2924) =3D=3D26577=3D=3D by 0x4B4A52: set_init_1 (option.c:2678) =3D=3D26577=3D=3D by 0x46D90E: main (main.c:361) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. --=20 |
|
From: Julian S. <js...@ac...> - 2005-08-19 20:13:47
|
I suspect what Tom means is, a process running on 64-bit valgrind can't execve() a 32-bit process, or vice versa. J On Friday 19 August 2005 20:23, Bryan O'Sullivan wrote: > On Fri, 2005-08-19 at 19:41 +0100, Tom Hughes wrote: > > A 64 bit process can't execve() a 32 bit process or vice versa. > > What? > > bos$ uname -i > x86_64 > bos$ file ./ash > ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped bos$ ./ash > $ file $0 > ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped $ file > /bin/ls > /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for > GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped $ /bin/ls > ash > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2005-08-19 20:07:32
|
On Friday 19 August 2005 21:23, Bryan O'Sullivan wrote: > > A 64 bit process can't execve() a 32 bit process or vice versa. > What? [...] I believe he meant when running under valgrind. once started under valgrind, all forked/exec'ed executables are hardcoded to one architecture. Dirk |
|
From: Bryan O'S. <bo...@se...> - 2005-08-19 19:24:12
|
On Fri, 2005-08-19 at 19:41 +0100, Tom Hughes wrote: > A 64 bit process can't execve() a 32 bit process or vice versa. What? bos$ uname -i x86_64 bos$ file ./ash ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped bos$ ./ash $ file $0 ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped $ /bin/ls ash |
|
From: Tom S. <to...@pl...> - 2005-08-19 18:48:59
|
On Fri, 2005-08-19 at 09:25 -0700, John Reiser wrote: > I have tried valgrind several times over the last 4 years, and the > result of each trial has been, "memcheck cannot handle my code." > The outstanding example is memcheck cannot run the internal testcases > of glibc. Complete coverage of i686 user-mode opcodes also matters to me. > Both of these areas have readily-available specifications. The manual > and/or release notes for valgrind should list the failing cases. I have run valgrind on a weekly basis over the last 3 years, and the result of each run has been the finding of memory leaks and bugs in my code. Only occasionaly has valgrind not been able to handle my code. By releasing this "incomplete" tool to me, the valgrind developers have saved me countless days of debugging time. Thank you valgrind developers! -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Tom H. <to...@co...> - 2005-08-19 18:41:26
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 16:19, Tom Hughes wrote:
>
> > It's not a proper solution though, as you can't exec 32 bit
> > from 64 bit and vice versa to start with.
>
> What do you mean by that?
A 64 bit process can't execve() a 32 bit process or vice versa.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-08-19 17:27:43
|
On Friday 19 August 2005 16:19, Tom Hughes wrote: > It's not a proper solution though, as you can't exec 32 bit > from 64 bit and vice versa to start with. What do you mean by that? Dirk |
|
From: Dirk M. <dm...@gm...> - 2005-08-19 17:26:31
|
On Friday 19 August 2005 19:00, Harry Mangalam wrote:
> checking for Qt install path... /usr/lib/qt3
^^^^^^^^^^^^^
> but
> $ ls -l /usr/lib/libqt*
^^^^^^^^^^^^^^^^^^^^
> lrwxrwxrwx 1 root root 17 2005-04-19 12:06 /usr/lib/libqt-mt.so.3 ->
> libqt-mt.so.3.3.4
Do you see the difference?
Dirk
|
|
From: Harry M. <hj...@ta...> - 2005-08-19 17:02:53
|
Some trouble getting valkyrie to compile: $ ./configure --vg-dir=/home/hjm/valgrind/valgrind --qt-lib=/usr/lib/ checking for Qt install path... /usr/lib/qt3 checking for Qt includes ... /usr/include/qt checking thread support... enabled checking for libqt-mt.* in Qt library path... no Error: cannot find Qt thread libraries ( libqt-mt.* ) Rerun configure with --thread=no Rerun configure with --qt-lib=/path/to/qt/libraries. but $ ls -l /usr/lib/libqt* lrwxrwxrwx 1 root root 21 2005-04-20 20:35 /usr/lib/libqthreads.so.12 -> libqthreads.so.12.3.0 -rw-r--r-- 1 root root 3988 2004-12-21 13:17 /usr/lib/libqthreads.so.12.3.0 -rw-r--r-- 1 root root 34004 2005-07-01 17:47 /usr/lib/libqtmcop.a -rw-r--r-- 1 root root 996 2005-07-01 17:47 /usr/lib/libqtmcop.la lrwxrwxrwx 1 root root 18 2005-07-10 19:49 /usr/lib/libqtmcop.so -> libqtmcop.so.1.0.0 lrwxrwxrwx 1 root root 18 2005-07-10 19:49 /usr/lib/libqtmcop.so.1 -> libqtmcop.so.1.0.0 -rw-r--r-- 1 root root 26976 2005-07-01 17:47 /usr/lib/libqtmcop.so.1.0.0 -rw-r--r-- 1 root root 796 2005-04-15 07:18 /usr/lib/libqt-mt.la -rw-r--r-- 1 root root 800 2005-04-15 07:19 /usr/lib/libqt-mt.prl lrwxrwxrwx 1 root root 17 2005-04-19 12:06 /usr/lib/libqt-mt.so -> libqt-mt.so.3.3.4 lrwxrwxrwx 1 root root 17 2005-04-19 12:06 /usr/lib/libqt-mt.so.3 -> libqt-mt.so.3.3.4 lrwxrwxrwx 1 root root 17 2005-04-19 12:06 /usr/lib/libqt-mt.so.3.3 -> libqt-mt.so.3.3.4 -rw-r--r-- 1 root root 7407192 2005-04-15 07:20 /usr/lib/libqt-mt.so.3.3.4 -rw-r--r-- 1 root root 1395 2005-04-03 23:17 /usr/lib/libqtopiakonnector.la -rw-r--r-- 1 root root 253088 2005-04-03 23:53 /usr/lib/libqtopiakonnector.so So what am I missing? (Thinkpad, PIII, Debian unstable) hjm > -----Original Message----- > From: val...@li... > [mailto:val...@li...] On Behalf Of Donna > Robinson > Sent: Friday, July 29, 2005 2:21 AM > To: val...@li... > Subject: [Valgrind-users] Valkyrie-0.9 available > > > We are pleased to release Valkyrie-0.9, an open-source GUI for > the Valgrind 3.X line. Version 0.9 is stable enough to be useful. > Please download and try it, and let us know what you think. > > To check out Valkyrie via anonymous, read-only svn access: > svn co svn://82.138.248.201/valkyrie/trunk valkyrie > To build, follow the instructions in the INSTALL file. > > Valkyrie is known to build and run on the following platforms: > amd64 running SuSE 9.2 > x86 running SuSE 9.1, SuSE 9.3 > ppc32 running Yellow Dog 4.0.1 > > Valkyrie is a Qt-based GUI for Valgrind, and is based on > Valgrind 3.X's XML output capabilities. Valkyrie is designed for > simplicity and ease of use, whilst allowing access to the full > range of Valgrind command-line options. Currently it can only > deal with output from Memcheck, although work is in progress to > handle Cachegrind and Massif too. > -- Cheers, Harry Harry J Mangalam hj...@ta... <<plain text preferred>> |