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
(2) |
2
(9) |
3
(1) |
4
(2) |
5
(6) |
|
6
(1) |
7
(12) |
8
(5) |
9
|
10
(2) |
11
(3) |
12
(2) |
|
13
(11) |
14
(13) |
15
(5) |
16
(10) |
17
(3) |
18
(3) |
19
(1) |
|
20
(4) |
21
(11) |
22
(6) |
23
|
24
(1) |
25
(1) |
26
(3) |
|
27
(1) |
28
(4) |
29
(10) |
30
(1) |
31
(8) |
|
|
|
From: Antti T. <ao...@cc...> - 2006-08-10 16:45:29
|
For some reason, when I run valgrind on a certain (normal) user account I get this feedback from the example program at http://valgrind.org/docs/manual/quick-start.html#quick-start.interpret The program has one modification: i'm trying to write to x[11]. ==19046== Invalid write of size 4 ==19046== at 0x804839F: ??? ==19046== by 0x80483BB: ??? ==19046== by 0x1B938E35: __libc_start_main (in /lib/libc-2.3.2.so) ==19046== by 0x80482E0: ??? ==19046== Address 0x1BA5B054 is 4 bytes after a block of size 40 alloc'd ==19046== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==19046== by 0x8048395: ??? ==19046== by 0x80483BB: ??? ==19046== by 0x1B938E35: __libc_start_main (in /lib/libc-2.3.2.so) ==19046== by 0x80482E0: ??? ==19046== ==19046== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 1) ==19046== malloc/free: in use at exit: 40 bytes in 1 blocks. ==19046== malloc/free: 1 allocs, 0 frees, 40 bytes allocated. ==19046== For counts of detected errors, rerun with: -v ==19046== searching for pointers to 1 not-freed blocks. ==19046== checked 77824 bytes. I only get this error when i'm using this certain account. If I use another account, i get ==4002== Invalid write of size 4 ==4002== at 0x804839F: f (valgtest.c:6) ==4002== by 0x80483BB: main (valgtest.c:11) ==4002== Address 0x1BA5B054 is 4 bytes after a block of size 40 alloc'd ==4002== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==4002== by 0x8048395: f (valgtest.c:5) ==4002== by 0x80483BB: main (valgtest.c:11) from the same binary file, compiled with gcc 3.3.5. Any idea if there is, for example, an enviroment variable or something like that which could cause this? Valgrind version is 2.4.0. -- Antti Tuomi |
|
From: Alexey M. <mel...@gm...> - 2006-08-10 15:37:17
|
Hi! Anobody could please give me a hints how to debug "FASTCGI+Apache+PERL web application" memory leak by valgrind? We have noticed memory leaks in our web application recently; Does valgrind help us in this way? -- Alexey Melezhik |
|
From: Julian S. <js...@ac...> - 2006-08-08 15:42:32
|
> As I'm currently debugging various test cases for our program I ran one
> through valgrind and managed to fire:
>
> --1515:0:aspacem Valgrind: FATAL: aspacem assertion failed:
> --1515:0:aspacem holeEnd <= aspacem_maxAddr
> --1515:0:aspacem at m_aspacemgr/aspacemgr.c:1998
> (vgPlain_am_get_advisory)
> --1515:0:aspacem Exiting now.
Hmm, the chances of figuring out what went wrong without a test
case are essentially zero. Are you doing some weird messing around
with mmap(...,MAP_FIXED,...) ?
> I know the usual advice is fix other problems first. However the only
> other issues are warnings about invalid fd's which is known about.
>
> Curiously if I tweak our programs config I can cause valgrind to barf
> differently. The two may well be related:
>
> --1507-- memcheck GC: 1024 nodes, 1024 survivors (100.0%)
> --1507-- memcheck GC: increase table size to 2048
> VEX temporary storage exhausted.
> Pool = TEMP, start 0x3880aef0 curr 0x38a4e728 end 0x38a54def (size
> 2399999)
>
> vex: the `impossible' happened:
> VEX temporary storage exhausted.
> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
> vex storage: T total 712614672 bytes allocated
This could happen if V has to deal with a block of very long,
lardy, x87 code. The register allocator has run out of memory.
But it could also mean there's a problem with IR optimisation
causing the backend to generate too many insns in the first
place.
What's the chances of seeing the basic block in question?
You can get this by first running with --trace-flags=10001000
and then, when you know the BB number just before it bombed,
adding --trace-notbelow=<number>. This assumes the execution
paths are identical for both runs.
J
|
|
From: Alex B. <ker...@be...> - 2006-08-08 14:59:04
|
Hi,
As I'm currently debugging various test cases for our program I ran one
through valgrind and managed to fire:
--1515:0:aspacem Valgrind: FATAL: aspacem assertion failed:
--1515:0:aspacem holeEnd <= aspacem_maxAddr
--1515:0:aspacem at m_aspacemgr/aspacemgr.c:1998
(vgPlain_am_get_advisory)
--1515:0:aspacem Exiting now.
I know the usual advice is fix other problems first. However the only
other issues are warnings about invalid fd's which is known about.
Curiously if I tweak our programs config I can cause valgrind to barf
differently. The two may well be related:
--1507-- memcheck GC: 1024 nodes, 1024 survivors (100.0%)
--1507-- memcheck GC: increase table size to 2048
VEX temporary storage exhausted.
Pool = TEMP, start 0x3880aef0 curr 0x38a4e728 end 0x38a54def (size
2399999)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 712614672 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==1507== at 0x380188E3: report_and_quit (m_libcassert.c:136)
==1507== by 0x38018BD2: panic (m_libcassert.c:210)
==1507== by 0x38018BF5: vgPlain_core_panic_at (m_libcassert.c:215)
==1507== by 0x38018C13: vgPlain_core_panic (m_libcassert.c:220)
==1507== by 0x3802C807: failure_exit (m_translate.c:487)
==1507== by 0x38075D28: vpanic (vex_util.c:225)
==1507== by 0x380762BC: private_LibVEX_alloc_OOM (vex_util.c:182)
==1507== by 0x3809B5B7: addHInstr (libvex.h:209)
==1507== by 0x3809E712: doRegisterAllocation (reg_alloc2.c:1211)
==1507== by 0x38074E35: LibVEX_Translate (vex_main.c:578)
==1507== by 0x3802CE84: vgPlain_translate (m_translate.c:1097)
==1507== by 0x38039624: handle_tt_miss (scheduler.c:693)
==1507== by 0x38039B56: vgPlain_scheduler (scheduler.c:865)
==1507== by 0x3804D47E: thread_wrapper (syswrap-linux.c:87)
==1507== by 0x3804D575: run_a_thread_NORETURN (syswrap-linux.c:120)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==1507== at 0x629C346: ???
Thread 2: status = VgTs_WaitSys
==1507== at 0x3B73EBC6B2: poll (in /lib64/tls/libc-2.3.4.so)
==1507== by 0x7010B828: MyClass::threadMain() (MyClass.cc:316)
==1507== by 0x3B74B060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==1507== by 0x3B73EC53D2: clone (in /lib64/tls/libc-2.3.4.so)
==1507== by 0x3C: ???
==1507== by 0x38019D96: vgPlain_printf (m_libcprint.c:115)
==1507== by 0x3000000007: ???
==1507== by 0x403A3DE6F: ???
==1507== by 0x403A3DDAF: ???
==1507== by 0x38019BCF: send_bytes_to_logging_sink (m_libcprint.c:55)
--
Alex, homepage: http://www.bennee.com/~alex/
The world's as ugly as sin, And almost as delightful -- Frederick
Locker-Lampson
|
|
From: Tom H. <to...@co...> - 2006-08-08 09:50:16
|
In message <sa7...@ke...>
YAEGASHI Takeshi <t...@ke...> wrote:
> The KDE Bug Report Wizard (http://bugs.kde.org/wizard.cgi) refused my
> bug report about valgrind, so I'm posting here.
There is a special valgrind bug form which is linked to from the
valgrind web site - you can find it at:
http://bugs.kde.org/enter_valgrind_bug.cgi
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: YAEGASHI T. <t...@ke...> - 2006-08-08 09:00:23
|
Hi there, The KDE Bug Report Wizard (http://bugs.kde.org/wizard.cgi) refused my bug report about valgrind, so I'm posting here. pkg-config (valgrind.pc) seems broken in valgrind 3.2.0 and svn trunk. % pkg-config valgrind --libs -L/usr/lib/valgrind/@VG_PLATFORM@ -lcoregrind -lvex -lgcc Sorry if it's already a known problem. Thanks, -- YAEGASHI Takeshi <t...@ke...> <ta...@ya...> <yae...@de...> |
|
From: McKee, H. <hug...@sy...> - 2006-08-08 00:15:59
|
Hi All, I've actually discovered that this issue was answered by Alasdair Ferro's mail of the 28/02/2006. Sorry to have repeated an issue. ********************************************************************** This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete the original message and all copies. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ********************************************************************** |
|
From: Nicholas N. <nj...@cs...> - 2006-08-07 23:17:43
|
On Mon, 7 Aug 2006, David Greene wrote:
> I have a simple question that doesn't seem to be addressed
> anywhere.
>
> When I get a " Conditional jump or move depends on uninitialised
> value(s)" error, how do I know which variable is uninitialized.
> For example, my code could be:
>
> if (a || b || c) { ... }
>
> How do I know whether the uninitialized value is a, b or c?
You have to either temporarily split the condition over multiple lines, or
temporarily use the client request VALGRIND_CHECK_VALUE_IS_DEFINED.
> Printing the address of the uninitialized data for this and
> other such errors would be tremendously useful.
Unfortunately the value is usually in a register when the problem is
detected.
Nick
|
|
From: David G. <gr...@ob...> - 2006-08-07 21:52:28
|
I have a simple question that doesn't seem to be addressed
anywhere.
When I get a " Conditional jump or move depends on uninitialised
value(s)" error, how do I know which variable is uninitialized.
For example, my code could be:
if (a || b || c) { ... }
How do I know whether the uninitialized value is a, b or c?
Printing the address of the uninitialized data for this and
other such errors would be tremendously useful.
-Dave
|
|
From: Bryan M. <om...@br...> - 2006-08-07 19:59:17
|
Patrick, thanks for the input. If the compiled object is available, there should be nothing to stop some "offline" analysis to determine the executable lines within it. It would be better if all of this could automagically be done by a GUI or some other pre/post processing tool rather than as a set of manual steps, but done this way, ALL of the relevant information would be available to perform whatever analysis you wish. The other advantage is that this wouldn't impact the size or speed of the executable under test and you could also cull this information from the "other" ;) OS if you really wanted to do the comparison. Bryan "Brain Murders" Meredith Patrick Ohly wrote: > On Sat, 2006-08-05 at 12:52 +0100, Bryan Meredith wrote: >>> Also, does it give percentage coverage? >> Again, in the GUI, with both the source file and line coverage >> information available, it will be simpler to generate any required >> metrics (another long way of saying No). > > Actually this might be the right approach to handle a problem that no > other coverage tool that I am aware of handles right: if you link the > same object code, say from a static library, into different executables > and then run those multiple times, then merging coverage information > about the original object code can be very hard. Now assuming that the > same source code is compiled differently into different object files > (think Linux and Windows, with and without debugging enabled, etc.) and > then executed the object file based approach completely fails - > basically you have to merge information about the source code in this > case, as you suggest. > > The drawback (and I suppose that was what Nicholas was pointing out) is > then that you don't have information about number of code lines compiled > into the object files or executables, so you have to fall back to less > reliable methods of source code analysis to have a baseline for the > percentage of covered lines of code. > |
|
From: Patrick O. <pat...@in...> - 2006-08-07 14:48:33
|
On Sat, 2006-08-05 at 12:52 +0100, Bryan Meredith wrote: > > Also, does it give percentage coverage? > > Again, in the GUI, with both the source file and line coverage > information available, it will be simpler to generate any required > metrics (another long way of saying No). Actually this might be the right approach to handle a problem that no other coverage tool that I am aware of handles right: if you link the same object code, say from a static library, into different executables and then run those multiple times, then merging coverage information about the original object code can be very hard. Now assuming that the same source code is compiled differently into different object files (think Linux and Windows, with and without debugging enabled, etc.) and then executed the object file based approach completely fails - basically you have to merge information about the source code in this case, as you suggest. The drawback (and I suppose that was what Nicholas was pointing out) is then that you don't have information about number of code lines compiled into the object files or executables, so you have to fall back to less reliable methods of source code analysis to have a baseline for the percentage of covered lines of code. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Tom H. <to...@co...> - 2006-08-07 07:27:07
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sun, 6 Aug 2006, Amadeus W. M. wrote:
>
>> I'm trying to debug a gtkmm program I'm writing, using valgrind.
>> Each time I get the following
>>
>> --17079-- WARNING: unhandled syscall: 311
>> --17079-- You may be able to write your own handler.
>> --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>>
>> I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL.
>> but the system calls in /usr/include/asm/unistd.h end at 309.
>> There's no system call 311.
>>
>> What next? And how come?
>
> New syscalls get added to Linux every so often. Look in Valgrind's source
> code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a
> different platform). If you are on x86/Linux, 311 is "set_robust_list"...
> your next job is to work out what it does :)
I implemented that system call for x86 and amd64 and it should be
supported in the 3.2.0 release.
If Amadeus is still seeing this problem in 3.2.0 then he should
open a ticket for it in the bug tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 04:57:29
|
On Mon, 07 Aug 2006 05:41:04 +0200, Peter "Firefly" Lund wrote: > On Sun, 6 Aug 2006, Amadeus W. M. wrote: > >> [quoted text muted] > > Here's the background: > > http://lwn.net/Articles/172149/ > http://lwn.net/Articles/172134/ > > I think you misunderstand the situation: you are not waiting for the > kernel to catch up, you are waiting for valgrind to catch up. This is a > system call glibc issues even on kernels that don't support it because > that's easier than first checking whether it is actually supported. If it > isn't, it is quite harmless. glibc very often uses this technique (you > can see for yourself by stracing just about any program). In some cases > a new system call is tried first and if that fails, an older and less > capable system call is tried next. This is often faster and easier than > checking kernel version numbers. It also handles backported system call > implementations. > I don't know what I was thinking. As long as valgrind does not have a wrapper for that syscall, it would still issue that warning, even on a kernel that does have that system call. > The thing is, valgrind needs to understand what the program tries to tell > the kernel because, who knows, it could be important. > > You can probably either use an older glibc or if you are lucky tell it to > assume it has an older kernel from before this call was introduced (by > setting the ASSUME_KERNEL environment variable). Or you can write a very > simple syscall wrapper for valgrind that just returns -ENOSYS. There are > probably others of that kind already. > > Good luck :) > Like so, you mean? PRE(sys_set_robust_list) { PRINT("sys_set_robust_list ( %p, %d )", ARG1,ARG2); PRE_REG_READ2(long, "set_robust_list", struct vki_robust_list_head *, head, vki_size_t, len); /* Just check the robust_list_head structure is readable - don't try and chase the list as the kernel will only read it when the thread exits so the current contents is irrelevant. */ if (ARG1 != 0) PRE_MEM_READ("set_robust_list(head)", ARG1, ARG2); } He, he! It's already done in valgrind-3.2.0. Compiled and installed, and now I got rid of the warning. The bad news is I'm still getting the errors that I thought were being triggered by the missing wrapper. The most trivial program in gtkmm produces 2 errors: #include <gtkmm.h> // Compilation: // // g++ -g -Wall -o main `pkg-config gtkmm-2.4 --cflags --libs` main.C int main(int argc, char * argv[]) { Gtk::Main m(argc, argv); return 0; } If valgrind is correct, then the two errors reported must be in gtk/gtkmm or in the X server. |
|
From: McKee, H. <hug...@sy...> - 2006-08-07 03:49:38
|
Hi,
I fully expect that it is something that I have done but when I type make
install I get at the end of it
/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `if [ -n "memcheck-x86-linux
vgpreload_memcheck-x86-linux.so " ] ; then for f in memcheck-x86-linux
vgpreload_memcheck-x86-linux.so ; do p=`echo $f | sed -e 's/^[^-]*-//' -e
's/\..*$//'`; n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`;
/home/dbi/val/valgrind-3.2.0/install-sh -d /usr/local/lib/valgrind/$p;
/usr/bin/install -c $f /usr/local/lib/valgrind/$p/$n; done ; fi ; if [ -n
"" ] ; then for f in ; do if expr match $f libcoregrind_ > /dev/null ;
then pU=`echo $f | sed -e 's/libcoregrind_//g' -e 's/\.a//g'` ; pD=`echo
$pU | sed -e 's/_/-/g'` ; /usr/bin/install -c -m 644 $f
/usr/local/lib/valgrind/$pD/libcoregrind.a ; /usr/bin/install -c -m 644
../VEX/libvex_$pU.a /usr/local/lib/valgrind/$pD/libvex.a ; fi ; done ;
fi'
make[4]: *** [install-exec-local] Error 2
make[4]: Leaving directory `/home/dbi/val/valgrind-3.2.0/memcheck'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/home/dbi/val/valgrind-3.2.0/memcheck'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/dbi/val/valgrind-3.2.0/memcheck'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/dbi/val/valgrind-3.2.0'
make: *** [install] Error 2
And then when I try to run valgrind I get the following.
valgrind ls -l
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such
file or directory
Can anyone tell me what I've actually stuffed up in the install. I did
./configure, make, make install.
**********************************************************************
This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete the original message and all copies. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment.
**********************************************************************
|
|
From: Peter \Firefly\ L. <fi...@di...> - 2006-08-07 03:41:19
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > No idea how to write a valgrind wrapper though, so maybe I'll > just stop short of hacking the kernel and valgrind, and wait > till the kernel >= 2.6.17-7 is available in FC5. Here's the background: http://lwn.net/Articles/172149/ http://lwn.net/Articles/172134/ I think you misunderstand the situation: you are not waiting for the kernel to catch up, you are waiting for valgrind to catch up. This is a system call glibc issues even on kernels that don't support it because that's easier than first checking whether it is actually supported. If it isn't, it is quite harmless. glibc very often uses this technique (you can see for yourself by stracing just about any program). In some cases a new system call is tried first and if that fails, an older and less capable system call is tried next. This is often faster and easier than checking kernel version numbers. It also handles backported system call implementations. The thing is, valgrind needs to understand what the program tries to tell the kernel because, who knows, it could be important. You can probably either use an older glibc or if you are lucky tell it to assume it has an older kernel from before this call was introduced (by setting the ASSUME_KERNEL environment variable). Or you can write a very simple syscall wrapper for valgrind that just returns -ENOSYS. There are probably others of that kind already. Good luck :) -Peter |
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 02:35:26
|
On Mon, 07 Aug 2006 10:59:17 +1000, Nicholas Nethercote wrote:
> On Sun, 6 Aug 2006, Amadeus W. M. wrote:
>
>> Thanks for the quick reply. Sorry, I forgot to mention in my first
>> post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5.
>>
>> I downloaded the valgrind source, and I did see set_robust_list in
>> vki_unista-x86-linux.h. First of all, why does valgrind have a different
>> list of syscalls than the system itself?
>
> Because Valgrind's list is up-to-date with more recent versions of the
> kernel than the one you have.
>
>> Second, exactly how do I know what that system call is supposed to do? I
>> ain't psychic.
>
> Google or the Linux source code.
>
> Nick
Found something in linux-2.6.17.7/kernel/futex.c:
asmlinkage long
sys_set_robust_list(struct robust_list_head __user *head,
size_t len)
{
/*
* The kernel knows only one size for now:
*/
if (unlikely(len != sizeof(*head)))
return -EINVAL;
current->robust_list = head;
return 0;
}
No idea how to write a valgrind wrapper though, so maybe I'll
just stop short of hacking the kernel and valgrind, and wait
till the kernel >= 2.6.17-7 is available in FC5.
Thanks for the help.
|
|
From: Nicholas N. <nj...@cs...> - 2006-08-07 00:59:31
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > Thanks for the quick reply. Sorry, I forgot to mention in my first > post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5. > > I downloaded the valgrind source, and I did see set_robust_list in > vki_unista-x86-linux.h. First of all, why does valgrind have a different > list of syscalls than the system itself? Because Valgrind's list is up-to-date with more recent versions of the kernel than the one you have. > Second, exactly how do I know what that system call is supposed to do? I > ain't psychic. Google or the Linux source code. Nick |
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 00:20:58
|
On Mon, 07 Aug 2006 10:04:53 +1000, Nicholas Nethercote wrote: > On Sun, 6 Aug 2006, Amadeus W. M. wrote: > >> I'm trying to debug a gtkmm program I'm writing, using valgrind. >> Each time I get the following >> >> --17079-- WARNING: unhandled syscall: 311 >> --17079-- You may be able to write your own handler. >> --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. >> >> I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. >> but the system calls in /usr/include/asm/unistd.h end at 309. >> There's no system call 311. >> >> What next? And how come? > > New syscalls get added to Linux every so often. Look in Valgrind's source > code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a > different platform). If you are on x86/Linux, 311 is "set_robust_list"... > your next job is to work out what it does :) > > Nick Thanks for the quick reply. Sorry, I forgot to mention in my first post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5. I downloaded the valgrind source, and I did see set_robust_list in vki_unista-x86-linux.h. First of all, why does valgrind have a different list of syscalls than the system itself? Second, exactly how do I know what that system call is supposed to do? I ain't psychic. |
|
From: Nicholas N. <nj...@cs...> - 2006-08-07 00:05:08
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > I'm trying to debug a gtkmm program I'm writing, using valgrind. > Each time I get the following > > --17079-- WARNING: unhandled syscall: 311 > --17079-- You may be able to write your own handler. > --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > > I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. > but the system calls in /usr/include/asm/unistd.h end at 309. > There's no system call 311. > > What next? And how come? New syscalls get added to Linux every so often. Look in Valgrind's source code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a different platform). If you are on x86/Linux, 311 is "set_robust_list"... your next job is to work out what it does :) Nick |
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-06 23:45:08
|
I'm trying to debug a gtkmm program I'm writing, using valgrind. Each time I get the following --17079-- WARNING: unhandled syscall: 311 --17079-- You may be able to write your own handler. --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. but the system calls in /usr/include/asm/unistd.h end at 309. There's no system call 311. What next? And how come? I do believe I need to correct the warning, by writing a wrapper, because there are a bunch of other errors that I think are triggered by the missing wrapper. Thanks! |
|
From: Nicholas N. <nj...@cs...> - 2006-08-05 15:33:58
|
On Sat, 5 Aug 2006, Gurganus, Brant L wrote: > I don't think there is an actual problem if the overlap in strcpy is > exactly the same block since no way I can think of copying the data from > one to the other would clobber the other That's probably true, but it does seem strange that such copies are taking place, and maybe indicates that something is sub-optimal about the code... Nick |
|
From: Bryan M. <om...@br...> - 2006-08-05 13:02:34
|
Brant,
glad you have found your leaks.
Did you use Omega to find them?
If so, what information did Omega provide that helped you?
Also, are there any changes to the output that could have made it easier
to understand or simpler to use?
If you didn't use Omega, no problem - at least you have found the leaks now.
thanks in advance,
Bryan "Brain Murders" Meredith
Gurganus, Brant L wrote:
> I tried the 3.2.0 version with the omega tool added. The 3.2.0 version
> allowed me to run the program and go through basic tasks without running
> out of memory almost immediately. I have discovered that no xForms
> object is being freed when it is done being used (using fl_free_object),
> and the X connection was not being shut down when the program exited
> (using fl_finish). When I added a call to fl_finish, that took care of
> about a third of the unreleased memory. It looks like I may have to
> modify the design of the software so that it uses lazy initialization
> and initializes when used so I can free it when not being used.
> I also figured out how to work around some errors with strcpy have
> source and destinations that overlap in xForms. Apparently, it will do
> something like:
>
> /* Set defaults. */
> char scbt[64] = "thin"; /* scrollbar type */
>
> /* Make a call to get resources. */
> getResources(scbt, scbt);
>
> /* Gets resources. */
> void getResource(void *dst, void *default)
> {
> if !(getAppResource(dst))
> {
> strcpy(dst, default);
> }
> }
>
> I can work around the problem in xForms by using an application-specific
> resource file which results in the destination and default for the
> resource not being the same.
>
> I don't think there is an actual problem if the overlap in strcpy is
> exactly the same block since no way I can think of copying the data from
> one to the other would clobber the other, but this type of issue was
> happening so frequently that Valgrind would say more than 30000 errors
> detected, I'm not reporting anymore; go fix your program.
>
> Anyhow, the quest continues in improving the robustness of the software
> I'm working on and making it use less memory. Thanks for the pointers to
> try the 3.2.0 version and the omega patch.
>
> Brant Gurganus
> http://www.rose-hulman.edu/~gurganbl
>
>
>
> -----Original Message-----
> From: Bryan Meredith [mailto:om...@br...]
> Sent: Wed 08/02/06 7:02 PM
> To: Gurganus, Brant L
> Cc: val...@li...
> Subject: Re: [Valgrind-users] debugging large memory usage
>
> Brant,
>
> if you are purely interested in memory leaks, please feel free to give
> my Omega tool a spin: http://www.brainmurders.eclipse.co.uk/omega.html
>
> If you use it, please post back to the list with how you got on.
>
> happy hunting,
> Bryan "Brain Murders" Meredith
>
> Gurganus, Brant L wrote:
>> I am trying to debug some unfreed memory in a project I am working on.
>> They system works with several 6.6 megapixel images at a time. If I run
>> the program in valgrind and do minimal things it very quickly runs out
>> of memory leading to invalid (for the current purpose) memory leaks. If
>> I use mtrace, I definitely see large leaks, but I can't since the
>> leaking mallocs are in library code from uses of functions like
>> cvCreateImage, I can't tell where the calls to functions like that don't
>> have a cvReleaseImage. Valgrind will give backtraces that are useful,
>> but because of its extra memory overhead, even when I created a swap
>> file of 4GB (enough to cover the maximum address space of a process),
>> the memory runs out earlier than I can go to the problematic portion of
>> the application and then exit cleanly.
>>
>> Do you have any suggestions in getting useful locations in the code for
>> which I have control without running out of memory before anything
>> useful can be done.
>>
>> Brant Gurganus
>> http://www.rose-hulman.edu/~gurganbl
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Julian S. <js...@ac...> - 2006-08-05 12:46:16
|
The svn head now supports all SSE3 insns except for monitor and mwait, in both 32- and 64-bit mode. Thanks to Matt Domsch for providing an SSE3 capable box to test on, and to Tom Hughes for the gen_insn_test.pl script which makes writing instruction tests very easy. If you use SSE3 instructions, you may want to check out the head and give this a test. Assuming there is no reported breakage I'll get this stuff into the next stable release (3.2.1). <uselessinfo>The JIT generates SSE2 instructions even when SSE3 code is fed in the front end. This means that you can use Valgrind to run SSE3 programs on an SSE2-only capable machine. Really.</uselessinfo> J |
|
From: Bryan M. <om...@br...> - 2006-08-05 11:52:54
|
Nick, thanks as ever for the quick reply. I have inserted some comments below so that the context is intact. Bryan "Brain Murders" Meredith Nicholas Nethercote wrote: > On Fri, 4 Aug 2006, Bryan Meredith wrote: > >> please check my small web page for the details: >> http://www.brainmurders.eclipse.co.uk/covergrind.html >> >>> From the web page: >> ------------------ >> Covergrind is a code coverage tool for the excellent Valgrind framework. >> Rather than having to link against strange libraries or compile in >> various support, Covergrind uses run time instrumentation in order to >> work out which parts of your source code are traversed. There have been >> comments made about how trivial it would be to use the Valgrind >> framework to construct such a tool but I wasn't able to find one so here >> is mine to share. >> ------------------ > > You don't explain how to use it -- what does the output look like? You need to follow the link in order to download it. Details are available there of how to run it. I admit there is no sample output on the web page - I shall add that on the next revision although I had hoped that the omission was an incentive for people to try it out... :D It looks like this: ==4464== Covergrind-beta-01, A code coverage tool.. ==4464== Copyright (C) 2006, and GNU GPL'd, by Bryan Meredith. ==4464== Using LibVEX rev 1631, a library for dynamic binary translation. ==4464== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==4464== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==4464== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==4464== For more details, rerun with: -v ==4464== ==4464== COVERGRIND FILES START 0:/home/bryan/covergrind/coregrind/m_trampoline.S 1:/home/bryan/c++/qt-x11-opensource-src-4.1.4/examples/widgets/analogclock/../../../include/QtCore/../../src/corelib/global/qglobal.h 2:/home/bryan/c++/qt-x11-opensource-src-4.1.4/examples/widgets/analogclock/../../../include/QtCore/../../src/corelib/thread/qatomic.h . . (snipped) . 302:/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S 303:/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S COVERGRIND FILES END COVERGRIND LINES START 0:155-155 0:161-161 1:754-754 1:1538-1538 2:74-75 2:75-75 3:77-77 4:93-94 . . (snipped) . 302:11-14 302:17-18 302:25-26 303:9-10 303:16-17 COVERGRIND LINES END As you can see, each file is given an identifier. These identifiers are then used to show the line coverage information in order to help keep the file size down. I hope you will agree that it is easily parsable by man or machine. The above is the output from running the QT "analogclock" example application (C++). We (at work) are not too interested in how many times a line range has been hit but there is partial support in the Covergrind source for it and I will probably end up implementing it fully. I would envisage adding the hit count to the end of the line range. Actually, I just noticed that it might be a good idea to output the name of the executable under test as well. > If > you run a program multiple times, are the coverage results merged? In the interests of keeping things simple (and hence lightweight and fast) merging of results would be done by the GUI (long way of saying No). > Also, does it give percentage coverage? Again, in the GUI, with both the source file and line coverage information available, it will be simpler to generate any required metrics (another long way of saying No). > Those latter two things are the > tricky part of writing a coverage tool with Valgrind. I appear to have side-stepped both of them. :P Callgrind has a wonderful GUI for post processing and combining run data so this is not setting any precedent. > I wrote one a > while ago ("vcov") which I never fully tested and released properly. I > attach the code in case you find it useful. Thanks. I shall have a look. > > vcov does the merging from multiple runs ok. It also does the > percentage coverage calculation, but it's not perfect -- because you > have to know how many lines of executable code each file has, and that's > only available from the debug info, and I found that some versions of > GCC produced debug info that was unreliable. If I understand this properly, my method differs from this. By outputting source code line number ranges, the source itself can be annotated by the GUI. With suitable parsing of the source to ignore comment only and whitespace only lines, the resulting statistics should be quite accurate for the more common coding styles. Like gcov, one statement per line styles will produce better results. I felt that the best approach was to just output source file line ranges in a fairly dumb fashion and let another tool post process the data. Because the post processing tool (my proposed GUI) would not be in such a constrained environment, there are many more implementation options available, working with the original source file rather than just the debug information being the most important IMO. > > Benoit Peccatte wrote a similar tool ("cover"), I'm not sure how > advanced it is, you can get it here > http://b.peccatte.free.fr/cover-0.03.tgz. Is it still active? I have no problem picking up someone else's work and submitting patches - I am old enough to have gotten over "not written here" syndrome more than two decades ago - but I will only do that if there are signs of active development and I can't say that I have seen anything on the list for a long time. This will be alive for some time yet as I have written it to use at work. It is also simple enough that others can get right in and hack on it if they wish (and I would like to at least hear about it if they do). > > Nick > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Gurganus, B. L <gur...@ro...> - 2006-08-05 11:50:39
|
I tried the 3.2.0 version with the omega tool added. The 3.2.0 version =
allowed me to run the program and go through basic tasks without running =
out of memory almost immediately. I have discovered that no xForms =
object is being freed when it is done being used (using fl_free_object), =
and the X connection was not being shut down when the program exited =
(using fl_finish). When I added a call to fl_finish, that took care of =
about a third of the unreleased memory. It looks like I may have to =
modify the design of the software so that it uses lazy initialization =
and initializes when used so I can free it when not being used.
I also figured out how to work around some errors with strcpy have =
source and destinations that overlap in xForms. Apparently, it will do =
something like:
/* Set defaults. */
char scbt[64] =3D "thin"; /* scrollbar type */
/* Make a call to get resources. */
getResources(scbt, scbt);
/* Gets resources. */
void getResource(void *dst, void *default)
{
if !(getAppResource(dst))
{
strcpy(dst, default);
}
}
I can work around the problem in xForms by using an application-specific =
resource file which results in the destination and default for the =
resource not being the same.
I don't think there is an actual problem if the overlap in strcpy is =
exactly the same block since no way I can think of copying the data from =
one to the other would clobber the other, but this type of issue was =
happening so frequently that Valgrind would say more than 30000 errors =
detected, I'm not reporting anymore; go fix your program.
Anyhow, the quest continues in improving the robustness of the software =
I'm working on and making it use less memory. Thanks for the pointers to =
try the 3.2.0 version and the omega patch.
Brant Gurganus
http://www.rose-hulman.edu/~gurganbl
-----Original Message-----
From: Bryan Meredith [mailto:om...@br...]
Sent: Wed 08/02/06 7:02 PM
To: Gurganus, Brant L
Cc: val...@li...
Subject: Re: [Valgrind-users] debugging large memory usage
=20
Brant,
if you are purely interested in memory leaks, please feel free to give
my Omega tool a spin: http://www.brainmurders.eclipse.co.uk/omega.html
If you use it, please post back to the list with how you got on.
happy hunting,
Bryan "Brain Murders" Meredith
Gurganus, Brant L wrote:
> I am trying to debug some unfreed memory in a project I am working on.
> They system works with several 6.6 megapixel images at a time. If I =
run
> the program in valgrind and do minimal things it very quickly runs out
> of memory leading to invalid (for the current purpose) memory leaks. =
If
> I use mtrace, I definitely see large leaks, but I can't since the
> leaking mallocs are in library code from uses of functions like
> cvCreateImage, I can't tell where the calls to functions like that =
don't
> have a cvReleaseImage. Valgrind will give backtraces that are useful,
> but because of its extra memory overhead, even when I created a swap
> file of 4GB (enough to cover the maximum address space of a process),
> the memory runs out earlier than I can go to the problematic portion =
of
> the application and then exit cleanly.
>=20
> Do you have any suggestions in getting useful locations in the code =
for
> which I have control without running out of memory before anything
> useful can be done.
>=20
> Brant Gurganus
> http://www.rose-hulman.edu/~gurganbl
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> =
-------------------------------------------------------------------------=
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
> opinions on IT & business topics through brief surveys -- and earn =
cash
> =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|