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
(4) |
3
|
4
(18) |
5
(20) |
6
(2) |
7
|
|
8
|
9
|
10
(6) |
11
|
12
(12) |
13
(3) |
14
(1) |
|
15
(2) |
16
(3) |
17
|
18
(9) |
19
(10) |
20
(18) |
21
(1) |
|
22
(10) |
23
(3) |
24
(25) |
25
(13) |
26
(2) |
27
(5) |
28
|
|
29
(1) |
30
(1) |
31
(6) |
|
|
|
|
|
From: Jim C. <jim...@gm...> - 2006-10-12 18:54:45
|
Over on lm-sensors, Im advocating the use of 2D-callbacks (sysfs), which allows the consolidation of multiple (1D) callbacks, thus reducing text-size. Ive been asked to 'prove' its a win. Setting aside the idea that this is not a high-traffic interface (voltages & temps for system health monitoring), how can I go about it ? Im aware that valgrind has been used on a UML kernel, but the valgrind ML threads arent particularly helpful (Ive never used UML in any way, so its hard to tell). Running a Xen-guest also occurred to me, but 'Xen' has zero hits on gmane.comp.debugging.valgrind. Are UML or Xen my best bet for getting some cachegrind data on a kernel driver ? or is there another way I havent thought of ? Oprofile has occurred to me, but Im a newbie there too. While it might show some total time spent in the callbacks, it seems (apriori) unlikely to just tell me the cache usage of a handful of routines (it does have filtering, but I think thats by application, a couple functions in a kernel driver is a very different problem). any hints welcome tia |
|
From: Josef W. <Jos...@gm...> - 2006-10-12 13:55:31
|
On Thursday 12 October 2006 14:58, Nicholas Nethercote wrote: > On Thu, 12 Oct 2006, Josef Weidendorfer wrote: > > > I also added some old addittions from cg-x86.c to cg-amd64.c. > > Do we need separate x86 and AMD64 files? Those two files are almost > identical... Hmm.. In general, the way how to automatically detect cache sizes is architecture dependent. However, in this case, the results from CPUID seem to have the same interpretation at least for Intel chips. IMHO, we should move common parts into a cg-x86-amd64-common.c, and include this both from cg-x86.c and cg-amd64.c. Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-10-12 12:58:52
|
On Thu, 12 Oct 2006, Josef Weidendorfer wrote: > I also added some old addittions from cg-x86.c to cg-amd64.c. Do we need separate x86 and AMD64 files? Those two files are almost identical... Nick |
|
From: Julian S. <js...@ac...> - 2006-10-12 12:01:48
|
> Patch attached. Comment would be something like: Cool. Can you commit it and also add an entry to 3_2_BUGSTATUS.txt? J |
|
From: Josef W. <Jos...@gm...> - 2006-10-12 10:16:27
|
On Thursday 12 October 2006 11:02, Nicholas Nethercote wrote: > Can you create a patch to fix this? Patch attached. Comment would be something like: "Cachegrind: Update cache parameter detection according to revision 21 of Intels Software Developer Manual" I also added some old addittions from cg-x86.c to cg-amd64.c. > (Is the CPUID code identical in > Callgrind compared to Cachegrind?) That would be really helpful! Yes. See callgrind/Makefile.am: ... CALLGRIND_SOURCES_X86 = ../cachegrind/cg-x86.c CALLGRIND_SOURCES_AMD64 = ../cachegrind/cg-amd64.c ... Probably should be backported. > > Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-10-12 09:03:12
|
On Thu, 12 Oct 2006, Josef Weidendorfer wrote: > According to table 3.17 of the "Intel 64 and IA-32 Architectures > Software Developer=FF=FFs Manual, Volume 2A, Revision 21": > (see http://www.intel.com/design/pentium4/manuals/index_new.htm) > >> ...... >> --11725-- warning: Unknown Intel cache config value (0xB1), ignoring > > Not specified (?). > However, B0 talks about instruction TLB, which is uninteresting for > Cachegrind. > >> --11725-- warning: Unknown Intel cache config value (0x5), ignoring > > Data TLB1: 4 MByte pages, 4-way set associative, 32 entries > Uninteresting for Cachegrind. > >> --11725-- warning: Unknown Intel cache config value (0xF0), ignoring > > 64-Byte prefetching. > Hmm... No idea about that. > >> --11725-- warning: Unknown Intel cache config value (0x57), ignoring > > Data TLB0: 4 KByte pages, 4-way associative, 16 entries > Uninteresting for Cachegrind. > >> --11725-- warning: Unknown Intel cache config value (0x56), ignoring > > Data TLB0: 4 MByte pages, 4-way set associative, 16 entries > Uninteresting for Cachegrind. > >> --11725-- warning: Unknown Intel cache config value (0x49), ignoring > > 2nd-level cache: 4 MByte, 16-way set associative, 64 byte line size > Important for Cachegrind: L2 cache size of 4 MB. > >> --11725-- warning: Unknown Intel cache config value (0xB4), ignoring > > Data TLB1: 4 KByte pages, 4-way associative, 256 entries > Uninteresting for Cachegrind. > >> --11725-- warning: L2 cache not installed, ignore L2 results. > > Wow. I did not known that Cachegrind produces such warnings. > However, in this case we have a L2 cache with 4MB (see above). Can you create a patch to fix this? (Is the CPUID code identical in=20 Callgrind compared to Cachegrind?) That would be really helpful! Nick |
|
From: Josef W. <Jos...@gm...> - 2006-10-12 08:35:58
|
On Thursday 12 October 2006 06:20, Zhiyao Tu wrote: > Hi Julian, >=20 > Thanks for your information. >=20 > I searched and found the CPU is this one: >=20 > Dual Core Intel(r) Xeon(r) processor 5130 > Dual Core Intel(r) Xeon(r) processor 5100 Series (2.00GHz, 4MB L2 > Cache, 1333MHz FSB, 65W, LGA771) That is a Core 2 Duo (Woodcrest). As I have such a machine around to test, I think I can come up with a patch. Actually, I get exactly the same warnings. According to table 3.17 of the "Intel 64 and IA-32 Architectures Software Developer=E2=80=99s Manual, Volume 2A, Revision 21": (see http://www.intel.com/design/pentium4/manuals/index_new.htm) > ...... > --11725-- warning: Unknown Intel cache config value (0xB1), ignoring Not specified (?). However, B0 talks about instruction TLB, which is uninteresting for Cachegrind. > --11725-- warning: Unknown Intel cache config value (0x5), ignoring Data TLB1: 4 MByte pages, 4-way set associative, 32 entries Uninteresting for Cachegrind. > --11725-- warning: Unknown Intel cache config value (0xF0), ignoring 64-Byte prefetching. Hmm... No idea about that. > --11725-- warning: Unknown Intel cache config value (0x57), ignoring Data TLB0: 4 KByte pages, 4-way associative, 16 entries Uninteresting for Cachegrind. > --11725-- warning: Unknown Intel cache config value (0x56), ignoring Data TLB0: 4 MByte pages, 4-way set associative, 16 entries Uninteresting for Cachegrind. > --11725-- warning: Unknown Intel cache config value (0x49), ignoring 2nd-level cache: 4 MByte, 16-way set associative, 64 byte line size Important for Cachegrind: L2 cache size of 4 MB. > --11725-- warning: Unknown Intel cache config value (0xB4), ignoring Data TLB1: 4 KByte pages, 4-way associative, 256 entries Uninteresting for Cachegrind. > --11725-- warning: L2 cache not installed, ignore L2 results. Wow. I did not known that Cachegrind produces such warnings. However, in this case we have a L2 cache with 4MB (see above). Josef |
|
From: Zhiyao T. <mc...@gm...> - 2006-10-12 04:20:14
|
Hi Julian, Thanks for your information. I searched and found the CPU is this one: Dual Core Intel(r) Xeon(r) processor 5130 Dual Core Intel(r) Xeon(r) processor 5100 Series (2.00GHz, 4MB L2 Cache, 1333MHz FSB, 65W, LGA771) 2006/10/12, Julian Seward <js...@ac...>: > > > directly in command line? If so, what values to use? According to the > > content of /proc/cpuinfo, my box has 4 CPUs, every one is like this: > > Assuming this is a Pentium 4 based Xeon, and not a Core 2 one, you > should specify I1 of 16k, D1 of 16k and L2 of 4096k. > > It would be helpful to know what CPU this really is. > > J > |
|
From: Julian S. <js...@ac...> - 2006-10-12 02:52:40
|
> directly in command line? If so, what values to use? According to the > content of /proc/cpuinfo, my box has 4 CPUs, every one is like this: Assuming this is a Pentium 4 based Xeon, and not a Core 2 one, you should specify I1 of 16k, D1 of 16k and L2 of 4096k. It would be helpful to know what CPU this really is. J |
|
From: Nicholas N. <nj...@cs...> - 2006-10-12 02:27:43
|
On Thu, 12 Oct 2006, Zhiyao Tu wrote: > Hi, > > I planed to use cachegrind tool to profile the instruction and data > cache usage in my program. When I startup it with default options > "valgrind --tool=cachegrind MyProgram", it shows following information > at the beginning: > > ...... > --11725-- warning: Unknown Intel cache config value (0xB1), ignoring > --11725-- warning: Unknown Intel cache config value (0x5), ignoring > --11725-- warning: Unknown Intel cache config value (0xF0), ignoring > --11725-- warning: Unknown Intel cache config value (0x57), ignoring > --11725-- warning: Unknown Intel cache config value (0x56), ignoring > --11725-- warning: Unknown Intel cache config value (0x49), ignoring > --11725-- warning: Unknown Intel cache config value (0xB4), ignoring > --11725-- warning: L2 cache not installed, ignore L2 results. > ...... > > The valgrind I used is valgrind-3.2.0-Debian. Seems that it can't > recognize the CPU cache config. Shall I specified the I1/D1/L2 options > directly in command line? Yes! > If so, what values to use? According to the > content of /proc/cpuinfo, my box has 4 CPUs, every one is like this: > > cache size : 4096 KB I think that's the L2 size. As for the I1/D1, I don't know, you could try googling for it. Ultimately due to various approximations Cachegrind's results are not exact -- you're unlikely to get them closely matching results from hardware counters, for example. Instead, think of Cachegrind's results as giving you an idea of your program's cache behaviour in general, in which case it doesn't matter if the cache configuration doesn't match reality exactly. Nick |
|
From: Zhiyao T. <mc...@gm...> - 2006-10-12 02:09:21
|
Hi, I planed to use cachegrind tool to profile the instruction and data cache usage in my program. When I startup it with default options "valgrind --tool=cachegrind MyProgram", it shows following information at the beginning: ...... --11725-- warning: Unknown Intel cache config value (0xB1), ignoring --11725-- warning: Unknown Intel cache config value (0x5), ignoring --11725-- warning: Unknown Intel cache config value (0xF0), ignoring --11725-- warning: Unknown Intel cache config value (0x57), ignoring --11725-- warning: Unknown Intel cache config value (0x56), ignoring --11725-- warning: Unknown Intel cache config value (0x49), ignoring --11725-- warning: Unknown Intel cache config value (0xB4), ignoring --11725-- warning: L2 cache not installed, ignore L2 results. ...... The valgrind I used is valgrind-3.2.0-Debian. Seems that it can't recognize the CPU cache config. Shall I specified the I1/D1/L2 options directly in command line? If so, what values to use? According to the content of /proc/cpuinfo, my box has 4 CPUs, every one is like this: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz stepping : 6 cpu MHz : 1994.999 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : 3993.78 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Thanks a lot |
|
From: Tom H. <to...@co...> - 2006-10-10 11:55:07
|
In message <520C5E108EFD11468EB43142EFEAD1BD4BF72A@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
>
> One other thing I found out is
> The exec of interest is loading a different set of vgp*.so
> --2983-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
> 20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
> --2983-- Reading syms from /usr/sbin/dpserver (0x400000)
> --2983-- Reading syms from /lib64/ld-2.3.6.so (0x11900000)
> --2983-- Reading suppressions file: /usr/lib64/valgrind/default.supp
> ==2983==
> --2983-- Reading syms from /usr/lib64/valgrind/vg_preload_core.so
> (0x11A1C000)
> --2983-- object doesn't have a symbol table
> --2983-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck.so
> (0x11B1E000)
> --2983-- object doesn't have a symbol table
>
> And I wrote a small test prog using setpriority() which is loading a
> different vgp*.so files
> --10565-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
> 20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
> --10565-- Arch and hwcaps: AMD64, amd64-sse2
> --10565-- Valgrind library directory: /usr/local/lib/valgrind
> --10565-- Reading syms from /home/sdc/rakesh/a.out (0x400000)
> --10565-- Reading syms from /usr/local/lib/valgrind/amd64-linux/memcheck
> (0x38000000)
> --10565-- object doesn't have a dynamic symbol table
> --10565-- Reading syms from /lib64/ld-2.3.6.so (0x3C1EB00000)
> --10565-- Reading suppressions file:
> /usr/local/lib/valgrind/default.supp
> --10565-- Reading syms from
> /usr/local/lib/valgrind/amd64-linux/vgpreload_core.so (0x4802000)
> --10565-- Reading syms from
> /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4903000)
>
> Would that give some clue, on this issue.
Yes - you have two copies of valgrind installed, one in /usr and one
in /usr/local and you have picked up different versions on different
runs, presumably due to a different path.
The one in /usr/local is newer that the one in /usr.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-10-10 11:40:38
|
In message <520C5E108EFD11468EB43142EFEAD1BD4E4334@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> I am running
> $ valgrind --version
> valgrind-3.2.1
>
> $ nm -a memcheck | grep setprio
> 000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
If you are getting that message then that is not the version you are
running - double check your path and make sure that you are running
the version that you think you are running.
Running with -d should also show you the path of the tool binary that
it is using.
There is no way that 3.2.1 should report the system call as unhandled
on amd64-linux as it is definitely hooked up to a handler.
> What happens if the syscall is not implemented say for setpriority
> The caller (in my case the exec I am testing) would get a return value
> as success or failure..
It would get an ENOSYS error.
> I am wondering if that is the cause for failure later with SIGSEGV.
I would think it unlikely, but as you haven't provided any details of
the SEGV it is hard to comment.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Shevde, R. S \(GE Healthcare\) <Rak...@ge...> - 2006-10-10 11:34:56
|
=20
One other thing I found out is=20
The exec of interest is loading a different set of vgp*.so
--2983-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
--2983-- Reading syms from /usr/sbin/dpserver (0x400000)
--2983-- Reading syms from /lib64/ld-2.3.6.so (0x11900000)
--2983-- Reading suppressions file: /usr/lib64/valgrind/default.supp
=3D=3D2983=3D=3D
--2983-- Reading syms from /usr/lib64/valgrind/vg_preload_core.so
(0x11A1C000)
--2983-- object doesn't have a symbol table
--2983-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck.so
(0x11B1E000)
--2983-- object doesn't have a symbol table
And I wrote a small test prog using setpriority() which is loading a
different vgp*.so files=20
--10565-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
--10565-- Arch and hwcaps: AMD64, amd64-sse2
--10565-- Valgrind library directory: /usr/local/lib/valgrind
--10565-- Reading syms from /home/sdc/rakesh/a.out (0x400000)
--10565-- Reading syms from /usr/local/lib/valgrind/amd64-linux/memcheck
(0x38000000)
--10565-- object doesn't have a dynamic symbol table
--10565-- Reading syms from /lib64/ld-2.3.6.so (0x3C1EB00000)
--10565-- Reading suppressions file:
/usr/local/lib/valgrind/default.supp
--10565-- Reading syms from
/usr/local/lib/valgrind/amd64-linux/vgpreload_core.so (0x4802000)
--10565-- Reading syms from
/usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4903000)
Would that give some clue, on this issue.
-----Original Message-----
From: Shevde, Rakesh S (GE Healthcare)=20
Sent: Tuesday, October 10, 2006 4:51 PM
To: 'Tom Hughes'; val...@li...
Subject: RE: [Valgrind-users] Problem with REDIR
I am running
$ valgrind --version
valgrind-3.2.1=20
$ nm -a memcheck | grep setprio
000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
What happens if the syscall is not implemented say for setpriority The
caller (in my case the exec I am testing) would get a return value as
success or failure..
I am wondering if that is the cause for failure later with SIGSEGV.
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, October 10, 2006 4:42 PM
To: val...@li...
Subject: Re: [Valgrind-users] Problem with REDIR
In message
<520C5E108EFD11468EB43142EFEAD1BD4E4333@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> It then complains about
> --2983-- WARNING: unhandled syscall: 141
> =3D=3D2983=3D=3D at 0x124B8657: setpriority (in =
/lib64/libc-2.3.6.so)
You haven't said what version of valgrind you are using, but this system
call is implemented in 3.2.1 so it obviously isn't the latest.
> setpriority is present in the coregrind syscall implementations.
Correct, and is hooked up on amd64-linux, so if you are getting that
error you are not running the current code.
> Please let me know on why do we get these REDIR (???) messages.
Those are normal, don't worry about them.
tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
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=
DEVDE
V
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Shevde, R. S \(GE Healthcare\) <Rak...@ge...> - 2006-10-10 11:21:31
|
I am running=20
$ valgrind --version
valgrind-3.2.1=20
$ nm -a memcheck | grep setprio
000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
What happens if the syscall is not implemented say for setpriority
The caller (in my case the exec I am testing) would get a return value
as success or failure..
I am wondering if that is the cause for failure later with SIGSEGV.
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, October 10, 2006 4:42 PM
To: val...@li...
Subject: Re: [Valgrind-users] Problem with REDIR
In message
<520C5E108EFD11468EB43142EFEAD1BD4E4333@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> It then complains about
> --2983-- WARNING: unhandled syscall: 141
> =3D=3D2983=3D=3D at 0x124B8657: setpriority (in =
/lib64/libc-2.3.6.so)
You haven't said what version of valgrind you are using, but this system
call is implemented in 3.2.1 so it obviously isn't the latest.
> setpriority is present in the coregrind syscall implementations.
Correct, and is hooked up on amd64-linux, so if you are getting that
error you are not running the current code.
> Please let me know on why do we get these REDIR (???) messages.
Those are normal, don't worry about them.
tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
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=
DEVDE
V
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2006-10-10 11:13:06
|
In message <520C5E108EFD11468EB43142EFEAD1BD4E4333@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> It then complains about
> --2983-- WARNING: unhandled syscall: 141
> ==2983== at 0x124B8657: setpriority (in /lib64/libc-2.3.6.so)
You haven't said what version of valgrind you are using, but this
system call is implemented in 3.2.1 so it obviously isn't the latest.
> setpriority is present in the coregrind syscall implementations.
Correct, and is hooked up on amd64-linux, so if you are getting that
error you are not running the current code.
> Please let me know on why do we get these REDIR (???) messages.
Those are normal, don't worry about them.
tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Shevde, R. S \(GE Healthcare\) <Rak...@ge...> - 2006-10-10 10:50:57
|
Hi=20 I am trying to use Valgrind for my executable.. The following is the snippet of the error it gives=20 =20 --2983-- Reading syms from /lib64/libc-2.3.6.so (0x123F6000) --2983-- REDIR: 0x12469B60 (memset) redirected to 0x11B21D10 (memset) --2983-- REDIR: 0x1246A270 (memcpy) redirected to 0x11B21DF0 (memcpy) --2983-- REDIR: 0x12468B90 (rindex) redirected to 0x11B21840 (rindex) --2983-- REDIR: 0x12468740 (strlen) redirected to 0x11B219F0 (strlen) --2983-- REDIR: 0x1201E460 (operator new(unsigned long)) redirected to 0x11B201E8 (operator new(unsigned long)) --2983-- REDIR: 0x12463210 (malloc) redirected to 0x11B1FE1D (malloc) --2983-- REDIR: 0x124692D0 (memchr) redirected to 0x11B21B70 (memchr) --2983-- REDIR: 0x12468000 (index) redirected to 0x11B21930 (index) --2983-- REDIR: 0x1246AB20 (rawmemchr) redirected to 0x11B21DD0 (rawmemchr) --2983-- REDIR: 0x12461320 (free) redirected to 0x11B209B5 (free) --2983-- REDIR: 0x12469F80 (stpcpy) redirected to 0x11B220F0 (stpcpy) --2983-- REDIR: 0x1201E560 (operator new[](unsigned long)) redirected to 0x11B20656 (operator new[](unsigned long)) --2983-- REDIR: 0x12462E90 (calloc) redirected to 0x11B21180 (calloc) --2983-- REDIR: 0x124689C0 (strncmp) redirected to 0x11B21A50 (strncmp) --2983-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x7002973B (???) --2983-- REDIR: 0x12468AD0 (strncpy) redirected to 0x11B22370 (strncpy) --2983-- REDIR: 0x124681F0 (strcpy) redirected to 0x11B22030 (strcpy) --2983-- REDIR: 0x124681B0 (strcmp) redirected to 0x11B21AD0 (strcmp) =3D=3D2983=3D=3D Syscall param pipe(filedes) points to unaddressable = byte(s) =3D=3D2983=3D=3D at 0x124B2DE7: pipe (in /lib64/libc-2.3.6.so) =3D=3D2983=3D=3D by 0x43D0B1: MPIDU_Sock_create_set (sock_set.i:70) =3D=3D2983=3D=3D by 0x428B00: MPIDI_CH3I_Progress_init = (ch3_progress.c:285) =3D=3D2983=3D=3D by 0x4284D4: MPIDI_CH3_Init (ch3_init.c:34) =3D=3D2983=3D=3D by 0x411806: MPID_Init (mpid_init.c:79) =3D=3D2983=3D=3D by 0x40FFA0: MPIR_Init_thread (initthread.c:220) =3D=3D2983=3D=3D by 0x4100EF: MPI_Init_thread (initthread.c:342) =3D=3D2983=3D=3D by 0x40BBD3: main (main.cpp:58) =3D=3D2983=3D=3D Address 0x1264AB28 is 0 bytes after a block of size = 80 alloc'd =3D=3D2983=3D=3D at 0x11B1FE96: malloc (in /usr/lib64/valgrind/vgpreload_memcheck.so) =3D=3D2983=3D=3D by 0x43D022: MPIDU_Sock_create_set (sock_set.i:25) =3D=3D2983=3D=3D by 0x428B00: MPIDI_CH3I_Progress_init = (ch3_progress.c:285) =3D=3D2983=3D=3D by 0x4284D4: MPIDI_CH3_Init (ch3_init.c:34) =3D=3D2983=3D=3D by 0x411806: MPID_Init (mpid_init.c:79) =3D=3D2983=3D=3D by 0x40FFA0: MPIR_Init_thread (initthread.c:220) =3D=3D2983=3D=3D by 0x4100EF: MPI_Init_thread (initthread.c:342) =3D=3D2983=3D=3D by 0x40BBD3: main (main.cpp:58) --2983-- REDIR: 0x1246ABF0 (strchrnul) redirected to 0x11B21DA0 (strchrnul) It then complains about=20 --2983-- WARNING: unhandled syscall: 141 =3D=3D2983=3D=3D at 0x124B8657: setpriority (in = /lib64/libc-2.3.6.so) =20 and finally it gives SIGSEGV and exits.. =20 setpriority is present in the coregrind syscall implementations. =20 The same executable runs fine without Valgrind.. =20 Please let me know on why do we get these REDIR (???) messages. =20 =20 Thanks and Regards, Rakesh |
|
From: Josef W. <Jos...@gm...> - 2006-10-06 11:59:30
|
On Thursday 05 October 2006 23:19, Nicholas Nethercote wrote: > On Thu, 5 Oct 2006, Mohit Tiwari wrote: > > > I notice that running the floating point benchmarks (like ammp) takes a > > substantial time. (ammp took ~15min natively and 1.5 hrs using nulgrind) > > With Memcheck's ~50X overhead, it might take this 12.5 hrs to finish. Is > > there a way I can switch between native and valgrind executions of a > > program, so I could use a phase analyzing software like Simpoint to simulate > > only certain instructions. > > Depends which tool you're using -- I think Callgrind might have some support > for this. In Callgrind, you temporarily can switch off full instrumentation to get the speed of nulgrind. Of course, cache simulator is off then, too, and the cache state will be flushed on such switches. The instrumentation mode at startup can be specified with "--instr-atstart=yes/no", interactivly changed with "callgrind_control -i on/off", and per client request in the code with CALLGRIND_START/STOP_INSTRUMENTATION. It probably would be nice to switch it on/off when entering a given function, but this checking would need instrumentation itself. Josef |
|
From: Janne H. <jjh...@gm...> - 2006-10-06 09:01:40
|
> I'd like to be able to control my tool from inside my instrumented > application. I thought that a pretty easy interface for this would be > to register my own software interrupt handler. This way I could > control my tool with a couple of syscalls. Is there an easier way to > do this? I'd rather not make the instrumented app depend on valgrind > header files to make it easier to build. Looks like I came into this conclusion a bit hastily. Reading through the documentation & code has convinced me that using the valgrind client request mechanism is a better way to control my tool. Janne |
|
From: Bryan M. <bra...@go...> - 2006-10-05 23:17:23
|
Bob Rossi wrote: > On Thu, Oct 05, 2006 at 08:12:57PM +0100, Bryan Meredith wrote: >> Bob Rossi wrote: >>> On Thu, Oct 05, 2006 at 07:01:31PM +0100, Bryan Meredith wrote: >>>> Bob Rossi wrote: >>>>> On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: >>>>>> Fellow Valgrinders, >>>>>> >>>>>> please see http://www.brainmurders.eclipse.co.uk/omega.html for a >>>>>> complete overview of what this tool can do for you! >>>>>> >>>>>> (We use this heavily at work - feel free to give it a spin...) >>>>>> >>>>>> As ever, I would welcome your comments, bug reports and especially any >>>>>> news of success stories. Please share them with us on the list and copy >>>>>> me in so I don't miss them. >>>>> Hi, >>>>> >>>>> I just installed valgrind with omega support. valgrind was reporting a >>>>> memory leak with the memcheck tool, and I spent a good 2 hours trying to >>>>> figure out if it was a leak or not, cause I couldn't find WHERE it >>>>> leaked. >>>>> >>>>> After running with the omega tool, I'm now confronted with 122 >>>>> memory leaks, where as the memcheck was saying I only had 2. >>>> The results shouldn't be that different apart from the indirect leaks >>>> will also be reported each time. If this isn't because of indirect leak >>>> reporting, I have more work to do. Try running with "--instant-reports >>>> --show-indirect" as this will make the indirect leaks stand out a bit >>>> better. You might want to stick the output in a log file though :D >>> Would it be possible to not print the indirect leaks via an option? >> You can try --instant-reports on its own (it wont show the indirect >> blocks without --show-indirect) and just use the on the fly leak reports >> to clue you in. This is set to only report on the first leak for a given >> allocation / leak location pair. I will look at splitting this out in >> the summary reports as well. > > If I run like this: > > >>>>> It looks like omega is not honoring the suppressions when reporting >>>>> on memory leaks, is this true? >>>> That is correct - I don't have suppression support in Omega. >>> Any plans on adding this? Basically, there are some memory leaks in our >>> tool that are not going away any time soon. It is sort of a pain for >>> me to see them in the reports, cause it takes more time to sort through >>> what is fixable now, and what is not fixable. Also, when our nigtly >>> testsuite runs, when the suprressions are used, memcheck reports there >>> are no memory leaks, which is really helpful. We can say if things >>> passed or failed off of this. > > If I run it like this: > > LD_LIBRARY_PATH=$VECTORCAST_DIR/lib:$LD_LIBRARY_PATH > PATH=/home/TOOLS/valgrind-omega-svn-10-05-2006/bin:$PATH valgrind > --tool=omega --num-callers=20 --suppressions=clicast.supp > --instant-reports foo.exe > out-omega-instant.txt 2>&1 > > I still get massive amounts of memory leaks in comparison to memcheck. > Is this what you would expect? > The --suppressions option won't do anything to suppress memory leak reports in Omega. If you are expecting leaks to be suppressed, don't because they wont be. Without having your program to play with, it's difficult to say. I am certainly nervous that you might be getting false positives although for a complete run, they are normally identified and discarded. I think a cautious first step would be to find the leak reports that match the malloc() shown by memcheck and see if they help you. Try to ignore the rest for now. Once those are fixed (or you decide to ignore them) pick one of the others and see if it is actually a real leak. If I had your source, I would do this step but obviously, its your source, you are familiar with it and it should take you a lot less time to determine if it is a leak (not to mention, I don't really want to be signing NDAs etc). If you find any false reports and can reproduce them, please let me know in as much detail as you can so I can hopefully replicate it here and fix it. >> for some funky suppression types) but I have been focusing on getting >> Omega to give the correct results first. >> >>>>> Can omega total the memory leaks that it found and report a number the >>>>> way memcheck does? That number usually provides a "wow factor" to people >>>>> explaining to there boss that they just stopped the coffee brewing >>>>> network application from leaking 100 megs of memory each time a pot of >>>>> coffee is brewed ... >>>> Happy to include this for you - it will be in RC2. >>> Thanks! >>> >> Out of interest, has Omega helped you to fix any of the leaks reported >> by Memcheck? > > To be honest, I've just started using it today, and I'm trying to > resolve these issues before I move forward. > > Bob Rossi > |
|
From: Nicholas N. <nj...@cs...> - 2006-10-05 21:19:48
|
On Thu, 5 Oct 2006, Mohit Tiwari wrote: > I notice that running the floating point benchmarks (like ammp) takes a > substantial time. (ammp took ~15min natively and 1.5 hrs using nulgrind) > With Memcheck's ~50X overhead, it might take this 12.5 hrs to finish. Is > there a way I can switch between native and valgrind executions of a > program, so I could use a phase analyzing software like Simpoint to simulate > only certain instructions. Depends which tool you're using -- I think Callgrind might have some support for this. The other tools don't. I have found that the 'reference' data sets for SPEC are too big to benchmark, but the 'train' ones are doable, ie. they take less than a day for the full suite. Nick |
|
From: Paul W. <pa...@bl...> - 2006-10-05 20:55:14
|
On Thu, Oct 05, 2006 at 06:54:54PM +0000, sean yang wrote: > it seems that this goup is not listed on groups.google. Why is that? It > would be much useful if that happens based on my understanding. Well, to start with this isn't a newsgroup or Google group. :-) I must admit to being curious though - why would this be a useful thing? -- Paul Tick: And that's just it, Doc -- my mind has always been my Achilles' heel. |
|
From: Bob R. <bob...@co...> - 2006-10-05 20:23:43
|
On Thu, Oct 05, 2006 at 08:12:57PM +0100, Bryan Meredith wrote: > Bob Rossi wrote: > > On Thu, Oct 05, 2006 at 07:01:31PM +0100, Bryan Meredith wrote: > >> Bob Rossi wrote: > >>> On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: > >>>> Fellow Valgrinders, > >>>> > >>>> please see http://www.brainmurders.eclipse.co.uk/omega.html for a > >>>> complete overview of what this tool can do for you! > >>>> > >>>> (We use this heavily at work - feel free to give it a spin...) > >>>> > >>>> As ever, I would welcome your comments, bug reports and especially any > >>>> news of success stories. Please share them with us on the list and copy > >>>> me in so I don't miss them. > >>> Hi, > >>> > >>> I just installed valgrind with omega support. valgrind was reporting a > >>> memory leak with the memcheck tool, and I spent a good 2 hours trying to > >>> figure out if it was a leak or not, cause I couldn't find WHERE it > >>> leaked. > >>> > >>> After running with the omega tool, I'm now confronted with 122 > >>> memory leaks, where as the memcheck was saying I only had 2. > >> The results shouldn't be that different apart from the indirect leaks > >> will also be reported each time. If this isn't because of indirect leak > >> reporting, I have more work to do. Try running with "--instant-reports > >> --show-indirect" as this will make the indirect leaks stand out a bit > >> better. You might want to stick the output in a log file though :D > > > > Would it be possible to not print the indirect leaks via an option? > > You can try --instant-reports on its own (it wont show the indirect > blocks without --show-indirect) and just use the on the fly leak reports > to clue you in. This is set to only report on the first leak for a given > allocation / leak location pair. I will look at splitting this out in > the summary reports as well. If I run like this: > > > > >>> It looks like omega is not honoring the suppressions when reporting > >>> on memory leaks, is this true? > >> That is correct - I don't have suppression support in Omega. > > > > Any plans on adding this? Basically, there are some memory leaks in our > > tool that are not going away any time soon. It is sort of a pain for > > me to see them in the reports, cause it takes more time to sort through > > what is fixable now, and what is not fixable. Also, when our nigtly > > testsuite runs, when the suprressions are used, memcheck reports there > > are no memory leaks, which is really helpful. We can say if things > > passed or failed off of this. > If I run it like this: LD_LIBRARY_PATH=$VECTORCAST_DIR/lib:$LD_LIBRARY_PATH PATH=/home/TOOLS/valgrind-omega-svn-10-05-2006/bin:$PATH valgrind --tool=omega --num-callers=20 --suppressions=clicast.supp --instant-reports foo.exe > out-omega-instant.txt 2>&1 I still get massive amounts of memory leaks in comparison to memcheck. Is this what you would expect? > for some funky suppression types) but I have been focusing on getting > Omega to give the correct results first. > > > > >>> Can omega total the memory leaks that it found and report a number the > >>> way memcheck does? That number usually provides a "wow factor" to people > >>> explaining to there boss that they just stopped the coffee brewing > >>> network application from leaking 100 megs of memory each time a pot of > >>> coffee is brewed ... > >> Happy to include this for you - it will be in RC2. > > > > Thanks! > > > > Out of interest, has Omega helped you to fix any of the leaks reported > by Memcheck? To be honest, I've just started using it today, and I'm trying to resolve these issues before I move forward. Bob Rossi |
|
From: Janne H. <jjh...@gm...> - 2006-10-05 19:57:22
|
> Easier would be writing a new tool from scratch.
>
> This probably sounds intimidating, but it shouldn't be. Use "nulgrind" (the
> tool that does nothing) as the starting point, and have it register callback
> functions for the "new_mem_stack" and "die_mem_stack" functions, which are
> called every time the SP changes. See VG_(track_{new,die}_mem_stack) in
> include/pub_tool_tooliface.h.
Thanks for the tip! I modified the nulgrind tool to track the SP extremes.
I'd like to be able to control my tool from inside my instrumented
application. I thought that a pretty easy interface for this would be
to register my own software interrupt handler. This way I could
control my tool with a couple of syscalls. Is there an easier way to
do this? I'd rather not make the instrumented app depend on valgrind
header files to make it easier to build.
Janne
|
|
From: Bryan M. <bra...@go...> - 2006-10-05 19:13:04
|
Bob Rossi wrote: > On Thu, Oct 05, 2006 at 07:01:31PM +0100, Bryan Meredith wrote: >> Bob Rossi wrote: >>> On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: >>>> Fellow Valgrinders, >>>> >>>> please see http://www.brainmurders.eclipse.co.uk/omega.html for a >>>> complete overview of what this tool can do for you! >>>> >>>> (We use this heavily at work - feel free to give it a spin...) >>>> >>>> As ever, I would welcome your comments, bug reports and especially any >>>> news of success stories. Please share them with us on the list and copy >>>> me in so I don't miss them. >>> Hi, >>> >>> I just installed valgrind with omega support. valgrind was reporting a >>> memory leak with the memcheck tool, and I spent a good 2 hours trying to >>> figure out if it was a leak or not, cause I couldn't find WHERE it >>> leaked. >>> >>> After running with the omega tool, I'm now confronted with 122 >>> memory leaks, where as the memcheck was saying I only had 2. >> The results shouldn't be that different apart from the indirect leaks >> will also be reported each time. If this isn't because of indirect leak >> reporting, I have more work to do. Try running with "--instant-reports >> --show-indirect" as this will make the indirect leaks stand out a bit >> better. You might want to stick the output in a log file though :D > > Would it be possible to not print the indirect leaks via an option? You can try --instant-reports on its own (it wont show the indirect blocks without --show-indirect) and just use the on the fly leak reports to clue you in. This is set to only report on the first leak for a given allocation / leak location pair. I will look at splitting this out in the summary reports as well. > >>> It looks like omega is not honoring the suppressions when reporting >>> on memory leaks, is this true? >> That is correct - I don't have suppression support in Omega. > > Any plans on adding this? Basically, there are some memory leaks in our > tool that are not going away any time soon. It is sort of a pain for > me to see them in the reports, cause it takes more time to sort through > what is fixable now, and what is not fixable. Also, when our nigtly > testsuite runs, when the suprressions are used, memcheck reports there > are no memory leaks, which is really helpful. We can say if things > passed or failed off of this. I would like to add suppression support in (and have a couple of ideas for some funky suppression types) but I have been focusing on getting Omega to give the correct results first. > >>> Can omega total the memory leaks that it found and report a number the >>> way memcheck does? That number usually provides a "wow factor" to people >>> explaining to there boss that they just stopped the coffee brewing >>> network application from leaking 100 megs of memory each time a pot of >>> coffee is brewed ... >> Happy to include this for you - it will be in RC2. > > Thanks! > Out of interest, has Omega helped you to fix any of the leaks reported by Memcheck? Bryan |