Re: [Discuss-gnuradio] Debugging polar code crashes

[Cinaed Simson]

On 07/17/2017 03:20 AM, Marcus Müller wrote:
> 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

Cool! That's how you debug the XML code. I was wondering how to do that
last week.

-- Cinaed

> 
> …
> 
> Trigger hangup by dragging POLAR config onto canvas
> 
> …
> 
> [ctrl-C]
> Thread 1 "python2" received signal SIGINT, Interrupt.
> (gdb) backtrace
> #0  0x77a76fbe in instancemethod_call.lto_priv () at 
> /lib64/libpython2.7.so.1.0
> #1  0x77a2bea3 in PyObject_Call () at /lib64/libpython2.7.so.1.0
> #2  0x77a7d323 in slot_sq_item.lto_priv () at 
> /lib64/libpython2.7.so.1.0
> #3  0x77a47b8f in iter_iternext.lto_priv () at 
> /lib64/libpython2.7.so.1.0
> #4  0x77a2d2de 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 
> 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:
> 
> 
> 
>   POLAR code Configurator
>   variable_polar_code_configurator
>   from gnuradio.fec import polar
>   self.$(id) = $(id) = polar.load_frozen_bits_info(False, $channel, 
> $block_size, $num_info_bits, $design_snr, $mu)
>   polar.load_frozen_bits_info(True, $channel, $block_size, 
> $num_info_bits, $design_snr, $mu)
>   
> 
>   
> Channel
> channel
> polar.CHANNEL_TYPE_BEC
> string
>   
> BEC
> polar.CHANNEL_TYPE_BEC
>   
>   
> AWGN
> polar.CHANNEL_TYPE_AWGN
>   
>   
> 
>   
> Block size (N)
> block_size
> int
>   
> 
>   
> *#Info Bits (K)*
> num_info_bits
> int
>   
> 
>   
> design SNR
> design_snr
> 0.0
> float
>   
> 
>   
> mu
> mu
> 16
> 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Marcus Müller]

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  0x77a76fbe in instancemethod_call.lto_priv () at 
/lib64/libpython2.7.so.1.0
#1  0x77a2bea3 in PyObject_Call () at /lib64/libpython2.7.so.1.0
#2  0x77a7d323 in slot_sq_item.lto_priv () at /lib64/libpython2.7.so.1.0
#3  0x77a47b8f in iter_iternext.lto_priv () at 
/lib64/libpython2.7.so.1.0
#4  0x77a2d2de 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 
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:




  POLAR code Configurator
  variable_polar_code_configurator
  from gnuradio.fec import polar
  self.$(id) = $(id) = polar.load_frozen_bits_info(False, $channel, 
$block_size, $num_info_bits, $design_snr, $mu)
  polar.load_frozen_bits_info(True, $channel, $block_size, $num_info_bits, 
$design_snr, $mu)
  

  
Channel
channel
polar.CHANNEL_TYPE_BEC
string
  
BEC
polar.CHANNEL_TYPE_BEC
  
  
AWGN
polar.CHANNEL_TYPE_AWGN
  
  

  
Block size (N)
block_size
int
  

  
*#Info Bits (K)*
num_info_bits
int
  

  
design SNR
design_snr
0.0
float
  

  
mu
mu
16
int
*#if 'BEC' in $getVar('channel') then 'all' else 'none' #*
  


Hm, that  element looks fishy.
Removed it, tried again, works.

So, you've got a bug in the way your  element is parsed. Maybe 
it's a combination with the (probably cheetah-illegal?) # at the 
beginning of "num_info_bits"'s  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) 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Johannes Demel]

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

(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
> 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
>
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 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Cinaed Simson]

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
 
 (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
> > 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
>> >
>> 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
>> 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Cinaed Simson]

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.

If we're talking about the polar_ber_curve_gen.py, where would I find it?

I can't generate the python code with grcc - grcc just barfs a bunch of
errors.

-- Cinaed

> 
> 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
 
 (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
> > 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
>> >
>> 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
>> 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Johannes Demel]

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

(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
> 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
> 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 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Cinaed Simson]

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
>> 
>> (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
>>> > 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
 > 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 

Re: [Discuss-gnuradio] Debugging polar code crashes

[Alex Homero Rivadeneira Erazo]

Hi Johannes

The GNU radio program turns dark and is unresponsive, and there is not
anything printed on the command line.

Best regards,

Alex



On Thu, Jul 13, 2017 at 3: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
>
>
> 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
>> 
>> (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
>>> > 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
 > 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
> >
> wrote:
>
> Hi Alex,
>
>  

Re: [Discuss-gnuradio] Debugging polar code crashes

[Johannes Demel]

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


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

(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
> 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
> 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
>
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


and there's a link to the official mailing list archive,
too.

I'd recommend deleting your