Yeah I was getting crashes in apps like gqrx. Took a few days to debug. There were some recent changes to logging. Log4cpp is going to be a required dep soon, so might as well install it anyway, but in the interim there is some more commentary on the issue here:
https://github.com/gnuradio/gnuradio/issues/1383 On Sep 1, 2017 7:41 PM, "Mike Rex" <mike....@silver-bullet-tech.com> wrote: > Ron, > > You can take these caps as enthusiastic shouting: THANK YOU, THANK YOU, > THANK YOU. That fixed my issue. I really needed that to enjoy my weekend :) > > Glad you also mentioned needing to rebuild GNU Radio. That really was > necessary. > > Have a really great weekend! > > Thanks, > Mike > > > > On 2017-08-31 8:49 PM, Ron Economos wrote: > >> 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...BCITM >>> ike: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 >> > > > _______________________________________________ > 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
