[ControlPort]
on = True #False
edges_list = True #False
I continue to run into the following message when I include a ‘ctrlport
performance monitor’ in my flowgraph:
ControlPort Monitor running.
monitor::endpoints() = -h rbell -p 49158
running: [‘gr-perf-monitorx’, ‘rbell’, ‘49158’]
Configuration has not turned on all of the appropriate ControlPort
features:
[ControlPort] on = True
[ControlPort] edges_list = False
[PerfCounters] on = True
[PerfCounters] export = False
Is there another file overriding the config file I set above to cause
this?
On Thu, Jun 18, 2015 at 7:38 PM, Richard B. [email protected]
wrote:
on = True #False
[ControlPort] on = True
[ControlPort] edges_list = False
[PerfCounters] on = True
[PerfCounters] export = False
Is there another file overriding the config file I set above to cause this?
v/r,
Rich
Do you have a local config file in ~/.gnuradio/config.conf? Entries in
there will override the system installed settings. See the manual page
here
for details:
That was the first thing I checked. No I don’t have any config file in
there. I’m not sure where it’s picking up these other settings.
I added a local config file to ~/.gnuradio with the same settings and
now
they seem to be picked up correctly. Shrug. I had to install one last
python module, python-graphviz, but it starts up and runs now!
If I leave it on the default view, it seems to run stably. If I switch
to
the ‘Buffer Table->Graph View’ or ‘Run Table->Graph View’, then
Performance
Monitor crashes, sometimes instantly, sometimes after a few seconds,
with
the following error:
ControlPort Monitor running.
monitor::endpoints() = -h rbell -p 57991
running: [‘gr-perf-monitorx’, ‘rbell’, ‘57991’]
Traceback (most recent call last):
File “/usr/local/bin/gr-perf-monitorx”, line 370, in update
if(self.perfTable.isVisible()):
RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted
I just ran a new pull, I don’t see any updates related to
gr-perf-monitorx,
so I think I already have that commit. Here is the pull details just in
case:
On Fri, Jun 19, 2015 at 1:42 PM, Richard B. [email protected]
wrote:
I just ran a new pull, I don’t see any updates related to
gr-perf-monitorx, so I think I already have that commit. Here is the pull
details just in case:
The patch that fixed it for me went in a while ago, just about when we
put
back ControlPort support in April.
If I can duplicate the failure mode, then I might be able to fix it.
Otherwise, there’s no much I can do to debug the problem.
this might be more complicated than it sounds at first, but:
Build GNU Radio with debugging symbols (ie. cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo); install debugging symbols for your
QT build (how to do this depends on your distribution)
run “gdb --args python $(which gr-perf-monitorx)”
“run”
Wait for crash
“bt” (for backtrace) will give you information on who called the
function that tried to access a deleted QTableWidget. That might or
might not be helpful.
Assuming the QTableWidget shouldn’t actually have been deleted:
Running python inside gdb, you might be able to add a breakpoint at the
destructor of QTableWidget; it’s “break functionname”, but I’d have to
look up whether that function would be
QT::GUI::QTableWidget::~QTableWidget or something else.
Then, gdb would interrupt the execution of gr-perf-monitorx the moment
that table widget gets deleted.