|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 06:23:30
|
Hi
I'm getting the following error with CVS valgrind + cachegrind skin (
alias cachegrind='valgrind --skin=cachegrind --num-callers=25
--logfile-fd=6'
/opt/gnome2.2/bin/valgrind
------------------------------------
==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. There is sufficient space
in the harddisk :
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 37334192 15213876 20223844 43% /
Can someone give me a clue ?
Thanks in adavnce.
--
Biswa.
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-16 08:08:56
|
On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > I'm getting the following error with CVS valgrind + cachegrind skin ( > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > --logfile-fd=6' > /opt/gnome2.2/bin/valgrind > > ------------------------------------ > ==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. There is sufficient space > in the harddisk : > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 37334192 15213876 20223844 43% / Is file descriptor 6 legitimate? Does it work if you let Valgrind's output go to stderr as usual? N |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-16 08:23:03
|
I just did: calltree ./SciTE ~/GNOME2.2/src/anjuta/src/aneditor.cxx It just creates some 0 byte cachegrind.out.* files :-( No warnings about unable to write this time though. Any clues ? On Wed, 2003-04-16 at 13:38, Nicholas Nethercote wrote: > On 16 Apr 2003, Biswapesh Chattopadhyay wrote: > > > I'm getting the following error with CVS valgrind + cachegrind skin ( > > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > > --logfile-fd=6' > > /opt/gnome2.2/bin/valgrind > > > > ------------------------------------ > > ==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. There is sufficient space > > in the harddisk : > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda2 37334192 15213876 20223844 43% / > > Is file descriptor 6 legitimate? Does it work if you let Valgrind's > output go to stderr as usual? > > N -- Biswa. |
|
From: Josef W. <Jos...@gm...> - 2003-04-16 08:35:49
|
On Wednesday 16 April 2003 08:31, Biswapesh Chattopadhyay wrote: > Hi > > I'm getting the following error with CVS valgrind + cachegrind skin ( > alias cachegrind='valgrind --skin=cachegrind --num-callers=25 > --logfile-fd=6' > /opt/gnome2.2/bin/valgrind > > ------------------------------------ > ==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. There is sufficient space > in the harddisk : > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 37334192 15213876 20223844 43% / > > Can someone give me a clue ? Does your program change its cwd (current working directory) while running? 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=... Josef > > Thanks in adavnce. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-21 22:19:31
|
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 |
|
From: Josef W. <Jos...@gm...> - 2003-04-27 14:31:38
|
On Tuesday 22 April 2003 00:19, Nicholas Nethercote wrote: > ... > > 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 Yes. > 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 Yes again. To tell the true, the "--base=" CLO addition was a quick workaround for this problem, as there's no getcwd() in valgrind's libc. We should add it and use the cwd at program start as absolute path for the cachegrind.out files. > 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? After a chroot(), a process can only access files below the given root in chroot(), if the files wasn't opened already. E.g, when cachegrinding the FTP damon, you don't have access to the cwd at program start on dump time. But I think this is neglectable, as chroot() is rare. > > N > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 20:24:00
|
On Sun, 27 Apr 2003, Josef Weidendorfer wrote: > > > Nick, we should add a implementation of getcwd() to V, and use absolute > > > file paths. But this still doesn't work with chroot() programs :-( Done: Cachegrind now uses getcwd() at startup and just dumps cachegrind.out.<pid> in that directory at the end. Should fix the problems. I just committed it to the CVS HEAD. N |