|
From: Stephen M. <mo...@gm...> - 2010-07-13 18:15:50
|
Hi Josef, It was exactly what you said in that /opt/Adobe/Reader9/bin/acroread is a script that sets up the environment. I have modified this and now all is good. Sorry, I should of realised that before bothering you. I am using Ubuntu (64bit Lucid, 10.04) by the way. One issue I do have though is that the true acroread binary is 32bit. I attempted to re-compile valgrind with only 32bit support for a test but configure complained that I did not have all the requirements for the '--enable-only32bit' option. Do you know if this is fairly straightforward to do in Ubuntu? If not, I shall do the analysis in a 32bit vmware image. Many thanks again, Steve On 12 July 2010 21:30, Josef Weidendorfer <Jos...@gm...> wrote: > On Monday 12 July 2010, Stephen Mortimer wrote: > > Many thanks for your reply. I did try it without the -w option and get > the > > error: > > > > /tmp$ callgrind_control -s > > No active callgrind runs detected. > > [Detection can fail on some systems; to work around this, > > specify the working directory of a callgrind run with '-w'] > > What distro is this? You either have the proc filesystem not mounted > (see output of "mount" for a line with "proc on ..."; if this does not > exist, run as root "mount /proc"), or somehow permissions are not set > to let you access your own processes under /proc. > > Anyway... if you can not change this, you have to use "-w". > > > I assumed that the callgrind working directory would be the directory > that I > > run "valgrind --tool=callgrind acroread" (in this case /tmp). > > For "acroread", yes. However, if acroread is a script and forks/execs > subprocesses, > these are not automatically run within Valgrind/Callgrind, and you only can > control > the script with callgrind_control - however, this script probably will just > sleep > and wait for the termination of the children processes. > > To also run Callgrind for the child processes, use "--trace-children=yes" > (this is > a generic Valgrind option). > > > I have tried moving the mouse and opening a file via the menu and still > see > > no output from callgrind_control. > > > > I notice that there are a number of callgrind.info.[PID] files created in > > /tmp, example is: > > > > steve@pen1:/tmp$ cat callgrind.info.21987 > > # This file is generated by Callgrind-3.6.0.SVN. > > # It is used to enable controlling the supervision of > > # '/opt/Adobe/Reader9/bin/acroread' > > # by external tools. > > > > version: 1.0 > > base: /tmp > > dumps: /tmp/callgrind.out.21987 > > control: /tmp/callgrind.cmd.21987 > > result: /tmp/callgrind.res.21987 > > cmd: /opt/Adobe/Reader9/bin/acroread > > > > This would suggest that the working directory is /tmp? I tried pointing > > callgrind_control to /tmp but still get no output. > > Yes. > > Can you check whether /opt/Adobe/Reader9/bin/acroread is a ELF binary > are actually a wrapper script? It would be better to just run the real > binary with > Callgrind; any wrapper script usually just sets some environment variables, > which > you need to do yourself before running any real binary. > > > Have you any tips as the how to find the actual working directory? I am > > afraid I am not very familiar with ptrace. > > Using "ptrace" as control method is not implemented yet... > > Best, > Josef > > > > > Steve > > > > > > On 12 July 2010 10:46, Josef Weidendorfer <Jos...@gm...> > wrote: > > > > > On Monday 12 July 2010, Stephen Mortimer wrote: > > > > I am trying to use Callgrind to run determine the code coverage of a > > > large > > > > number of PDF files opened in Adobe Reader to then provide me with a > much > > > > smaller set of files that have unique code coverage. > > > > > > > > The method is as follows: > > > > > > > > 1. I run Adobe Reader in Valgrind with the Callgrind tool enabled. > > > > 2. Then open the first file. > > > > 3. Now run Callgrind_Control (callgrind_control -w /tmp/ -s) > > > > 4. Note the number of "Basic Blocks" > > > > 5. Now close that file and open another > > > > 6. Repeat steps 3 to 5 for each file and only keep files that show > new > > > Basic > > > > blocks have been hit > > > > > > Interesting. > > > When no new translated BBs show up, no new code was executed, yes. > > > > > > > The issue I have is that this works fine if I use evince to read the > > > files > > > > but when I run Adobe Reader in the callgrind tool, callgrind_control > does > > > > not give me any output, just hangs with the "[requesting Status]" > prompt: > > > > > > > > /tmp$ callgrind_control -w /tmp/ -s > > > > [requesting 'Status'...] > > > > > > The "-w" options is only a workaround if callgrind_control is not able > > > to detect the current working directory of the callgrind process (by > > > checking /proc/*/cwd). Usually, you should not need it. > > > > > > Communication between callgrind_control and the callgrind process is > done > > > by creating command and result files in the working dir of the > callgrind > > > process. > > > Callgrind regularily polls for commands, but only every X executed BBs > of > > > the > > > client program. > > > > > > So if callgrind_control hangs, it can have two causes: > > > (1) the client code waits in an OS calls, thus does not executed any > client > > > code, > > > which effectively suspends command polling. You have to trigger code > > > execution > > > somehow, eg. by moving the mouse pointer into the Adobe Reader window. > > > (2) the working directory of the callgrind process is not /tmp, as you > > > suspect. > > > Just try out without "-w" option first, and if this fails, try to > detect > > > the > > > working dir yourself, and use this as argument for -w. > > > > > > > I suspect that this is because Adobe Reader is opening a number of > > > processes > > > > when run, but the main process callgrind.out file does not contain > any > > > > output, all output goes into the other process files. > > > > > > Perhaps the process doing the actual work does not have /tmp as working > > > directory? > > > > > > Josef > > > > > > PS: Command file polling is not really the best way for controlling > > > callgrind > > > processes from the outside. A better way seems to be using ptrace. > > > > > > > > > > > /tmp$ ps -ef |grep Adobe > > > > steve 20800 4754 1 10:07 pts/2 00:00:01 > > > > /opt/Adobe/Reader9/Reader/intellinux/bin/acroread > > > > /tmp$ ls -ltrh > > > > total 448K > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20800 > > > > -rw------- 1 steve steve 68K 2010-07-12 10:07 callgrind.out.20802 > > > > -rw------- 1 steve steve 67K 2010-07-12 10:07 callgrind.out.20801 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20807 > > > > -rw------- 1 steve steve 73K 2010-07-12 10:07 callgrind.out.20810 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20815 > > > > -rw------- 1 steve steve 74K 2010-07-12 10:07 callgrind.out.20805 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20817 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20819 > > > > -rw------- 1 steve steve 76K 2010-07-12 10:07 callgrind.out.20821 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20824 > > > > -rw------- 1 steve steve 80K 2010-07-12 10:07 callgrind.out.20827 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20828 > > > > -rw-r--r-- 1 steve steve 6 2010-07-12 10:07 callgrind.cmd > > > > > > > > > > > > Is there a way around this issue? > > > > > > > > Many thanks, > > > > Steve Mortimer > > > > > > > > > > > > > > > > > > |