discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] app crashes with ctrlport enabled. Works fine wit


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] app crashes with ctrlport enabled. Works fine with ctrlport disabled.
Date: Fri, 16 Oct 2015 17:04:16 -0400

On Fri, Oct 16, 2015 at 4:33 PM, Achilleas Anastasopoulos <address@hidden> wrote:
I have installed ctrlport and playing around with it.

What a great piece of work! thanks guys!


Thanks!

 
I am running an application (cdma_txrx from my gr-cdma module)
and I notice that with ctrport enabled it crashes, while without it works perfectly.

With ctrport I get the following message that hints at what may be going wrong:

gr::log :INFO: controlport - Apache Thrift: -h jefe.eecs.umich.edu -p 59556
gr::log :WARN: flat_flowgraph - Block (chopper0) max output buffer set to 6656 instead of requested 8192
Traceback (most recent call last):
  File "/home/anastas/gr-cdma/apps/cdma_txrx.py", line 587, in <module>
    main()
  File "/home/anastas/gr-cdma/apps/cdma_txrx.py", line 582, in main
    tb.Start(True)
  File "/usr/local/lib64/python2.7/site-packages/grc_gnuradio/wxgui/top_block_gui.py", line 74, in Start
    self.start()
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/top_block.py", line 109, in start
    top_block_start_unlocked(self._impl, max_noutput_items)
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 5611, in top_block_start_unlocked
    return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: block lookup failed! block not found!
Exception in thread Thread-1 (most likely raised during interpreter shutdown):Exception in thread Thread-2 (most likely raised during interpreter shutdown):


Ugh, that's ugly. When a block is put into the flowgraph, it gets registered with the global_block_registry that will map from the block's alias to the actual pointer. This is done to have pointers to block objects managed internally by the system and user-level code never talks directly to them but only through the alias. This is supposed to be safer!

It looks like something is getting registered or at least ControlPort thinks that a block's alias exists in the flowgraph, but when it tries to actually look it up in the block registry, it's not there.

Hopefully this gives you enough of a clue where to look next.

 
when i run it without contrlport i still get the warning

gr::log :WARN: flat_flowgraph - Block (chopper0) max output buffer set to 6656 instead of requested 8192

but the application runs fine.

Can someone suggest what the problem may be, and how to get around it?

thanks
Achilleas

We'd have to look closer at that warning and how you're setting the block up. That's strange that it'd force it to 6656 instead of a nice power of two -- unless that warning message is backwards?
 
Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]