Re: [Valgrind-users] Error using cachegrind

[Nicholas N. <nj...@ca...>]

On Wed, 16 Apr 2003, Josef Weidendorfer wrote:

> > ------------------------------------
> > ==6863== error: can't open cache simulation output file
> > `cachegrind.out.6863'
> > ==6863==        ... so simulation results will be missing.
> > ------------------------------------
> >
> > A 0 byte file cachegrind.out.6863 is created.
>
> Does your program change its cwd (current working directory) while running?

Biswapesh, can you confirm if this was the cause of your problem?


> I thought that on dump time, cachegrind will check for existence of an empty
> cachegrind.out it generates at startup. If it doesn't find it because of a
> change of the cwd, you will see the error, as the dump is always created in
> the cwd.
>
> To work around this, I made the "--base=" option to specify a prefix for dump
> files. Use an absolute path in the prefix.
>
> Nick, we should add a implementation of getcwd() to V, and use absolute file
> paths. But this still doesn't work with chroot() programs :-(
> Another option: --dumpfile-fd=...

How's this for a better solution:  let's abandon the creation of the
cachegrind.out.<pid> file at startup.  Originally, Cachegrind aborted if
it couldn't open the cachegrind.out.<pid> file, and I put the
open-at-startup code in so that if it couldn't open the file, the abort
would happen at the start of execution, not at the end after waiting what
could be a long time.

But then Cachegrind was changed so it didn't abort if the file couldn't be
opened, because sometimes with --trace-children=yes it happened often (I
can't remember why).

So now there's absolutely no point in opening the file at the start and
then reopening it at the end.  So I'd be happy to remove the opening at
the start.  But, the cachegrind.out.<pid> file should really be written in
the directory the program was invoked from, regardless of any cwd change
commands during execution, so the getcwd() implementation still seems like
a good idea.  Does this sound sensible, Josef?  I don't understand the
chroot() problem, can you explain it to me, and how it interacts here?

N