I've been having troubles with the master branch lately myself. I've
traced it to having liblog4cpp5 installed or not. If liblog4cpp5 is NOT
installed, GNU Radio seems oddly unstable, especially for OOT modules.
Note that build-gnuradio does NOT install liblog4cpp5.
Try installing liblog4cpp5-dev (sudo apt-get install liblog4cpp5-dev)
and rebuilding GNU Radio.
Ron
On 08/31/2017 08:17 PM, Mike Rex wrote:
> gnuradio version: 3.7.12git-218-g811bee8c installed from
> build-gnuradio script.
> Dev PC: Xubuntu 16.04 running in VM Workstation (mentioned because
> some python bugs are hypervisor effected only)
> Problem: I am getting errors when running flow graphs in GRC after
> adding variables to the udp_sink_impl.h file.
>
> I've been struggling all week making changes to an existing project
> (https://github.com/ghostop14/gr-grnet) that are alternate versions of
> TCP/UDP sink/source. I planned on starting with this project, adding
> in some missing bits from the gr-blocks UDP sink/source, and then
> finally modifying it for our particular application (raw protocol
> instead of UDP with IP).
>
> I'm having problems adding variables to
> udp_sink_impl.h/udp_source_impl.h without getting errors when running
> the flow graph. I may be overlooking something simple, but I'm really
> just trying to append the new variable following the usage of other
> existing variables. I think there is either something wrong with my
> python 2.7 on my xubuntu 16.04 PC, or there needs to be additional
> memory allocated somewhere. Typically, when adding a new variable to
> udp_sink_impl.h, I'll get the following, where the "NUM needed" varies
> from run to run:
>
> Traceback (most recent call last):
> File "/home/mike/top_block.py", line 110, in <module>
> main()
> File "/home/mike/top_block.py", line 99, in main
> tb.start()
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 5681, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
> RuntimeError: udp_sink(1): insufficient connected output ports
> (54929632 needed, 0 connected)
>
>
> Other times, the flowgraph will start and then crash after the
> private constructor finishes and the error will be related to python2
> and corrupted size vs prev_size...
>
> *** Error in `/usr/bin/python2': corrupted size vs. prev_size:
> 0x0000000003428620 ***
>
> Comment out the variable, and then it runs every time. Geez, while
> writing this email, I restored the variable to get the corrupted size
> error. Pressed Play again and it ran. Sometimes 2/3 tries works, and
> other times 2/3 tries gets the python error (I did not notice that
> behavior until just now). Added another variable, and then it went up
> to like 1 in 6 worked or 1 in 10 worked, and with another variable
> added, it doesn't ever work again. So this looks like a memory
> allocation/corruption problem that somehow randomly works.
>
> When testing block changes, what is the correct process to ensure
> gnuradio sees the newest installed code only? I've been doing:
>
> (current dir is build)
> sudo make uninstall && sudo ldconfig && cd .. && rm -rf build
> mkdir build
> cd build
> cmake -DCMAKE_BUILD_TYPE="Debug" ../
> make -j8 && sudo make install && sudo ldconfig
>
> Is there something I'm missing that completely removes old stuff or
> failing to import all the new stuff?
>
> I do have another local repo where I have many more changes and the
> payload_size is working (don't know what changed when it suddenly
> started working), but further adding variables like 'eof' result in
> the error in question. The simplest changes I can make and reproduce
> this can be seen here:
> https://github.com/ghostop14/gr-grnet/compare/master...BCITMike:master.
> I'm changing 4 files:
> modified: grc/grnet_udp_sink.xml
> modified: include/grnet/udp_sink.h
> modified: lib/udp_sink_impl.cc
> modified: lib/udp_sink_impl.h
>
> So either I'm missing something fundamental or my dev setup is bad.
> If someone can point out what I'm missing to make this work, I would
> greatly appreciate it!
>
> Thanks!
> Mike
>
>
> _______________________________________________
> 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
No comments:
Post a Comment