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
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Josef W. <Jos...@gm...> - 2006-01-11 15:02:20
|
On Wednesday 11 January 2006 13:56, Julian Seward wrote:
>
> > is my question: can I just obtain that by reading the current memory
> > contents at the given address at the time the instrumentation function
> > gets executed? From looking at the source code, I assume that yes,
> > because the instrumentation appears to be always after (later in the
> > basic block than) the instruction(s) it instruments. Could someone
> > please confirm or deny whether I understand the code correctly?
>
> I think that's right (not 100% sure). Use --tool=cachegrind
> --trace-flags=10001000 to see the relationship between the initial IR
> and the instrumented IR. The calls to simulation functions are grouped
> in sets of up to 8 for efficiency reasons, so the instrumented IR
> looks a bit strange at first.
Wrong.
I just checked:
int main()
{
volatile int a;
a = 3;
a = 5;
return a;
}
08048240 <main>:
int main()
{
8048240: 55 push %ebp
8048241: 89 e5 mov %esp,%ebp
8048243: 83 ec 18 sub $0x18,%esp
8048246: 83 e4 f0 and $0xfffffff0,%esp
volatile int a;
a = 3;
8048249: c7 45 fc 03 00 00 00 movl $0x3,0xfffffffc(%ebp)
a = 5;
8048250: c7 45 fc 05 00 00 00 movl $0x5,0xfffffffc(%ebp)
return a;
8048257: 8b 45 fc mov 0xfffffffc(%ebp),%eax
804825a: 83 ec 10 sub $0x10,%esp
}
Relevant output of
valgrind --tool=cachegrind --trace-flags=10001000 ./a.out
------ IMark(0x8048249, 7) ------
PUT(60) = 0x8048249:I32
t22 = Add32(t19,0xFFFFFFFC:I32)
STle(t22) = 0x3:I32
------ IMark(0x8048250, 7) ------
PUT(60) = 0x8048250:I32
t24 = Add32(t19,0xFFFFFFFC:I32)
STle(t24) = 0x5:I32
------ IMark(0x8048257, 7) ------
PUT(60) = 0x8048257:I32
t26 = Add32(t19,0xFFFFFFFC:I32)
STle(t26) = 0x7:I32
------ IMark(0x804825E, 3) ------
PUT(32) = 0x6:I32
PUT(36) = t5
PUT(40) = 0x10:I32
PUT(44) = 0x0:I32
PUT(16) = Sub32(t5,0x10:I32)
------ IMark(0x8048261, 3) ------
PUT(60) = 0x8048261:I32
t28 = Add32(t19,0xFFFFFFFC:I32)
PUT(0) = LDle:I32(t28)
------ IMark(0x8048264, 1) ------
PUT(60) = 0x8048264:I32
PUT(16) = t19
PUT(20) = LDle:I32(t19)
t31 = Add32(t19,0x4:I32)
PUT(16) = t31
DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3]{0xb0003e4c}(0x61D55E7C:I32,t19,0x4:I32)
DIRTY 1:I1 ::: log_3I_0D_cache_access[rp=3]{0xb00019a6}(0x61D55E88:I32,0x61D55E94:I32,0x61D55EA0:I32)
DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3]{0xb0003e4c}(0x61D55EAC:I32,t22,0x4:I32)
DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3]{0xb0003e4c}(0x61D55EB8:I32,t24,0x4:I32)
DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3]{0xb0003e4c}(0x61D55EC4:I32,t26,0x4:I32)
DIRTY 1:I1 ::: log_2I_0D_cache_access[rp=2]{0xb0000b00}(0x61D55ED0:I32,0x61D55EDC:I32)
DIRTY 1:I1 ::: log_0I_1Dr_cache_access[rp=3]{0xb0004cf0}(0x61D55EDC:I32,t28,0x4:I32)
DIRTY 1:I1 ::: log_1I_1Dr_cache_access[rp=3]{0xb0002fa8}(0x61D55EE8:I32,t19,0x4:I32)
------ IMark(0x8048265, 1) ------
So all the calls are delayed to the end of main.
The helper has no chance to get at the 3 written first.
Perhaps you should add the read/written value as parameter of the helper.
Josef
>
> J
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
|
|
From: Julian S. <js...@ac...> - 2006-01-11 12:57:25
|
> is my question: can I just obtain that by reading the current memory > contents at the given address at the time the instrumentation function > gets executed? From looking at the source code, I assume that yes, > because the instrumentation appears to be always after (later in the > basic block than) the instruction(s) it instruments. Could someone > please confirm or deny whether I understand the code correctly? I think that's right (not 100% sure). Use --tool=cachegrind --trace-flags=10001000 to see the relationship between the initial IR and the instrumented IR. The calls to simulation functions are grouped in sets of up to 8 for efficiency reasons, so the instrumented IR looks a bit strange at first. J |
|
From: Martin H. <hi...@gm...> - 2006-01-11 03:07:06
|
Hi, For cachegrind, the instrumenter inserts calls to functions that drive a cache simulation. The cache simulation only needs to know where memory cells are read or written, not what the contents of those memory cells are, since that doesn't affect whether there is a hit or miss. But I would like to abuse the write instrumentation in a situation where I do need to know the newly written values. Now here is my question: can I just obtain that by reading the current memory contents at the given address at the time the instrumentation function gets executed? From looking at the source code, I assume that yes, because the instrumentation appears to be always after (later in the basic block than) the instruction(s) it instruments. Could someone please confirm or deny whether I understand the code correctly? Thank you, Martin |
|
From: Tom S. <to...@pl...> - 2006-01-10 16:40:40
|
Keith wrote: > I am trying to valgrind a java application (our code is written in C and > published through a JNI layer) and when running under valgrind, it uses 100% > CPU but it appears to hang. I don't see any activity but one of the CPUs is > always maxed out. > > > > I'm using the latest code because I need a very recent fix to even get it to > run. > > > > What can I do to troubleshoot? > > > > Thanks, > > Keith > > You didn't mention which JVM you are using. I have never been able to valgrind our JNI app using the Sun JVM. After testing a number of JVMs, the SableVM is the one that works best for me when valgrinding. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Julian S. <js...@ac...> - 2006-01-10 14:05:49
|
[On amd64, once clflush is fixed, java JIT spins at 100% CPU] Keith You're the second person to report this problem - Martin has the same on x86. I don't know why the spin happens. One possibility is that it could be due to atomic insns used for synchronisation: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits: Atomic instruction sequences are not properly supported, in the sense that their atomicity is not preserved. This will affect any use of synchronization via memory shared between processes. They will appear to work, but fail sporadically. At this point perhaps the best thing is for you to put together a simple test case so I can at least try and reproduce the problem at this end. It's going to take a bit of GDBing to see what's going on. One quick thing to do: rerun V with --trace-flags=10000000 --trace-notbelow=999999. This prints out one line for each block translated and might give a clue about the names of the function it gets stuck in. Send the last hundred or so lines of the log. J |
|
From: Dirk M. <dm...@gm...> - 2006-01-10 13:12:14
|
On Tuesday 10 January 2006 13:59, Keith Mange wrote:
> The application normally takes a few seconds to load. I gave it 4 hours
> running under valgrind before giving up.
Ok, then it probably really hung somewhere. strace/ltrace telling something?
does an attached gdb produce a sensible backtrace (most likely not, but it
would be worth a try).
then you either have to figure out how to reduce it to a small code snippet
that reproduces the valgrind lockup or try to look through the valgrind debug
output to see if you can find something obvious on why it locks up. see
valgrind --help-debug output:
--sanity-level=<number> level of sanity checking to do [1]
--profile=no|yes profile? (tool must be built for it) [no]
--trace-flags=<XXXXXXXX> show generated code? (X = 0|1) [00000000]
--profile-flags=<XXXXXXXX> ditto, but for profiling (X = 0|1) [00000000]
--trace-notbelow=<number> only show BBs above <number> [0]
--trace-syscalls=no|yes show all system calls? [no]
--trace-signals=no|yes show signal handling details? [no]
--trace-symtab=no|yes show symbol table details? [no]
--trace-cfi=no|yes show call-frame-info details? [no]
--trace-sched=no|yes show thread scheduler details? [no]
--wait-for-gdb=yes|no pause on startup to wait for gdb attach
--command-line-only=no|yes only use command line options [no]
Also, try if "valgrind --tool=none" works for your application. that would be
very important to know.
Dirk
|
|
From: Keith M. <kei...@ch...> - 2006-01-10 13:00:07
|
The application normally takes a few seconds to load. I gave it 4 hours running under valgrind before giving up. -Keith -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Dirk Mueller Sent: Tuesday, January 10, 2006 2:44 AM To: val...@li... Subject: Re: [Valgrind-users] 100% CPU On Tuesday 10 January 2006 02:32, Keith wrote: > I am trying to valgrind a java application (our code is written in C and > published through a JNI layer) and when running under valgrind, it uses > 100% CPU but it appears to hang. I don't see any activity but one of the > CPUs is always maxed out. Well, it *could* be very slow (like factor 150 or more slower than without valgrind). Is that not the case? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2006-01-10 08:44:11
|
On Tuesday 10 January 2006 02:32, Keith wrote: > I am trying to valgrind a java application (our code is written in C and > published through a JNI layer) and when running under valgrind, it uses > 100% CPU but it appears to hang. I don't see any activity but one of the > CPUs is always maxed out. Well, it *could* be very slow (like factor 150 or more slower than without valgrind). Is that not the case? |
|
From: Keith <kei...@gm...> - 2006-01-10 01:33:07
|
I am trying to valgrind a java application (our code is written in C and published through a JNI layer) and when running under valgrind, it uses 100% CPU but it appears to hang. I don't see any activity but one of the CPUs is always maxed out. I'm using the latest code because I need a very recent fix to even get it to run. What can I do to troubleshoot? Thanks, Keith |
|
From: Josef W. <Jos...@gm...> - 2006-01-09 16:59:06
|
On Monday 09 January 2006 17:39, you wrote: > On Mon, 9 Jan 2006, Josef Weidendorfer wrote: > > >> What about jumps that should be there but aren't? > > > > That is a matter of debug info. If one instruction maps to source > > file:100, and the next to file:200, there is obviously a "jump" in the > > source code from line 100 to 200, and the compiler has linearized this. > > That's a reasonable heuristic, but it won't always be true; there could > just be a big comment. Right. This reminds me of a wish list for the tool API: Iterator interfaces for debug info: eg. function symbols defined in a segment and source lines of functions. This would allow to get all the source lines which are attributed to instructions, even for code which is never executed. This would ease above problem, and would be good for a code coverage module. Or is there currently a way for a tool to get the source line of instructions which were never executed? > > There can be a huge gap between source and assembler. E.g. look at > > OpenMP code generated by the Intel compiler. You will see a totally > > different control flow, and the compiler generates new functions > > for parallel regions. > > Yes, it's a hard problem. Yes. It would be nice for a visualization tool to be able to show the mapping from source to assembler in a meaningful, understandable way. But everything beyound using the debug line info seems to be problematic. I have no problem to show the exact control flow in the assembler annotation of KCachegrind (via jump arrows), but mapping this to jumps in the source is difficult. Currently, KCachegrind does something alike, but this is just confusing. And that is the reason that "--collect-jumps=yes" is an option in callgrind. Perhaps the best is to try to detect loop nests, and see if this can be mapped better to source... Josef > > Nick > > |
|
From: Tom S. <to...@pl...> - 2006-01-09 16:57:50
|
Julian Seward wrote: > Here's an excerpt from SuSE-9.3 related email: > > --11932-- DWARF2 CFI reader: unhandled CFI instruction 0:50 > These appear in both /lib/tls/libc.so.6 and /lib/tls/libpthread.so.0. > I could not find what these were by looking in the DWARF3 spec. > > So I asked readelf to read the call-frame-info and it has no idea > either: > > sewardj@nemesis:~/VgHACKED/trunk$ readelf > --debug-dump=frames /lib/tls/libc.so.6 > /dev/null > readelf: Warning: unsupported or unknown DW_CFA_50 > readelf: Warning: unsupported or unknown DW_CFA_50 > > From this I was convinced that the CFA info from the libraries itself > was bad, since readelf was also complaining about it. What do you get > if you try the same on Debian testing? I get identical results with Debian testing: rota:~$ readelf --debug-dump=frames /lib/tls/libc.so.6 > /dev/null readelf: Warning: unsupported or unknown DW_CFA_50 readelf: Warning: unsupported or unknown DW_CFA_50 For the archives, the version of libc.so.6 is 2.3.5-8. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Nicholas N. <nj...@cs...> - 2006-01-09 16:44:10
|
On Mon, 9 Jan 2006, Jeroen N. Witmond wrote: >> So after using a modification of Cachegrind and Lackey to collect >> instruction reads, loads and stores, I get something like the following: >> >> ins : 0x40FA821 >> ins : 0x40FA823 >> ins : 0x40FA824 >> ins : 0x40FA826 >> ins : 0x40FA828 >> ins : 0x40FA831 >> load : 0x41BF5C0, 4 >> store: 0x41BF5C0, 4 >> ins : 0x40FA834 >> ins : 0x40FA837 >> ins : 0x40FA83A >> >> I was wondering why the instructions referenced aren't consecutive. Is it >> because Valgrind has added additional instructions during its translation? >> Or is that how instructions really are read in real programs? > > The length of an instruction can vary from 1 to 15 bytes (at least on > x86/amd64 type CPUs). What I see above is a linear sequence of > instructions of 1, 2, or 3 bytes long. Yep, and if you run it on PowerPC you'll see the instructions are all 4 bytes long and on 4-byte boundaries. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-01-09 16:40:00
|
On Mon, 9 Jan 2006, Josef Weidendorfer wrote: >> What about jumps that should be there but aren't? > > That is a matter of debug info. If one instruction maps to source > file:100, and the next to file:200, there is obviously a "jump" in the > source code from line 100 to 200, and the compiler has linearized this. That's a reasonable heuristic, but it won't always be true; there could just be a big comment. > The compiler is allowed to do everything. Inlining simply can not be > shown as calling a function, because instructions can be reordered, > duplicated etc. The inlined function has to be seen as part of the > calling function, and perhaps the only useful thing here is to shown > jumps among source lines. > > There can be a huge gap between source and assembler. E.g. look at > OpenMP code generated by the Intel compiler. You will see a totally > different control flow, and the compiler generates new functions > for parallel regions. Yes, it's a hard problem. Nick |
|
From: Patrick O. <Pat...@gm...> - 2006-01-09 12:44:08
|
On Sat, 2006-01-07 at 19:03 -0800, John Reiser wrote: > > There isn't really a problem. LinuxThreads does this: [...] > > So, you can safely write a suppression for this error. There are already suppressions for this in valgrind's default glibc-2.2.supp which were good enough to suppress all errors in a program using LinuxThreads on RH AS2.1. However, since at least valgrind 3.0 they no longer work because of new stack backtraces like this one here (from Ron's report): ==17229== Syscall param write(buf) points to uninitialised byte(s) ==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so) ==17229== by 0x80484D4: main (main.c:13) ==17229== Address 0xBEFFF9AC is on thread 1's stack I had already reported this as http://bugs.kde.org/show_bug.cgi?id=119446 Bye, Patrick -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie |
|
From: Josef W. <Jos...@gm...> - 2006-01-09 10:29:52
|
On Monday 09 January 2006 00:33, Michael E Locasto wrote: > The tool I'm trying to build can be thought of as an strace-style tool, > but for application and library functions rather than system calls. Look at the output of "callgrind -ct-verbose=1 ..". It writes a line with correct indentation on calls to functions. Returns are shown implicitly via the indentation, but it could be easily modified. > For > the moment, I'm concentrating on x86 and keeping track of return values. > I'd eventually like to expand monitoring to function arguments as well. For showing return values and function parameters (types/names), you need to write a dwarf parser for this type of debug information, or use libdwarf. The later is probably not easy, as tools should use valgrinds own libc. > > Another thing is how to interpret jumps between functions which are not allowed > > in high level languages, but neverless exist e.g. because of tail recursion > > optimization or handcrafted assembler (as in the runtime linker). Either > > you interpret the jump as "call", and naturally get multiple returns in a row > > afterwards (which is automatically handled by synchronization of the shadow > > stack with real stack pointer), or you simulate the jump by a return/call pair. > > What about jumps that should be there but aren't? That is a matter of debug info. If one instruction maps to source file:100, and the next to file:200, there is obviously a "jump" in the source code from line 100 to 200, and the compiler has linearized this. I currently do not check for this in callgrind, which is the reason that jump arrow annotation for source currently is not really useful. > For example, I'm > guessing this sort of analysis doesn't hold for functions that have > been inlined as a result of compiler optimization. But then again, I don't > suppose anything can detect that situation from just the instruction > stream. The compiler is allowed to do everything. Inlining simply can not be shown as calling a function, because instructions can be reordered, duplicated etc. The inlined function has to be seen as part of the calling function, and perhaps the only useful thing here is to shown jumps among source lines. There can be a huge gap between source and assembler. E.g. look at OpenMP code generated by the Intel compiler. You will see a totally different control flow, and the compiler generates new functions for parallel regions. Josef |
|
From: Igmar P. <mai...@jd...> - 2006-01-09 07:43:06
|
> Last I heard (if I remember correctly) this was caused by a bug in > the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this > on SuSE 9.3 on a low-end x86? Debian Stable (3.1) also has this. Since I'll probably switch to CentOS soon, it will probably go away :) Regards, Igmar |
|
From: Jeroen N. W. <jn...@xs...> - 2006-01-09 07:21:51
|
> > So after using a modification of Cachegrind and Lackey to collect > instruction reads, loads and stores, I get something like the following: > > ins : 0x40FA821 > ins : 0x40FA823 > ins : 0x40FA824 > ins : 0x40FA826 > ins : 0x40FA828 > ins : 0x40FA831 > load : 0x41BF5C0, 4 > store: 0x41BF5C0, 4 > ins : 0x40FA834 > ins : 0x40FA837 > ins : 0x40FA83A > > I was wondering why the instructions referenced aren't consecutive. Is it > because Valgrind has added additional instructions during its translation? > Or is that how instructions really are read in real programs? The length of an instruction can vary from 1 to 15 bytes (at least on x86/amd64 type CPUs). What I see above is a linear sequence of instructions of 1, 2, or 3 bytes long. HTH Jeroen. > > Thanks in advance. > > Zac > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-01-09 02:54:54
|
So after using a modification of Cachegrind and Lackey to collect instruction reads, loads and stores, I get something like the following: ins : 0x40FA821 ins : 0x40FA823 ins : 0x40FA824 ins : 0x40FA826 ins : 0x40FA828 ins : 0x40FA831 load : 0x41BF5C0, 4 store: 0x41BF5C0, 4 ins : 0x40FA834 ins : 0x40FA837 ins : 0x40FA83A I was wondering why the instructions referenced aren't consecutive. Is it because Valgrind has added additional instructions during its translation? Or is that how instructions really are read in real programs? Thanks in advance. Zac |
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-01-09 02:43:41
|
> What you want is probably > addr_expr = mkIRExpr_HWord( st->Ist.IMark.addr ); > Does that work? Thanks Julian, that works great. Zac |
|
From: Michael E L. <me...@co...> - 2006-01-08 23:33:43
|
Josef, Thank you for the description of what the difficulties are... On Sun, 8 Jan 2006, Josef Weidendorfer wrote: > I think it probably would be good to extract the minimal things from > callgrind for robust call tracing into a separate tool; it can not I agree, and I'm looking at callgrind's source to see how I can adapt it. The tool I'm trying to build can be thought of as an strace-style tool, but for application and library functions rather than system calls. For the moment, I'm concentrating on x86 and keeping track of return values. I'd eventually like to expand monitoring to function arguments as well. > Another thing is how to interpret jumps between functions which are not allowed > in high level languages, but neverless exist e.g. because of tail recursion > optimization or handcrafted assembler (as in the runtime linker). Either > you interpret the jump as "call", and naturally get multiple returns in a row > afterwards (which is automatically handled by synchronization of the shadow > stack with real stack pointer), or you simulate the jump by a return/call pair. What about jumps that should be there but aren't? For example, I'm guessing this sort of analysis doesn't hold for functions that have been inlined as a result of compiler optimization. But then again, I don't suppose anything can detect that situation from just the instruction stream. > If the common case for the SP synchronization is done inline, I can imagine > that pure robust call tracing could get quite fast. The "problem" with It seems like it can, and I think something employing it would be useful for regression testing, among other things. > callgrind getting faster is the further context maintaining. And I suppose > this mixture makes callgrind source quite difficult to understand... I'm working my way through it ;) Cheers, Michael |
|
From: Ron K. <ro...@ko...> - 2006-01-08 07:55:32
|
I read the glibc-audit page which answers that very question. Thank you, Ron "Ron Korving" <ro...@ko...> wrote in message news:dpqeti$9eu$1...@se...... ... > I wonder why the patches in glibc-audit > haven't been made final in glibc? But that's > probably a subject that's not > meant for this mailinglist. ... |
|
From: Ron K. <ro...@ko...> - 2006-01-08 07:28:00
|
Awesome, thank you very much guys. I really want to suppress these issues,
which I think is the easiest step here. I could use an edited libpthread,
but I'd need to do that on every machine I was compiling on. I have no clue
how to suppress these errors yet, but I'm sure the manual has plenty to say
about that. I do hope that these suppression configurations suppress a kind
of problem, and not one instance of a problem, because then I'd have to keep
suppressing new errors every time I use a pthread function. In that case I'd
be better of using glibc-audit. I wonder why the patches in glibc-audit
haven't been made final in glibc? But that's probably a subject that's not
meant for this mailinglist.
Anyway, thanks a lot guys, you've really helped out a lot.
Ron
"John Reiser" <jreiser@BitWagon.com> wrote in message
news:43C08114.305@BitWagon.com...
> > There isn't really a problem. LinuxThreads does this:
> >
> > struct pthread_request {
> > ...
> > enum { ... } req_kind;
> > union { ... fields that depend on req_kind };
> > };
> >
> > struct pthread_request req;
> > req.req_kind = ...;
> >
> > // code that fills some, *but not all* of the other fields
> >
> > write(pipe_to_thread_manager, &req, sizeof(req)); // triggers:
> >
> >
> >>==17229== Syscall param write(buf) points to uninitialised byte(s)
> >
> >
> > because some of the bytes in req are uninitialized.
>
> So, you can safely write a suppression for this error.
> If you want to adjust libpthread itself so that it never
> uses uninit bytes, then see
> http://bitwagon.com/glibc-audit/glibc-audit.html
> for suitable patches. In this case, the fix uses
> memset(&req, 0, sizeof(req)); /* 2003-04-15 be kind to auditors */
> shortly after declaration but before any assignments to the struct.
> Besides eliminating the message from memcheck, the change also
> observes proper hygiene with respect to information leaks
> from the stack of one thread to another thread.
>
> --
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
|
|
From: John R.
|
> There isn't really a problem. LinuxThreads does this:
>
> struct pthread_request {
> ...
> enum { ... } req_kind;
> union { ... fields that depend on req_kind };
> };
>
> struct pthread_request req;
> req.req_kind = ...;
>
> // code that fills some, *but not all* of the other fields
>
> write(pipe_to_thread_manager, &req, sizeof(req)); // triggers:
>
>
>>==17229== Syscall param write(buf) points to uninitialised byte(s)
>
>
> because some of the bytes in req are uninitialized.
So, you can safely write a suppression for this error.
If you want to adjust libpthread itself so that it never
uses uninit bytes, then see
http://bitwagon.com/glibc-audit/glibc-audit.html
for suitable patches. In this case, the fix uses
memset(&req, 0, sizeof(req)); /* 2003-04-15 be kind to auditors */
shortly after declaration but before any assignments to the struct.
Besides eliminating the message from memcheck, the change also
observes proper hygiene with respect to information leaks
from the stack of one thread to another thread.
--
|
|
From: Paul P. <ppl...@gm...> - 2006-01-08 01:52:44
|
On 1/7/06, Ron Korving <ro...@ko...> wrote: > I'm having trouble with pthreads even with the simplest program. I'm usin= g > valgrind 3.1.0 on debian sarge using linux-2.4.26. ... > I compile it like this: gcc -lpthread -ggdb ./main.c The link line above is incorrect (though it just happens to work). Correct build line is: gcc -pthread -ggdb main.c You may wish to read this if you want to understand why "-lpthread" doesn't belong where you've put it: http://webpages.charter.net/ppluzhnikov/linker.html > The errors that this tiny program cause in valgrind are appended to the > bottom of this message. These are "normal" for LinuxThreads. > I don't have a clue what the problem could be. There isn't really a problem. LinuxThreads does this: struct pthread_request { ... enum { ... } req_kind; union { ... fields that depend on req_kind }; }; struct pthread_request req; req.req_kind =3D ...; // code that fills some, *but not all* of the other fields write(pipe_to_thread_manager, &req, sizeof(req)); // triggers: > =3D=3D17229=3D=3D Syscall param write(buf) points to uninitialised byte(s= ) because some of the bytes in req are uninitialized. Cheers, |
|
From: Josef W. <Jos...@gm...> - 2006-01-08 00:22:13
|
On Saturday 07 January 2006 19:21, Nicholas Nethercote wrote: > On Fri, 6 Jan 2006, Michael E Locasto wrote: > > > A tool I'm constructing needs to be able to detect returns from a function. > > Tracking function entry/exit is in general very difficult, much more so > than you might expect. Josef Weidendorfer's Callgrind tool does a good > job, in the Valgrind source tree there's a file called > docs/internals/tracking-fn-entry-exit.txt which describes the hoops it has > to jump through. Hi, I think it probably would be good to extract the minimal things from callgrind for robust call tracing into a separate tool; it can not be done as a core module as it needs its own instrumentation which could conflict with a tools instrumentation needs; so a tool writer has to be aware of the instrumentation needs of call tracing. Basically, it comes down to maintain shadow call stacks for each thread and signal handler. These are updated according to calls and returns in the instruction stream, and most important: for robustness, a synchronization of the shadow stacks with the stack pointer is needed to handle longjmps (especially nasty: longjmps from signal handlers back into normal code - quite common with ADA compiler code). The most compelling reason why callgrind always (since support for VG3) is using "--vex-guest-chase-thresh=0" is the following: you can not see from the VEX code if an unconditional jump was a real call or only a jump, because it is thrown away by chaising. Julian: Can we introduce VEX hints (translating to NOOPs) for such cases, e.g. so that a tool can see what jump kind got thrown away by chasing BBs? It gets a little bit more complicated in callgrind because it does not use the pure function name on top of the shadow stack for the event counts relation, but adds another context on top of the function name, which includes the tread ID and possibly the call chain to this function (or even ignore function calls by merging with the caller). Another thing is how to interpret jumps between functions which are not allowed in high level languages, but neverless exist e.g. because of tail recursion optimization or handcrafted assembler (as in the runtime linker). Either you interpret the jump as "call", and naturally get multiple returns in a row afterwards (which is automatically handled by synchronization of the shadow stack with real stack pointer), or you simulate the jump by a return/call pair. If the common case for the SP synchronization is done inline, I can imagine that pure robust call tracing could get quite fast. The "problem" with callgrind getting faster is the further context maintaining. And I suppose this mixture makes callgrind source quite difficult to understand... Josef |