|
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
<address@hidden
<mailto:address@hidden>> 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
<address@hidden
<mailto:address@hidden>>
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
<address@hidden
<mailto:address@hidden>>
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
> address@hidden
<mailto:address@hidden>
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
<mailto:address@hidden>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|