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