Bug 369456 - callgrind_control failed to find an active callgrind run.
Summary: callgrind_control failed to find an active callgrind run.
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: callgrind (show other bugs)
Version: 3.11.0
Platform: Homebrew (macOS) macOS
: NOR normal
Target Milestone: ---
Assignee: Josef Weidendorfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-28 04:24 UTC by Alex
Modified: 2016-10-03 10:40 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2016-09-28 04:24:45 UTC
I'm running callgrind with:
$ valgrind --tool=callgrind  --instr-atstart=no ./program_name

Then trying to enable profiling from other terminal:
$ callgrind_control -i on
No active callgrind runs detected.

The same with PID:
$ callgrind_control -i on 80627
Error: Callgrind task with PID/name '80627' not detected.

Valgrind in process list:
$ ps
  PID TTY           TIME CMD
 1021 ttys000    0:00.32 -bash
80627 ttys000    0:56.54 valgrind --tool=callgrind --instr-atstart=no ./program_name
 5280 ttys002    0:00.24 -bash

Some additional info:
uname -a
Darwin macpc-1124 14.5.0 Darwin Kernel Version 14.5.0: Mon Aug 29 21:14:16 PDT 2016; root:xnu-2782.50.6~1/RELEASE_X86_64 x86_64
Comment 1 Josef Weidendorfer 2016-09-28 13:48:27 UTC
callgrind_control uses "vgdb" starting from Valgrind 3.11 to get a list of running valgrind instances.
Perhaps this is not working on OSX.
What is the output of "vgdb -l" with callgrind running?
Comment 2 Alex 2016-09-29 04:57:26 UTC
$ vgdb -l
use --pid=93572 for (could not open process command line)

93572 is the right PID of running valgrind.
Comment 3 Philippe Waroquiers 2016-09-29 20:19:53 UTC
I ported and tested vgdb on macos some years ago, so the basic of vgdb should work.
What is not done on macos is the (optional) vgdb  (ptrace based on linux) functionality
that takes a process out of a syscall.

Another difference between vgdb on linux and macos is that vgdb cannot find
the command line by opening "/proc/%d/cmdline", pid);

This means vgdb -l reports e.g.
use --pid=93572 for (could not open process command line)

This is probably the reason for which callgrind_control does not work, as I guess it expects
something that matches :
     if (/^use --pid=(\d+) for \S*?valgrind\s+(.*?)\s*$/) {

So, I suppose that fixing the perl regexp there to also match the (could not ....)
should allow callgrind_control to work
Comment 4 Alex 2016-09-30 04:30:07 UTC
Fixing regex can help to find PID. Something like that (I'm not familiar with perl/regex):
$ vgdb -l | perl -lpe'/^use --pid=(\d+) for [\S\s]+$/; print $1;'
30750
use --pid=30750 for (could not open process command line)

But callgrind_control also check  that running tool is callgrind.
There is no such info in the string returning from vgdb -l.

So I can make little hack in callgrind_control for using it until this will be fixed.
Thanks.
Comment 5 Philippe Waroquiers 2016-09-30 19:12:37 UTC
(In reply to Alex from comment #4)
> Fixing regex can help to find PID. Something like that (I'm not familiar
> with perl/regex):
> $ vgdb -l | perl -lpe'/^use --pid=(\d+) for [\S\s]+$/; print $1;'
> 30750
> use --pid=30750 for (could not open process command line)
> 
> But callgrind_control also check  that running tool is callgrind.
> There is no such info in the string returning from vgdb -l.
Yes, a proper fix implies to have a way to find the command line (or at least the
launched executable) on MacOS.
No idea how to do that (and moreover I have no access to a MacOS system).
Maybe Rhys has an idea ?
Comment 6 Alex 2016-10-03 10:40:21 UTC
May be I can help?
MacOS has proc_pidinfo (from sys/proc_info.h or libproc.h) for obtaining info about running app.
Probably ps, top and others use it.
Or popen something like "ps -p <pid> -o command" and parse.
The second variant is potentially multi-platform.