Control Ports On/Off and Config file

I set my gnuradio configuration file (located here:
/usr/local/etc/gnuradio/conf.d/gnuradio-runtime.conf) to the following:

[PerfCounters]
on = True #False
export = True #False
clock = thread
#clock = monotonic

[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?

v/r,
Rich

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:

http://gnuradio.org/doc/doxygen/page_prefs.html

Tom

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

Have I overlooked something?

Rich

On Fri, Jun 19, 2015 at 12:58 PM, Richard B. [email protected]
wrote:

the following error:
Have I overlooked something?

Rich

Darn, I thought that I fixed that bug here:

https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3

Tom

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:

[email protected]:~/Documents/gnuradio$ git pull origin master
remote: Counting objects: 32, done.
remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10
Unpacking objects: 100% (32/32), done.
From https://github.com/gnuradio/gnuradio

  • branch master -> FETCH_HEAD
    7b684a2…28f69a5 master -> origin/master
    Updating 7b684a2…28f69a5
    Fast-forward
    CMakeLists.txt | 35 ++++++±-----
    …/include/gnuradio/thrift_application_base.h | 4 ±
    gnuradio-runtime/lib/CMakeLists.txt | 7 +±
    gr-digital/grc/digital_constellation.xml | 21 ++++±–
    gr-digital/grc/digital_constellation_rect.xml | 60
    ++++++++++++±--------
    grc/python/Generator.py | 2 ±
    6 files changed, 75 insertions(+), 54 deletions(-)
    [email protected]:~/Documents/gnuradio$

Is there anyway I can help you figure out the cause of the crash?

Rich

Is there a way I can give you feedback from my crash that will help you
figure out the cause? If so, I’m happy to do it.

Rich

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.

Tom

Hi Rich,

this might be more complicated than it sounds at first, but:

  1. 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)
  2. run “gdb --args python $(which gr-perf-monitorx)”
  3. “run”
  4. Wait for crash
  5. “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.

For a bit of background:
https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs