Hi Johannes,
thanks for this very short and informal bug report on your own software :)
so, a bit of debugging from my side:
gdb --args python2 $(which gnuradio-companion)
(gdb) run
…
Trigger hangup by dragging POLAR config onto canvas
…
[ctrl-C]
Thread 1 "python2" received signal SIGINT, Interrupt.
(gdb) backtrace
#0 0x00007ffff7a76fbe in instancemethod_call.lto_priv () at
/lib64/libpython2.7.so.1.0
#1 0x00007ffff7a2bea3 in PyObject_Call () at /lib64/libpython2.7.so.1.0
#2 0x00007ffff7a7d323 in slot_sq_item.lto_priv () at /lib64/libpython2.7.so.1.0
#3 0x00007ffff7a47b8f in iter_iternext.lto_priv () at
/lib64/libpython2.7.so.1.0
#4 0x00007ffff7a2d2de in PyIter_Next () at /lib64/libpython2.7.so.1.0
…
aha, so that's happening in python-land. Thus, throw python debugging at
this:
(gdb) py-bt
Traceback (most recent call first):
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/core/Param.py",
line 136, in __getitem__
*return str(self._param.get_opt(item)) if self._param.is_enum() else
NotImplemented*
File "cheetah_DynamicallyCompiledCheetahTemplate_1500284883_72_24761.py",
line 85, in respond
File "/usr/lib64/python2.7/site-packages/Cheetah/Template.py", line 1005, in
__str__
rc = getattr(self, mainMethName)()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/core/Block.py",
line 703, in resolve_dependencies
return str(Template(tmpl, n))
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/core/Param.py",
line 338, in get_hide
hide = self.get_parent().resolve_dependencies(self._hide).strip()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/Block.py",
line 211, in create_labels
markups = [param.get_markup() for param in self.get_params() if
param.get_hide() not in ('all', 'part')]
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/Element.py",
line 78, in create_labels
for child in self.get_children():child.create_labels()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/FlowGraph.py",
line 476, in update
self.create_labels()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 113, in flow_graph_update
fg.update()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 358, in _handle_action
flow_graph_update()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/Actions.py",
line 114, in __call__
self.emit('activate')
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/FlowGraph.py",
line 160, in add_new_block
Actions.ELEMENT_CREATE()
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/gui/DrawingArea.py",
line 96, in _handle_drag_data_received
self._flow_graph.add_new_block(selection_data.data, (x, y))
File
"/home/marcus/.usrlocal/lib64/python2.7/site-packages/gnuradio/grc/main.py",
line 54, in main
gtk.main()
File "/home/marcus/.usrlocal/bin/gnuradio-companion", line 92, in run_main
exit(main())
File "/home/marcus/.usrlocal/bin/gnuradio-companion", line 99, in <module>
run_main()
*Emphasis* by me. OK, so it's a ["string"] dereferral problem in Cheetah
calling back into GRC code, most likely (the point in the execution time
where my ctrl-C hits the python process is of course a random variable,
with the event-space being all lines of code executed in that infinite
loop in a "this eats up CPU" situation; but there's an accumulation
point at the things that are called most often, so heh, this "works on
average", or after a few tries. This time, it worked on the first
ctrl-C). So, Cheetah looping over something it parses. Ok, we have a
suspect. Let's look at the block definition XML file:
<?xml version="1.0"?>
<block>
<name>POLAR code Configurator</name>
<key>variable_polar_code_configurator</key>
<import>from gnuradio.fec import polar</import>
<var_make>self.$(id) = $(id) = polar.load_frozen_bits_info(False, $channel,
$block_size, $num_info_bits, $design_snr, $mu)</var_make>
<var_value>polar.load_frozen_bits_info(True, $channel, $block_size, $num_info_bits,
$design_snr, $mu)</var_value>
<make></make>
<param>
<name>Channel</name>
<key>channel</key>
<value>polar.CHANNEL_TYPE_BEC</value>
<type>string</type>
<option>
<name>BEC</name>
<key>polar.CHANNEL_TYPE_BEC</key>
</option>
<option>
<name>AWGN</name>
<key>polar.CHANNEL_TYPE_AWGN</key>
</option>
</param>
<param>
<name>Block size (N)</name>
<key>block_size</key>
<type>int</type>
</param>
<param>
*<name>#Info Bits (K)</name>*
<key>num_info_bits</key>
<type>int</type>
</param>
<param>
<name>design SNR</name>
<key>design_snr</key>
<value>0.0</value>
<type>float</type>
</param>
<param>
<name>mu</name>
<key>mu</key>
<value>16</value>
<type>int</type>
*<hide>#if 'BEC' in $getVar('channel') then 'all' else 'none' #</hide>*
</param>
</block>
Hm, that <hide> element looks fishy.
Removed it, tried again, works.
So, you've got a bug in the way your <hide> element is parsed. Maybe
it's a combination with the (probably cheetah-illegal?) # at the
beginning of "num_info_bits"'s <name> element. Hope that gives you a
direction to look at!
By the way, wouldn't we use small k instead of K and n instead of N for
a (n,k) code?
Cheers,
Marcus
On 07/17/2017 11:03 AM, Johannes Demel wrote:
Hi List,
I created an issue for this on github [0]. I assume the bug manifested
itself due to a change in GRC.
Cheers
Johannes
[0] https://github.com/gnuradio/gnuradio/issues/1385
On 15.07.2017 04:36, Cinaed Simson wrote:
Hi Johannes - I captured the output of grcc for both polar grc files and
they can't find
polar_config
I did a search of the gnuradio tree and my home directory
find . -name polar_config\*
and I couldn't find it either.
-- Cinaed
On 07/14/2017 01:04 AM, Johannes Demel wrote:
Hi,
this is a tricky one. My assumption is, that the configurator block
tries to compute channel capacities with a complex algorithm. There is
also the BEC channel approximation, which should be called.
This whole bug is caused by some GRC changes, as far as I could figure
it out. Could you try to have a look into the python code of the block
configurator and make sure, only the BEC functions are called? This
should fix your GRC problem.
The configurator automates quite a few things regarding channel
construction and has a built-in system for cached channel capacities. I
assume something does not behave as expected here.
Cheers
Johannes
On 14.07.2017 01:47, Cinaed Simson wrote:
On 07/13/2017 12:03 AM, Johannes Demel wrote:
Hi Alex,
could you be more specific about
'When I drop the POLAR code configurator block on the canvas, the
gnuradio program turns down.'?
Does GRC quit with an error? Does it turn dark and is
unresponsive? Is
there anything printed on the commandline?
Cheers
Johannes
Hey, I had that problem too!
In my case, all the tests pass - I have the correct version of GSL
installed - namely 1.16
But I couldn't even load the polar grc files.
When I press open on the grc it hangs - the grc was consuming 100% of
the cpu.
Eventually I had to kill it.
I first noticed it in gnuradio-3.7.10. I'm currently running
gnuradio-3.7.12git and I just checked and the problem is still there.
And I can't generate the python code using grcc - both polar grc
examples generate errors.
-- Cinaed
On 12.07.2017 18:04, Marcus Müller wrote:
Those test failures aren't great, but I think they might be bugs
in the
tests.
So, OK, can't remember what you need to do under Ubuntu to get
the full
Python debugging capability in GDB, but I wrote a (slightly dated,
since
the python commands have improved) tutorial on debugging crashing
Python
applications [1].
The idea is to simply execute your minimal crashing example using
gdb --args python2 /path/to/flowgraph.py
(gdb) run
<wait for crash>
(gdb) backtrace
and figure out why where how things crash. If you got a
backtrace, and
don't immediately see how to proceed (hint: print a few local
variables,
if possible, using gdb's "print" command), share it with the mailing
list
Best regards,
Marcus
[1]https://wiki.gnuradio.org/index.php/TutorialsGDB
On 07/12/2017 05:50 PM, Alex Homero Rivadeneira Erazo wrote:
I am using ubuntu 16.04 LTS.
At the end of the make test, I have obtained some failures:
97% tests passed, 6 tests failed out of 218
Total Test time (real) = 142.49 sec
The following tests FAILED:
48 - qa_ctrlport_probes (Failed)
59 - qa_cpp_py_binding (Failed)
76 - qa_cpp_py_binding_set (Failed)
124 - qa_filterbank (Failed)
154 - qa_ofdm_txrx (Failed)
197 - qa_fading_model (Failed)
Errors while running CTest
Makefile:61: recipe for target 'test' failed
make: *** [test] Error 8
Best regards,
Alex
On Wed, Jul 12, 2017 at 11:46 AM, Marcus Müller
<marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
That might still give us enough debug info. Which Linux
distro are
we talking about (or, is it Linux at all?)
Best regards,
Marcus
On 07/12/2017 05:30 PM, Alex Homero Rivadeneira Erazo wrote:
Hi Marcus
At this moment, I am installing the
gnuradio 3.7.12git-171-get72c77bc from source, which is the
same
that I installed with pybombs . Unfortunately, I just already
built the gnuradio with "make && make test". The gnuradio
that I
had with the standard installation was gnuradio 3.7.9
Thanks
Best regards,
Alex
On Wed, Jul 12, 2017 at 11:13 AM, Marcus Müller
<marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>
wrote:
Hi Alex,
that does indeed sound like a bug. Things shouldn't be
crashing!
So, what's the distribution you're working with? Maybe
I can
help you a bit with the debugging. If you're, at the
moment,
building GNU Radio, make sure that the CMake parameters
contain -DCMAKE_BUILD_TYPE=RelWithDebInfo , so that we get
debugging symbols :)
Best regards,
Marcus
On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo
wrote:
Hi Marcus
Based on your suggestion I have deleted my Nabbles
account.
Respect to my problem with the POLAR code
configurator block, I checked the discussion threads, but
anyone gave a solution.
Note that this problem does not happen with
a gnuradio installed with the distribution's package
manager
(standard installation). However, the problem with this
installation method is that gnuradio is not up to date
and
it does not have all the blocks that I need in my
work. That
is why I used pybombs to install gnuradio which has the
blocks that I need. Now the problem is that gnuradio with
pybombs does work with the POLAR code configurator block.
When I drop the POLAR code configurator block on the
canvas,
the gnuradio program turns down.
At this moment, I am installing gnuradio from source.
If you
have other ideas please tell me.
Thanks
Best regards,
Alex
On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller
<marcus.muel...@ettus.com
<mailto:marcus.muel...@ettus.com>>
wrote:
Hi Alex,
I hope you do get an answer, but that mail from
Jose is
from the
beginning of 2016 – not extremely likely.
Anyway, have you seen the other answers that Jose
got?
If not: That's Nabble's fault. I never tire to
repeat:
Nabble is just a terrible, terrible web frontend
to use
the official GNU
Radio Mailing list.
It's not the official mailing list archive. It never
was, and it never
will be. The official way to sign up for the mailing
list is
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
and there's a link to the official mailing list
archive,
too.
I'd recommend deleting your Nabble account, and
directly
signing up
under the above address with your email account. It's
really easier to
use a proper email client (eg. GMail's web
frontend) and
simply the
mails than Nabble. Nabble breaks discussion
threads, it
makes answers
invisible, and it has cost us hours and hours of
unnecessary work so
far. PLEASE, don't use Nabble.
Best regards,
Marcus
On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
> Dear Jose
>
> Can you tell me if you solved the problem with the
POLAR code configurator
> block? because I have the same problem in the
gnuradio
installed with
> pybombs.
>
> Thanks
>
> Alex
>
>
>
> --
> View this message in context:
http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html
<http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html>
> Sent from the GnuRadio mailing list archive at
Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
--
Regards,
Alex Homero Rivadeneira E.
Cell: 438 397-8330 <tel:%28438%29%20397-8330>
--
Regards,
Alex Homero Rivadeneira E.
Cell: 438 397-8330 <tel:%28438%29%20397-8330>
--
Regards,
Alex Homero Rivadeneira E.
Cell: 438 397-8330
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
