Re: [Valgrind-users] tool=cachegrind always reports LL misses, even if the cache is bigger than the used memory
On 4/25/2023 3:56 PM, Volker Dirr wrote: Hallo, maybe I misunderstood, but it look like I don't understand tool=cachegrind correct (or there is a bug). I have a software. If it runs, then the task manager tells me that is use only 38 MB memory. Now i used cachegrind like this: valgrind --tool=cachegrind --LL=2097152,16,64 ./fet-cl --inputfile=German-100_and_0.fet --randomseeds10=10 --randomseeds11=11 --randomseeds12=12 --randomseeds20=20 --randomseeds21=21 --randomseeds22=22 i got this report: [...] ==43032== LL misses: 8,283,261 ( 7,840,142 rd + 443,119 wr) i doubled the LL cache by this: valgrind --tool=cachegrind --LL=4194304,16,64 ./fet-cl --inputfile=German-100_and_0.fet --randomseeds10=10 --randomseeds11=11 --randomseeds12=12 --randomseeds20=20 --randomseeds21=21 --randomseeds22=22 and got this: [...] ==48663== LL misses: 230,426 ( 89,082 rd + 141,344 wr) That sound ok (larger cache should reduce the misses). But I continued to double the cache again and again. Up to: valgrind --tool=cachegrind --LL=268435456,16,64 ./fet-cl --inputfile=German-100_and_0.fet --randomseeds10=10 --randomseeds11=11 --randomseeds12=12 --randomseeds20=20 --randomseeds21=21 --randomseeds22=22 So much more memory then my program use at all. But the misses never drop down to 0. They stay at: [...] ==6637== LL misses: 180,120 ( 41,252 rd + 138,868 wr) I don't understand that. Shouldn't the misses drop down to 0 as soon as LL is >64MB (since my software use only 38 MB)? (But i tried up to 256MB and it doesn't drop). Is that a bug in valgrind or is there a bug in my logic in understanding the LL misses? Please let me know. I would think that, regardless of cache size, the *first* access to a line causes a miss. These are sometimes called mandatory misses. A large cache *will* eliminate *capacity* misses. HTH -- Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction bytes
On 4/18/2023 10:51 AM, folkert wrote: Hi, I wrote a compiler for brainfuck to x86. The result is quite fast but I was curious if I could tune it even more. So I ran it in callgrind but this resulted in: folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test ==77043== Callgrind, a call-graph generating cache profiler ==77043== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==77043== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==77043== Command: ./test ==77043== ==77043== For interactive control, run 'callgrind_control -h'. vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0xC3 0x67 0x80 0x3E 0x0 0x74 0x5 0x83 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==77043== valgrind: Unrecognised instruction at address 0x40274e. ==77043==at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043==by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== Your program just tried to execute an instruction that Valgrind ==77043== did not recognise. There are two possible reasons for this. ==77043== 1. Your program has a bug and erroneously jumped to a non-code ==77043==location. If you are running Memcheck and you just saw a ==77043==warning about a bad jump, it's probably your program's fault. ==77043== 2. The instruction is legitimate but Valgrind doesn't handle it, ==77043==i.e. it's Valgrind's fault. If you think this is the case or ==77043==you are not sure, please let us know and we'll try to fix it. ==77043== Either way, Valgrind will now raise a SIGILL signal which will ==77043== probably kill your program. ==77043== ==77043== Process terminating with default action of signal 4 (SIGILL) ==77043== Illegal opcode at address 0x40274E ==77043==at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043==by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== ==77043== Events: Ir ==77043== Collected : 28836 ==77043== ==77043== I refs: 28,836 Illegal instruction (core dumped) If you're curious what is going wrong here, the source assembly and the x86 binary can be retrieved from https://vanheusden.com/permshare/callgrind-error.tar.xz Oh and if you would like to assemble the assembly yourself: as -g mandelbrot.s ld -g a.out -o test ./test then results in the mandelbrot-fractal. Using an online disassembler, I found that the initial bytes decode to int 0x80, which (under Linux) is a system call. Maybe you're making a system call that valgrind does not recognize? One would need to know register contents to go further with that. Btw, naming a program "test" is not necessarily a wonderful idea if the current directory happens to be on your path, since "test" is a program often used by scripts. Cheers - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Recursive `who-points-at`
On 2/26/2023 4:29 AM, Philippe Waroquiers wrote: On Fri, 2023-02-24 at 10:42 -0700, User 10482 wrote: Dear All, I am looking to fix dangling pointer issue and was pleasantly surprised to find the `who-points-at` functionality in valgrind which tells the stack variable names (assuming --read-var-info=yes) and any addresses on heap with holding the searched address. [link](https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands) The tool is just splendid but I wish there was some way to do it recursively on the heap addresses (i.e who-points-at on the output of previous who-points-at) until we get the stack variable names holding the dangling pointers; something like how core-analyzer's `ref` command does. [link]( https://core-analyzer.sourceforge.net/index_files/Page600.html). Yes, a recursive who-points-at would be a nice thing to have. I have added this on my list of things to do (one day, whenever I have time :(). On a side note, is there a way to know which variable/type a heap address points to? That will be helpful too. The only information valgrind has about a (live) heap block is the stack trace that allocated it. Valgrind does not know the type of the object for which this memory was allocated. Unclear to me how that can be implemented (at least without support of the compiler). I wonder if gdb (or whatever debugger) info about the types of the pointers would allow providing useful information? Presumably that could be had if the executable had the information kept with it and not stripped. Best - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Regarding use of Lackey to trace midway execution of a program
On 2/8/2023 4:10 PM, SAI GOVARDHAN M C PES1UG19EC255PESU ECE Student wrote: Hi, We are students working on memory access analysis, using the Lackey tool in Valgrind. Our memory trace results in a large log file, and we need the trace from discrete points of execution (between 40-60%). Instead of logging completely, and splitting manually, is there a way we can modify the Lackey command to pick from a desired point in the execution? For reference, the command we use is $ valgrind --tool=lackey --trace-mem=yes --log-file=/path_to_log ./program We need to modify this to command to trace from 40-60% of the program If you know the approximate number of memory accesses, you could do something as simple as: valgrind ... | tail +n XXX | head -n YYY to start after XXX lines of output and stop after producing YYY lines. You could do something more sophisticated using, say, gawk, to trigger on a particular address being accessed, e.g., as an instruction fetch. This will all slow things down a bit, but might accomplish your goals. I'm not claiming there isn't some sophisticated way to tell valgrind when to start tracing, either. Also, nobody is stopping you from customizing the tool yourself :-) ... a mere exercise in programming, no? Best wishes - EM ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cache conflict detection support in cachegrind
On 1/30/2023 7:08 AM, Ivica B wrote: Can you please share the instructions on how to do it? On Sun, Jan 29, 2023, 9:07 PM Eliot Moss mailto:m...@cs.umass.edu>> wrote: I have used lackey to get traces, which I have fed into a cache model to detect conflicts and such. You could also start with the lackey code and model the cache model into the tool (which a student of mine did at one point). Lackey is one of the built-in valgrind tools. It has instructions. It produces a trace giving one memory access per line, and indicating if the access is for instruction fetch, memory read, memory write, or both read and write, with the address and size. You write a program to parse that and run your own model of whatever cache you're concerned with. Doing that part is for you to figure out. You do need to know the details of the cache you're going to model. There may be programs or libraries out there for analyzing address traces, but this would not be the list to find them. Sorry, but I'm not prepared to go through how to code a cache model ... EM ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cache conflict detection support in cachegrind
I have used lackey to get traces, which I have fed into a cache model to detect conflicts and such. You could also start with the lackey code and model the cache model into the tool (which a student of mine did at one point). Regards - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind trace Memory Addresses while running?
On 8/5/2022 8:47 PM, G N Srinivasa Prasanna wrote: Thanks for this information. We are doing a memory system simulation, and need the address stream. At this point of time, we don't care if we need a Terabyte even, we can delete the files later. Is there anything we can use from Valgrind? The lackey tool does just that - output a trace of memory references. -- Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx
On 1/14/2021 9:35 AM, Geoff Alexander wrote: I wonder if this is related to Valgrind bug 439542 Cannot compile valgrind on Ubuntu 20.04 docker due to failed compilation libmpiwrap.c (https://bugs.kde.org/show_bug.cgi?id=420518). Geoff Alexander, Ph.D. Software Engineer, Corporate Tools Development IBM Corporation Charlotte, NC It seems to be exactly the same issue. EM Koki Nagahama wrote on 01/14/2021 02:59:18 AM: > From: Koki Nagahama > To: valgrind-users@lists.sourceforge.net > Date: 01/14/2021 03:00 AM > Subject: [EXTERNAL] [Valgrind-users] I need your help because > Building VALGRIND is Failing on Ubuntu 20.xx > > Hi VALGRIND developers, I'm planning to modify a part of your... > > This Message Is From an External Sender > > This message came from outside your organization. > > Hi VALGRIND developers, > > I'm planning to modify a part of your product, VALGRIND,to integrate > it with a middleware for robots called ROS.However, I'm having > trouble building from the Valgrind source code on Ubuntu 20.xx. > > The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu > Mate 20.04 (focal) 64-bit version,so I think ARMv8 is supported, but > I can't seem to get it to work.The source code is from 3.16.1, which > came out this year. > > From reading the errors and warnings, maybe there is an obvious > reason in the source code,but maybe there are other build stoppers > after the one I failed to build,so can you please help me to > investigate the cause and help me to build successfully? > > By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may > be that the package required for make is not included in Ubuntu > 20.xx or is different, but I have no idea. > > I've uploaded the build log of my environment to Google Drive, and > the URL is listed below.Some of the logs are omitted because I ran > the command one more time after one failed build,but I hope it helps > you understand the situation. > > Build log:https://drive.google.com/file/d/1-pxnXa- > GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing > > Best Regards, > Koki___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > INVALID URI REMOVED > u=https-3A__lists.sourceforge.net_lists_listinfo_valgrind-2Dusers=DwICAg=jf_iaSHvJObTbx- > siA1ZOg=KJ6EIWC2rKHl4x6BfwQuSA=KVpnlHdoQ- > kGIfGrpIAYViKHIKfID3QJSLNoDAds8T0=PozwhcjX- > _fdLcjkvHCWdXX8fBvwKTYXFJDMpjuDjyQ= ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx
On 1/14/2021 2:59 AM, Koki Nagahama wrote: Hi VALGRIND developers, I'm planning to modify a part of your product, VALGRIND,to integrate it with a middleware for robots called ROS.However, I'm having trouble building from the Valgrind source code on Ubuntu 20.xx. The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu Mate 20.04 (focal) 64-bit version,so I think ARMv8 is supported, but I can't seem to get it to work.The source code is from 3.16.1, which came out this year. From reading the errors and warnings, maybe there is an obvious reason in the source code,but maybe there are other build stoppers after the one I failed to build,so can you please help me to investigate the cause and help me to build successfully? By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may be that the package required for make is not included in Ubuntu 20.xx or is different, but I have no idea. I've uploaded the build log of my environment to Google Drive, and the URL is listed below.Some of the logs are omitted because I ran the command one more time after one failed build,but I hope it helps you understand the situation. Build log:https://drive.google.com/file/d/1-pxnXa-GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing It is failing in the stage where it is building MPI support. Your setup seems to have mpi installed (mpicc and mpi.h are found), but apparently not a version of mpi.h that works with valgrind. You might try configuring --without-mpicc or else revert the MPI version to 2.something instead of 3.something. (The latter is a little bit of a guess, but because configure --help mentions MPI2.) HTH - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Running Valgrind on ndmp
On 9/12/2019 5:45 AM, Pallavi Shinde wrote: We ran valgrind on ndmp by inserting the valgrind command within /etc/init.d/ndmpd, the script that starts ndmpd. valgrind did indeed run on ndmpd and we did get a memory check report, but it didn't keep itself attached to ndmpd. valgrind dumps the memory check log and exits. The exit status is '1'. Don't know how to 'keep valgrind attached' to ndmpd. Would there be any guidance on how to keep valgrind attached to ndmp? What do you mean by "keep itself attached"? From what you say, it sounds as if ndmpd ran and finished, so naturally valgrind finished. Everything went as you asked. Do you mean that you want all runs of ndmpd to be done under valgrind, including future ones, not just the one kicked off in the init.d script? If so, then one way I can think of to do it is: - rename ndmpd, to, say, ndmpd.bin (for binary) - write a script called ndmpd that does: valgrind ndmpd.bin $* - make sure the script is executable, on the path, etc. Then when ndmpd is launched, you'll launch valgrind on the original ndmpd program. This is not so much a "valgrind thing" as a "how to do something on linux" thing ... Maybe somebody can think of even nicer ways to do this. Regards - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] How can valgrind prevent Segmentation fault?
On 1/26/2019 6:12 PM, Peng Yu wrote: I have an executable. If I just run on its own, there will be segmentation fault. But if I run it using valgrind, it finishes successfully. Does anybody how can this happen? How to debug such a program? Thanks. Maybe not the sort of answer you have in mind, but I might start with using gdb. It should still segfault under those conditions. You can then try recompiling to -g to get debug symbols. Doing that might affect whether the bug exhibits, but it would make debugging easier. Valgrind might be useful if you think the fault has to do with improper freeing or lack of initialization of pointers ... Regards - Eliot Moss ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction.
On 7/29/2015 11:04 PM, John Reiser wrote: disInstr(arm): unhandled instruction: 0xEEBA0BEF cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF) You can help even more by telling us which hardware you have. For instance, this is an original RaspberryPi B+: - $ cat /proc/cpuinfo processor : 0 model name: ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 2.00 Features : half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Hardware : BCM2708 Revision : 0010 - If you create a file with the unhandled instruction, and compile and disassemble it, then you can see what the instruction is: -foo.s .word 0xEEBA0BEF - $ gcc -c foo.s $ gdb foo.o (gdb) x/i 0 0: vcvt.f64.s32 d0, d0, #1 (gdb) If we are really talking about the ARM processor, this instruction is supposedly handled: https://bugs.kde.org/show_bug.cgi?id=308717 Regards -- Eliot Moss -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction.
On 7/29/2015 8:35 PM, Thomas Green wrote: I'm new to this list, but was unable to google an answer to this one. This is an unhandled instruction error, and I'm pretty sure it's not in my program (as it happens to be inside of QT, and I didn't get the warning about a bad jump). So, as the instructions say, I'm letting you know disInstr(arm): unhandled instruction: 0xEEBA0BEF cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF) ==3014== valgrind: Unrecognised instruction at address 0x4f5b628. ==3014==at 0x4F5B628: QQuickText::setFont(QFont const) (in /usr/lib/libQt5Quick.so.5.3.1) ==3014== Your program just tried to execute an instruction that Valgrind ==3014== did not recognise. There are two possible reasons for this. ==3014== 1. Your program has a bug and erroneously jumped to a non-code ==3014==location. If you are running Memcheck and you just saw a ==3014==warning about a bad jump, it's probably your program's fault. ==3014== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3014==i.e. it's Valgrind's fault. If you think this is the case or ==3014==you are not sure, please let us know and we'll try to fix it. ==3014== Either way, Valgrind will now raise a SIGILL signal which will ==3014== probably kill your program. The Intel platform has a huge number of instructions and variants on them. Valgrind covers *most* of them, but this means that this particular instruction it does not recognize. It's a moving target -- new models and new instructions come out all the time. All that said, one of the regular contributors may be able to add it ... Regards -- Eliot Moss -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
On 9/26/2014 12:38 PM, Julian Seward wrote: On 09/25/2014 12:52 PM, Eliot Moss wrote: I started updating the valgrind documentation to add description of this new feature, and expect to submit a patch soon for developer approval. https://bugs.kde.org/show_bug.cgi?id=339405 is the bug, yes? Yes, that's the bug notice with the patch to add this feature. Regards -- Eliot -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote: That's fantastic. Thank you very much for your time. It works great. Good news that it works for someone else too! I started updating the valgrind documentation to add description of this new feature, and expect to submit a patch soon for developer approval. Regards - Eliot -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote:
That's fantastic. Thank you very much for your time. It works great.
Here's how I am using it:
I have this line in my ~/.valgrindrc:
--log-file=/software/valgrind/rpts/%s{/software/dstring}-%p-report.txt
And these are the contents of /software/dstring:
echo $(ps -f $PPID | tail -n 1 | awk {print \$10})-$(date +%Y%m%d%H%M%S%N)
This results in this very nice log:
$ valgrind ls
cap.cap cov covfsn md5r rpts rpts1 rpts_fsn_errors
$ ls /software/valgrind/rpts
ls-20140925123940975544578-18453-report.txt
Kind Regards,
Costas
You're welcome! The use case that prompted me to add the feature was
using lackey to generate full memory access traces from a benchmark that
invoked subprocesses. The traces are very large, and so I compress them
by piping lackey output to gzip. This is easy to express for a single
process on the command line, but for dynamically generated subprocesses
I needed to construct a fifo, with gzip on the other end, and return
the path name of the fifo for valgrind to open. As in your case, worked
great.
Cheers -- E
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote: I really appreciate this patch. It’s exactly what I was looking for. I must be doing something wrong though. When I apply the patch and try to “make” I get this error: m_options.c: In function âvgPlain_expand_file_nameâ: m_options.c:244: warning: assignment discards qualifiers from pointer target type m_options.c:252: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â m_options.c:253: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness m_options.c:254: warning: pointer targets in passing argument 1 of âvgPlain_strcpyâ differ in signedness m_options.c:254: warning: pointer targets in passing argument 2 of âvgPlain_strcpyâ differ in signedness m_options.c:256: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â m_options.c:279: warning: pointer targets in initialization differ in signedness m_options.c:279: warning: pointer targets in initialization differ in signedness m_options.c:280: warning: pointer targets in passing argument 1 of âvgPlain_execvâ differ in signedness m_options.c:280: warning: passing argument 2 of âvgPlain_execvâ from incompatible pointer type m_options.c:327: warning: implicit declaration of function âvgPlain_sigemptysetâ m_options.c:330: warning: implicit declaration of function âvgPlain_sigactionâ m_options.c:335: warning: implicit declaration of function âvgPlain_convert_sigaction_fromK_to_toKâ m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness Line 252 is: format[i] = 0; Line 256 is: format[i] = ‘}’; Maybe I didn’t apply the patch right… The patch is against a somewhat older version of valgrind, and was also never tested in other OS environments than my own. My sense of the above is that some declarations need adjustment around signed/unsigned and const or not, or else rather than modifying 'format' in place, the code needs to copy the relevant part out to a separate string. Also, some of the routines I called in the code (execva, sigaction, strlen) seem not to have their proper declarations available. I am sure this can all be solved, but I am not sure when I will have time to work on porting it forward to present day valgrind. Thoughts from the list? Regards -- Eliot Moss -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
On 9/24/2014 7:39 AM, Eliot Moss wrote:
On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:
Ok -- I decided to just give it a try in a copy of valgrind
updated to svn head. The issue is that I was temporarily
sticking a null character into the format string, yet the
format string was declared somewhere else as const. That
declaration was righteous, and my temporary insertion of
a null I admit was a hack. I was already copying the
relevant part of the format string out into a temporary
buffer, so the actual adjustments needed were small. Once
I made those changes, it compiles and passes check tests
for me (on a linux amd64 system). I attach the updated
patch. I'll see about submitting this, though there also
needs to be an update to a section of the manual for a
complete patch to make sense for the distro.
Regards -- Eliot Moss
Index: coregrind/m_options.c
===
--- coregrind/m_options.c (revision 14564)
+++ coregrind/m_options.c (working copy)
@@ -234,6 +234,120 @@
goto bad;
}
}
+ else if ('s' == format[i]) {
+i++;
+if ('{' == format[i]) {
+ // Get the script name, get organized to invoke it
+ Char* scriptname;
+ Char* result;
+ i++;
+ int start = i;
+ while (True) {
+ if (0 == format[i]) {
+ VG_(fmsg)(%s: malformed %%s specifier\n, option_name);
+ goto bad;
+ } else if ('}' == format[i]) {
+ int nameLen = i - start;
+ Char *tempBuf = VG_(malloc)( options.efn.3, nameLen + 1 );
+ VG_(strncpy)( tempBuf, format[start], nameLen );
+ tempBuf[nameLen] = 0;
+ scriptname = tempBuf;
+
+ Int fd[2];
+ Int err;
+ if ( (err = VG_(pipe)(fd)) 0) {
+ VG_(fmsg)(%s: could not create pipe for script; err=%d\n, option_name, err);
+ goto bad;
+ }
+
+ Int pid = VG_(fork)();
+ if (pid 0) {
+ // could not fork to execute script -- die!
+ VG_(fmsg)(%s: could not fork to run script; err=%d\n, option_name, pid);
+ VG_(close)(fd[0]);
+ VG_(close)(fd[1]);
+ goto bad;
+ }
+
+ if (pid == 0) { // child
+ VG_(close)(fd[0]); // don't need the input side of the pipe
+ VG_(close)(1); // want to replace standard output
+ VG_(dup2)(fd[1], 1); // now have pipe for output
+ VG_(close)(fd[1]); // close old fd
+ Char* argv[4] = { /bin/sh, -c, scriptname, 0 };
+ VG_(execv)(argv[0], argv);
+ VG_(exit)(1); // should not get here!
+ }
+
+ VG_(close)(fd[1]);
+ Int incr = 100;
+ Int max = incr;
+ Int hardmax = 5 * incr;
+ Char* buf = VG_(malloc)( options.efn.4, max+1 );
+ Int idx = 0;
+ Int amt;
+ while ( (amt = VG_(read)( fd[0], buf+idx, max-idx )) 0 ) {
+ Int lim = idx + amt;
+ while ( idx lim ) {
+ if (buf[idx] == '\n' || buf[idx] == 0) {
+ break;
+ }
+ idx++;
+ }
+ if (idx lim) {
+ break;
+ }
+ if ( idx == max ) {
+ if ( max = hardmax ) {
+ VG_(fmsg)(%s script output too large; truncating\n, scriptname);
+ amt = 0;
+ break;
+ }
+ max += incr;
+ buf = VG_(realloc)( options.efn.5, buf, max+1 );
+ }
+ }
+ if ( amt 0 ) {
+ VG_(fmsg)(%s script: error reading output; err=%d\n, scriptname, amt);
+ goto bad;
+ }
+ buf[idx] = 0;
+ VG_(close)(fd[0]);
+ i++; // over the }
+ result = buf;
+
+ { // code cribbed from m_libcproc.c: system
+ // wait for child to finish
+ Int ir, zzz;
+ vki_sigaction_toK_t sa, sa2;
+ vki_sigaction_fromK_t saved_sa;
+ VG_(memset)( sa, 0, sizeof(sa) );
+ VG_(sigemptyset)(sa.sa_mask);
+ sa.ksa_handler = VKI_SIG_DFL;
+ sa.sa_flags= 0;
+ ir = VG_(sigaction)(VKI_SIGCHLD, sa, saved_sa);
+ vg_assert(ir == 0);
+
+ zzz = VG_(waitpid)(pid, NULL, 0);
+
+ VG_(convert_sigaction_fromK_to_toK)( saved_sa, sa2 );
+ ir = VG_(sigaction)(VKI_SIGCHLD, sa2, NULL);
+ vg_assert(ir == 0);
+ if (zzz 0) {
+ VG_(fmsg)(%s: script returned code %d\n, scriptname, zzz);
+ }
+ }
+ break;
+ }
+ i++;
+ }
+ ENSURE_THIS_MUCH_SPACE(VG_(strlen)(result));
+ j += VG_(sprintf)(out[j], %s, result);
+} else {
+ VG_(fmsg)(%s: expected '{' after '%%s'\n, option_name);
+ goto bad;
+}
+ }
else {
// Something else, abort.
VG_(fmsg)(%s: expected 'p' or 'q' or '%%' after '%%'\n,
@@ -261,7 +375,7 @@
bad: {
HChar* opt =// 2: 1
Re: [Valgrind-users] Unique log filename
On 9/23/2014 10:11 AM, Skarakis, Konstantinos wrote:
Hello,
I want to run a big project over a long time under Valgrind’s Memcheck. I am
using --log-file in
conjunction with %p to generate log files per process ID. This means that
over time I will start
losing log files due to PID reuse. Is there a way to make my logs unique so
that they will not be
overwritten? Maybe some way to get a timestamp in the filename? I know that
the only other available
specifier is %q, but I haven’t found a way to make this work.
I am running on Suse Linux 64bit.
Thanks,
Costas
Dear Costas -- I am not aware of anything to do that, but a while back
I wrote a patch that allows an additional format specifier, %s{}
which runs a script and argument that are specified in the {},
and the result of that script is used as the file name for the log
file. It would be easy enough, given that functionality, to write
a script that returns a time stamp. I will see if I can narrow this
down to a small patch that I can submit, and when I do, I can email
you the patch at the same time. I did this a while ago, but if this
part of the code has not been changed a lot, then the patch should
not be too bad to extract.
I've been meaning to submit it for some time, actually, and this is
a good prompt to make me do it!
Regards -- Eliot Moss
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unique log filename
Ok, here's the patch to add the %s{script} form
to log-file expansion. The script is run via
/bin/bash -c script, and its output replaces the
while %s form. The max length my code allows
for the result is 500 characters, which seemed
enough for anything realistic. Note that the
pid of the invoking valgrind will be the script's
PPID, etc.
If the powers that be think this might be
generally useful, then let me know how you would
prefer to receive the patch, and any tidying you
feel would be in order ...
Regards -- Eliot Moss
Index: m_options.c
===
--- m_options.c (revision 12572)
+++ m_options.c (working copy)
@@ -227,6 +227,122 @@
goto bad;
}
}
+ else if ('s' == format[i]) {
+i++;
+if ('{' == format[i]) {
+ // Get the script name, get organized to invoke it
+ Char* scriptname;
+ Char* result;
+ i++;
+ scriptname = format[i];
+ while (True) {
+ if (0 == format[i]) {
+ VG_(fmsg)(%s: malformed %%s specifier\n, option_name);
+ goto bad;
+ } else if ('}' == format[i]) {
+ // Temporarily replace the '}' with NUL to extract script
+ // name.
+ format[i] = 0;
+Char *tempBuf = VG_(malloc)( options.efn.3,
VG_(strlen)(scriptname) );
+VG_(strcpy)( tempBuf, scriptname );
+scriptname = tempBuf;
+format[i] = '}';
+
+Int fd[2];
+Int err;
+if ( (err = VG_(pipe)(fd)) 0) {
+ VG_(fmsg)(%s: could not create pipe for script;
err=%d\n, option_name, err);
+ goto bad;
+}
+
+Int pid = VG_(fork)();
+if (pid 0) {
+ // could not fork to execute script -- die!
+ VG_(fmsg)(%s: could not fork to run script; err=%d\n,
option_name, pid);
+ VG_(close)(fd[0]);
+ VG_(close)(fd[1]);
+ goto bad;
+}
+
+if (pid == 0) { // child
+ VG_(close)(fd[0]); // don't need the input side of
the pipe
+ VG_(close)(1); // want to replace standard output
+ VG_(dup2)(fd[1], 1); // now have pipe for output
+ VG_(close)(fd[1]); // close old fd
+ Char* argv[4] = { /bin/sh, -c, scriptname, 0 };
+ VG_(execv)(argv[0], argv);
+ VG_(exit)(1); // should not get here!
+}
+
+VG_(close)(fd[1]);
+Int incr = 100;
+Int max = incr;
+Int hardmax = 5 * incr;
+Char* buf = VG_(malloc)( options.efn.4, max+1 );
+Int idx = 0;
+Int amt;
+while ( (amt = VG_(read)( fd[0], buf+idx, max-idx )) 0 )
{
+ Int lim = idx + amt;
+ while ( idx lim ) {
+ if (buf[idx] == '\n' || buf[idx] == 0) {
+ break;
+ }
+ idx++;
+ }
+ if (idx lim) {
+ break;
+ }
+ if ( idx == max ) {
+ if ( max = hardmax ) {
+ VG_(fmsg)(%s script output too large;
truncating\n, scriptname);
+ amt = 0;
+ break;
+ }
+ max += incr;
+ buf = VG_(realloc)( options.efn.5, buf, max+1 );
+ }
+}
+if ( amt 0 ) {
+ VG_(fmsg)(%s script: error reading output; err=%d\n,
scriptname, amt);
+ goto bad;
+}
+buf[idx] = 0;
+VG_(close)(fd[0]);
+ i++; // over the }
+result = buf;
+
+{ // code cribbed from m_libcproc.c: system
+ // wait for child to finish
+ Int ir, zzz;
+ vki_sigaction_toK_t sa, sa2;
+ vki_sigaction_fromK_t saved_sa;
+ VG_(memset)( sa, 0, sizeof(sa) );
+ VG_(sigemptyset)(sa.sa_mask);
+ sa.ksa_handler = VKI_SIG_DFL;
+ sa.sa_flags= 0;
+ ir = VG_(sigaction)(VKI_SIGCHLD, sa, saved_sa
Re: [Valgrind-users] memory barriers support
On 8/18/2014 9:09 AM, Jan Včelák wrote: Hello list, we develop an authoritative DNS server called Knot DNS and we use the userspace-rcu library [1] for synchronization. The library implements the synchronization by inserting appropriate sfence/lfence/mfcence instructions and some reference counting around. Currently, we are trying to track down an invalid read reported by Valgrind. The problem appears very rarely and it's quite difficult to reproduce. Valgrind claims that a previously freed memory is being read. However we quite sure that the synchronization is correct and that this problem should not happen. Does Valgrind support the mentioned memory barrier instructions? If it did not *recognize* the instruction, then valgrind would bomb out with an error message giving the op code byte sequence and saying it did not recognize it. A possibility is that it recognizes the instruction but does not implement it as you expect. Someone else will need to answer as to that possibility. I'm not rejecting that there is a problem in our code, but I want to make sure that we are chasing a real bug. You might want to verify that valgrind and your code have the same notion of what the malloc/free routines are, etc., i.e., that valgrind is able to hook into all allocation and freeing calls your application uses. Best wishes -- Eliot Moss -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Memcheck with Jikes RVM
On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: I can confirm that Jikes RVM does it own special allocation of stacks, which might be involved here. I am wondering why anyone would think a tool like memcheck would work with a Java virtual machine like JikesRVM, with its own notion of object, garbage collection, etc. For example, JikesRVM almost certainly explicitly clears memory before using it for objects, which would mean it is initialized, and verified Java bytecode will never access an uninitialized local variable. I suppose you might get some mileage on checking JNI / native code stuff, but I'm not sure. So, I am intrigued, but also wondering if maybe you're barking up the wrong tree here ... Regards -- Eliot (Hi, Sam!) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Memcheck with Jikes RVM
On 7/8/2014 3:47 PM, Karl Cronburg wrote: On 07/08/2014 02:48 PM, Philippe Waroquiers wrote: On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote: On 7/8/2014 2:04 PM, Philippe Waroquiers wrote: On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: We're interested in using malloc/free client requests to see if we can get memcheck to tell us when the garbage collector is handling its' own memory incorrectly. That sounds like a radical change to Jikes RVM. At present it doesn't really use malloc/free. It mmaps big chunks and manages them all itself, both for the system (i.e., outside of the garbage collected universe) and for the GC'ed heap. Best wishes -- EM -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] understanding massif output when run against a simple executable
On 5/14/2014 2:21 PM, Rob Taylor wrote: Thank you Milian Wolff and Eliot Moss, Typical users of tools like valgrind have more background in how all this works -- not a criticism of you, just a difference in expectation. The volume of code that results from compiling a program consisting of a main function that simply returns is quite small. It is stored on disk in the executable file produced by the C compiling and linking process. That file also describes any global / static storage needed for the program. When a process is created to run the program, the operating system sets up an area in low memory (not the stack) for that data. Local / automatic (in C terminology) variables are allocated in the stack, and done so by each function as you enter the function. The operating system grows the stack (from high addresses toward lower ones) automatically. It is also possible to allocate, and free, memory on request using library functions such as malloc and free. Any libraries used will be linked in (connected to your code) on demand, and they may also have static data areas and may malloc/free data as well. You may benefit from finding documentation or a textbook about how compiling, linking, loading, etc., works for C programs in Unix/Linux, etc. (The Windows world is similar, though of course different in some details.) Regards -- Eliot Moss -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] New to valgrind
On 4/1/2013 2:43 PM, Dan Kegel wrote: On Mon, Apr 1, 2013 at 11:33 AM, sukbir singh shai_...@hotmail.com wrote: I want to trace now what is the cause of this leaks any idea please? I have with this option valgrind --tool=memcheck --log-file=file-memLog --track-origins=yes --leak-check=yes java myApp1. I think Valgrind isn't meant for use with java in general... Maybe you want http://stackoverflow.com/questions/40119/how-to-find-a-java-memory-leak ? Agreed. It *might* be relevant for gcj, the GNU compiler for Java, which probably has something more like malloc/free underneath, but even then it might not be appropriate. Regards -- Eliot Moss -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind Error Message on standard if statement
On 2/11/2013 12:55 AM, David Hourn (DTH Design) wrote:
char *getInputNoNewline(int max, char message[]) { static char* input; int
maxchars = max+ADDCHARS
input = (char*)malloc(maxchars); input = getInput(max, message); if
(input[strlen(input) - 1] ==
'\n') { input[strlen(input) - 1] = '\0'; } return input; }
Just looking at this code, I see these issues:
- You allocate space for input then overwrite the pointer to that space,
as other correspondents have noted.
- You call strlen more than once. Wasteful, though not *harmful*.
- You are counting on getInput to return a string that has at least
one character in it; if it has no characters then you will access
input[-1], which is out of range (and you might potentially damage
some other data structure, such as a header that malloc uses to
track items and to handle freeing).
If you expect no more than one \n in the string, then strchr may be
what you want, or strrchr to find the last \n regardless. If they
return non-null, you can examine the next byte to see if it is \0
and then clear the \n safely.
Regards -- Eliot Moss
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind Error Message on standard if statement
On 2/11/2013 6:04 PM, David Hourn (DTH Design) wrote: Cheers guys, After reviewing the code the general issues I was having was memory management, and trying to access memory that had been freed. Having only started coding in C two days ago it's probably a fair common problem. This is the full code that I am using (I should've done this yesterday. Didn't think to pastebin) http://pastebin.com/tewJSX3W Compiling and running that code through valgrind gives me no errors which is great, however there is still 12 non-freed blocks at the end. 9 definitely lost - Am I right in saying these are getInput.in (allocated line 25), getInputNoNewline.input (allocated line 39) and main.IntIn(initialised line 51). And there are 3 still reachable blocks, which i'm guessing are the three blocks that make up the players array (allocated line 53) ? Well, you make 9 input calls, each of which allocates a buffer, and you allocate the players array (it is one malloc object, even though it is 3 structs). You free the players array, but none of the strings it points to. The 3 IntIn assignments are blocks just dropped. In getInput, input and in point to the same place, so should not be a problem. This code will not necessarily work right if there is an I/O error or fgets reads NO chars at all. Likewise, getInputNoNewline may make an improper access: you should check len 0 *before* accessing in[len - 1]. The still-reachable blocks mystify me a little. The only one I see is the last IntIn, since players is freed and the rest won't be reachable from any accessible variable. Of course there are block in library routines, such as an I/O buffer for stdout, etc. Regards -- Eliot Moss -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Fwd: [Valgrind-developers] vex: r2532: Fix PCMPxSTRx variant $0x46. Fixes #306664.
It's always nice to have additional cases covered. May I gently suggest that if an 8-bit case is added, the 16-bit case also be added at the same time? :-) Regards -- Eliot Moss Original Message Subject: [Valgrind-developers] vex: r2532: Fix PCMPxSTRx variant $0x46. Fixes #306664. Date: Mon, 17 Sep 2012 14:40:12 +0100 From: s...@valgrind.org To: valgrind-develop...@lists.sourceforge.net sewardj 2012-09-17 14:40:11 +0100 (Mon, 17 Sep 2012) New Revision: 2532 Log: Fix PCMPxSTRx variant $0x46. Fixes #306664. Modified files: trunk/priv/guest_amd64_toIR.c trunk/priv/guest_generic_x87.c -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] where is the official git tree for valgrind?
On 6/26/2012 4:15 AM, Tom Hughes wrote: On 26/06/12 07:38, lei yang wrote: can someone show me where is the official git tree for valgrind? There isn't one - valgrind uses svn. Details of the repository can be found on the web site: http://www.valgrind.org/downloads/repository.html Of course, if you prefer using git, you can do git svn clone ... Regards -- Eliot Moss -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] how to disable unhandled instruction bytes error reporting
On 6/4/2012 1:23 PM, Amstoutz Marc wrote: Hi valgrind experts, I’m facing an unhandled instruction issue when valgrinding ing intel-ipp libraries. ~/valgrind-3.7.0/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes --error-limit=no --log-file=valgrnd.txt --gen-suppressions=all … vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0xFC 0xD 0x37 0xBB 0x22 0x0 ==12078== valgrind: Unrecognised instruction at address 0x4cacf71. ==12078== at 0x4CACF71: ??? (in …) ==12078== by 0x4CA3282: y8_ippiFilterDeblockingLuma_VerEdge_H264_8u_C1IR (in …) I have tried to disable error reporting using VALGRIND_DISABLE_ERROR_REPORTING/ VALGRIND_ENABLE_ERROR_REPORTING macros without success. Could you help me to disable error reporting for this error ? In addition, do you think such error should be reported as a bug (I’ve noticed similar bugs into the bugbase) ? Dear Marc -- You can't disable that. It means that valgrind encountered instructions that it does not know what to do with. There is no way for it to continue sensibly (beyond causing a signal, which presumably is unhandled here). A quick look suggests that this is a PADDB instruction. I think someone has been working on adding some of those instructions latelt; it *might* be covered if you grab and build from svn head. Regards -- Eliot Moss (a fellow user and occasional patch contributor) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about Valgrind
On 3/23/2012 9:10 AM, Hamid Reza Khaleghzadeh wrote: Hi, I have some questions about Valgrind tool. I would be thankful if answer me. 1- I want to know does Valgrind support Pthread and openMP programs? 2- I need a tool that traces my multi-threaded program and creates memory trace of the program. The trace must contain accessed memory address, threadID and access type(Read/Write). Sorry to bother you with my questions. It does support multiple threads, but runs only one thread at a time. I don't personally know the answer to the OpenMP question. For a memory trace, you can take and extend the lackey tool slightly to have it output the thread id in addition to the type of reference, the address, and the number of bytes referenced. That should be a straightforward change if you can find where to get the thread id in valgrind. (I've not looked for that information, but system call tracing in valgrind certainly prints it, so it should not be hard to get.) Regards -- Eliot Moss -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about Valgrind
On 3/23/2012 12:21 PM, Hamid Reza Khaleghzadeh wrote: Hi Dear Eliot, I added valgrind-users back so that all can follow the email thread. Thanks for your answer. You said that Valgrind does support multiple threads, but runs only one thread at a time. Suppose a two threaded application. The threads run in parallel. Suppose thread1 read A, thread2 simultaneously write A, and thread1 read A again. In this case, records of output trace are as following (holds order of access) ? Thread1 read A Thread2 write A Thread1 read A It depends on whether the scheduler swaps threads at the two places indicated. Perhaps it will help to think of the trace as being what you might get from running your multi-thread program on a single cpu, where the operating system periodically switches between runnable threads. In fact, valgrind will try to switch when the underlying OS does. However, for various reasons valgrind tends to emulate the execution of whole sequences of instructions in one go, and such thread switching will not happen in the middle of a sequence. Thus if Thread1 reads A twice in the *same* such sequence, you will never see Thread2 do anything between the two reads. You may be able to control with your instrumentation where the sequences end, but performance will be very bad if you end them at every read and write. Also, you still get each thread normally running for a full scheduler quantum before a switch will be attempted. In sum, you should get one *possible* execution, but it won't necessarily be one typical of truly concurrent execution. (Just because you have threads that are *runnable* at the same time does not mean that they actually run *concurrently* in a real system, unless you guarantee multuple cpus are available. You can think of valgrind as providing a universe where only one cpu is *ever* available.) There are many good reasons why valgrind is this way; it would be substantially more difficult to build (and maintain!) a similar tool that supported true concurrency. Thanks for your answer in advance. No problem. Eliot Moss -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Add missing syscall (setns())
I'm not super-familiar with this part of the code, but I wonder if the insertion you put in syswrap-generic.c needs to be in syswrap-linux.c, to match where you put things in syswrap-linux.h ... Eliot Moss -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Callgrind] Illegal Instruction - how to find the cause?
On 2/25/2012 4:10 PM, Steve Burden wrote: I should've mentioned of course that I'm using 3.8.0-SVN, checked out about a week ago (at home now so I cannot check the exact revision number right now). In any case, the fresh air on the walk home made me think: 0x0616aeee +606: prefetchw BYTE PTR [rdi+0x340] The prefetchw instruction doesn't sound as something common to me, so I would not be surprised if it is not implemented in Callgrind/LibVex. I can't explain yet why that instruction is hit only with certain data though. Is there an 'implemented instructions' list available for LibVex ? I had checked and it looks as if guest_amd64_toIR implements this case (parsing the guest instruction, but generating no IR for it, since it is *semantically* a no-op). I don't understand why it fails unless if was added since you checked out from SVN. Best wishes -- Eliot Moss -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Behavior diffenert with valgrind without valgrind
On 2/23/2012 7:51 AM, jee wrote: My code change itself with running, and, I use VALGRIND_DISCARD_TRANSLATIONS with I changed the function's assembly code. and my code is pure C++. i rewrite the assembly code like this: inline hook: mov addr, %rax jmp *%rax I insert this assembly code to the begin of functions, I can run my elf fine. but with valgrind, the code's behavior israndom. mostly, it goto deadly lock. You have self-modifying code, so probably need to specify some flavor of the --smc-check option to valgrind. See the man page :-) ... Best wishes -- Eliot Moss -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] A question about AMD 0x66 prefixes
On 2/14/2012 6:12 PM, Julian Seward wrote:
So ... I am running tests with the decoder revised to allow 0x66 on the fpu
instructions.
Does anyone know of a reason why doing this would be bad/wrong?
Giving a blanket OK for 0x66 on FPU instructions makes me nervous, that we
might inadvertantly accept an 0x66 prefix that had some significance, and
then ignore it.
I understand your skittishness about it, but I quote from the AMD manual
(pages 8-9 of Volume 3 (URL below)):
The operand-size prefix should be used only with general-purpose instructions
and the x87 FLDENV, FNSTENV, FNSAVE, and FRSTOR instructions, in which the
prefix selects between 16-bit and 32-bit operand size. The prefix is ignored
by all other x87 instructions and by 64-bit media floating-point (3DNow!)
instructions.
So, this says that the four indicated instructions should check for the size
explicitly, and the rest should ignore it. I have verified in the case of FLD
that the machine in fact ignores it. It would be painful to go verify it with
the rest of the opcodes, though possible in principle. For FNSAVE and FRSTOR
I have implemented both the 16- and 32-bit versions -- the application that
valgrind was failing to work with used 16-bit FRSTOR (and maybe FNSAVE too,
but I put them bth in at once, and FRSTOR was the one it had failed on). Then
it failed on 0x66 FLDL and I went to check up on things and found the quoted
statement. I will make sure that FNSTENV and FLDENV check for size (or
implemented their 16-bit version as well, which should be easy given the
implementations of FNSAVE and FRSTOR).
I *do* make sure that the 0xF2 and 0xF3 (opcode extension) prefixes are *not*
given, since they do affect the semantics. Here's the code I am testing now:
in dis_ESC_NONE, for the 0xD8 through 0xDF cases of the switch on opc:
Bool redundantREXWok = False;
if (haveF2orF3(pfx))
goto decode_failure;
/* kludge to tolerate redundant rex.w prefixes (should do this
properly one day) */
/* mono 1.1.18.1 produces 48 D9 FA, which is rex.w fsqrt */
if ( (opc == 0xD9 getUChar(delta+0) == 0xFA)/*fsqrt*/ )
redundantREXWok = True;
/* AMD manual says 0x66 size override is ignored, except where it is
meaningful */
if ( (sz == 2 || sz == 4 || (sz == 8 redundantREXWok)) ) {
Bool decode_OK = False;
delta = dis_FPU ( decode_OK, vbi, pfx, delta );
if (!decode_OK)
goto decode_failure;
} else {
goto decode_failure;
}
return delta;
The if could probably read: if ( (sz != 8) || redundantREXWok ) ...
Is it possible you can add the specific necessary exemptions in the place
where dis_FPU is called (shown below), so that we continue to disallow 0x66
for FPU instructions in the general case?
You didn't show it. But given what AMD says, there are no specific
exemptions. If we're willing to put in patches for each case people
run into in practice, I have coded it and tested on my programs.
My app does not appear to have more of these (admittedly silly) 0x66
prefixed fpu opcodes.
Bool redundantREXWok = False;
if (haveF2orF3(pfx))
goto decode_failure;
/* kludge to tolerate redundant rex.w prefixes (should do this
properly one day) */
/* mono 1.1.18.1 produces 48 D9 FA, which is rex.w fsqrt */
if ( (opc == 0xD9 getUChar(delta+0) == 0xFA)/*fsqrt*/ )
redundantREXWok = True;
Bool size_OK = False;
if ( sz == 4 )
size_OK = True;
else if ( sz == 8 )
size_OK = redundantREXWok;
else if ( sz == 2 ) {
int mod_rm = getUChar(delta+0);
int reg = gregLO3ofRM(mod_rm);
if ( (opc == 0xDD) (reg == 0 || reg == 4 || reg == 6) ) {
size_OK = True;
}
}
/* AMD manual says 0x66 size override is ignored, except where it is
meaningful */
if ( size_OK ) {
Bool decode_OK = False;
delta = dis_FPU ( decode_OK, vbi, pfx, delta );
if (!decode_OK)
goto decode_failure;
} else {
goto decode_failure;
}
return delta;
What do you think at this point?
Regards -- Eliot
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On 2/9/2012 6:55 AM, Istvan Csanady wrote: Hi All, I am trying to use Valgrind on OS X 10.7.3, and when I try to start a Cocoa application, it always crashes at the following point: vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8 0x6A That looks like a variant of the PCMPxSTRx instruction. I am working on a patch that will add *some* new cases to that instruction, not previously supported by valgrind, but at a glance this one is different :-( ... I can't look into the manuals now to be certain, but can probably get back within a day. Perhaps someone else can verify it. If this variant is close enough to existing ones, I *might* be able to add it to what I am patching Regards -- Eliot Moss -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Apparent bug in svn head
On 2/7/2012 5:19 AM, Julian Seward wrote: Thank you, Julian, for your patient instructions :-) ... # merge any other changes that happened in the meantime cd VEX svn up cd .. Why only VEX? I also added tests in none/test/amd64. Is there some reason to avoid svn up in the valgrind top-level directory? # remake, re-test # generate diff cd VEX svn diff -rHEAD # send the diff That's clear enough, but are you saying you want the tests as a separate patch? One thing though. Bugs discussed on mailing lists tend to get forgotten or otherwise fall through the cracks. A much more reliable approach, if you have bugs/patches in future, is to file a bug as described at http://valgrind.org/support/bug_reports.html and do all the discussion, patches, patch reviewing etc in the bug report. Right. I'll put in a bug report before submitting the patch. I hope to get to all this within a week (a big thing happening at work is draining any spare cycles). I'll post the other missing instruction as a bug report too. I am also on the trail of something that looks like an unimplemented (or differently implemented?) system call. The Java program under test, which is the DaCapo eclipse benchmark, complains that it can't create the workspace it's going to work on, throws an exception, and quits. There is no valgrind complaint. However, if I run the benchmark without valgrind, it completes normally. Does valgrind restrict the number of open files? I noticed that the benchmark had over 50 files open, and might have hit a limit if it is set at 64 or something. My next step is to compare trace output without valgrind to valgrind --trace-syscalls=yes and see where the system calls majorly diverge. Of course it could be something else, but ... I also have one run that just core dumps. No valgrind end-of-run stuff, no complaint, just a core dump. I am scratching my head a bit on how to dig in on that one, since it seems to have jumped to address 0 and I don't get stack back trace ... but maybe I am being simple-minded about how I use gdb on this ... Is there a way to file a bug report with a core dump? Regards -- Eliot -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Apparent bug in svn head
On 2/7/2012 5:13 PM, Julian Seward wrote: I'm clear about the 2 repos business now :-) ... I'll post the other missing instruction as a bug report too. I am also on the trail of something that looks like an unimplemented (or differently implemented?) system call. The Java program under test, which is the DaCapo eclipse benchmark, complains that it can't create the workspace it's going to work on, throws an exception, and quits. There is no valgrind complaint. However, if I run the benchmark without valgrind, it completes normally. Does valgrind restrict the number of open files? I noticed that the benchmark had over 50 files open, and might have hit a limit if it is set at 64 or something. My next step is to compare trace output without valgrind to valgrind --trace-syscalls=yes and see where the system calls majorly diverge. Of course it could be something else, but ... I also have one run that just core dumps. No valgrind end-of-run stuff, no complaint, just a core dump. I am scratching my head a bit on how to dig in on that one, since it seems to have jumped to address 0 and I don't get stack back trace ... but maybe I am being simple-minded about how I use gdb on this ... You're running with --smc-check=all or (better, if it works) --smc-check=all-non-file, right? These are mandatory when doing jitted code. Omitting it will cause the program under test to run off the road and disappear into the shrubbery. The former, not the latter -- perhaps slower but safer, no? Someone who had used valgrind with a jitting JVM before clued me in on that one :-) ... Regards -- EM -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Apparent bug in svn head
A little while ago I posted about the non-implementation of the AMD 64 SSE 4.2 instructions PCMPxSTRx for 16-bit characters (many 8-bit sub-operations were supported). I got them working, and was (reasonably) directed to move to svn head if I want to be able to send in a patch. I did that, but when I run the updated valgrind on the same program as before (Oracle's HotSpot JVM), it fails on a 0xF 0xAE 0x3F instruction, which appears to be either a CLFLUSH or an SFENCE (both decode the same way in the docs, so I am slightly confused). Either way, it worked in the latest stable release, and I didn't mess with that decoding. I will see if I can replicate it on svn head without my mods, but wanted to give a heads up. Any notion what's happening? It is becoming apparent that it might be nice to have more control over which x86 family processor is supported as the guest. If I downgraded the guest some then I think that HotSpot would avoid these instruction that I am having to add ... which come about apparently because valgrind claims via cpuid to support a really advanced processor, but then does not support all of its instructions. But I can see that it would be a significant project to support a range of guest processor capabilities controlled with flags, etc. Regards -- Eliot Moss -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unimplemented x64 instruction: 0x66 0xDD 0x4 (frstor)?
On 1/30/2012 3:29 AM, Julian Seward wrote: I would have thought that FSAVE/FRSTOR in 64 bit mode is essentially useless, and the fact that we've not so far needed to implement them kind of supports that suspicion. Reason is that they don't save or restore the XMM registers. The x86-64 bit ELF ABI requires floating point values to be in the XMM registers; hence FSAVE/FRSTOR don't succeed in correctly saving and restoring the CPU's floating point state. What you need for that is FXSAVE and FXRSTOR, and they are indeed implemented. I couldn't find an ELF ABI requirement that floating point values *must* be in XMM regs versus MMX regs. The difference I could find is that MMX registers are not saved across calls -- but saving and restoring might still be useful if you are doing MMX computations ... Anyway, HotSpot uses them :-) ... They may not be interesting for *OS* use though ... Does this seem right? Regards -- Eliot -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Unimplemented x64 instruction: 0x66 0xDD 0x4 (frstor)?
Dear valgrind-ers -- I am enjoying getting started with valgrind and have been trying to apply it to a couple of Java VMs, Jikes RVM and HotSpot (the usual Oracle/Sun JVM). While valgrind seems to play well with Jikes RVM, I have run into two unimplemented instructions for x64 used by HotSpot: 0x66 0x0F 0x3A 0x61 0x06 0x0D: PCMPESTRI for 16-bit characters For this one I am attempting to add the 16-bit versions of those PCMPxSTRx instructions already supported for 8-bit. Once I have tested it some, I will see about submitting a patch. It's relatively straightforward. 0x66 0xDD 0x4: FRSTOR with size-change prefix. For AMD guest FRSTOR is completely commented out. I am guessing it was originally copied from x86 (since the contents of the commented our code correspond with guest_x86 code) but never really ported to AMD. Several runs of HotSpot on DaCapo benchmarks fail under valgrind because this instruction is missing. Could someone perhaps clarify whether it simply hasn't been done or if there is some deeper reason why the code was commented out? Regards -- Eliot Moss PS -- I did search the archives on these but failed to find anything immediately relevant. Sorry if it's there but I missed it ... EM -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
