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 <josef.weidendor...@gmx.de> 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:
> >
> > st...@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 <josef.weidendor...@gmx.de>
> 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
> > > >
> > >
> > >
> > >
> >
>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
