Hi Jessica, that's really interesting!
It means that the problem only happens when you use your compiler to build your C++ blocks, but not when only using the GNU Radio that's already part of your image. Not quite sure what that entails; maybe it means that openembedded builds broken SDKs... That shouldn't happen. The other thing I could think of would be a slight misconfiguration of the compiler (or the linker). Maybe Philip has an idea! Best regards, Marcus On 24.05.2017 20:51, Jessica Iwamoto wrote: > > Hi all, > > > > I never found the solution to this problem, but I ended up using a > work around by writing my custom blocks in Python instead of C++. > > > > Jessica > > > > *From:*Discuss-gnuradio > [mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero....@gnu.org] *On > Behalf Of *Jessica Iwamoto > *Sent:* Monday, May 15, 2017 8:38 AM > *To:* Ben Hilburn <bhilb...@gnuradio.org> > *Cc:* discuss-gnuradio@gnu.org > *Subject:* [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: > [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hi Ben, > > > > Here is some of the backtrace from the error. At the top level, the > error starts in the msg_connect function and it looks like it gets > tripped up reading something from memory when checking for a valid > message port. > > > > #0 0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1, > > storage=@0x6: <error reading variable>) > > at /home /prefix > /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100 > > #1 fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6) > > at /home /prefix > /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115 > > #2 pmt::intrusive_ptr_add_ref (p=0x2) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69 > > #3 0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c) > > at /home /prefix > /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92 > > #4 gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162 > > #5 0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578, > src=..., > > dst=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503 > > #6 0xb63f4c84 in gr::hier_block2_detail::msg_connect ( > > this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...) > > at /home /prefix > /src/gnuradio/gnuradio-runtime/lib/hier_block2_detail.cc:198 > > #7 0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0, > src=..., > > srcport=..., dst=..., dstport=...) > > at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104 > > #8 0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 ( > > args=<optimized out>) > > at /home > /prefix_new/src/gnuradio/build-arm/gnuradio-runtime/swig/runtime_swigPYTHON_wrap.cxx:47551 > > > > Thanks, > > Jessica > > > > *From:*Ben Hilburn [mailto:bhilb...@gnuradio.org] > *Sent:* Friday, May 12, 2017 1:35 PM > *To:* Jessica Iwamoto <jessica.iwam...@aero.org > <mailto:jessica.iwam...@aero.org>> > *Cc:* discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> > *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hey Jessica - > > > > The SIGBUS you are receiving indicates that there is likely some > funniness happening with memory addressing / access somewhere. > Especially since your test flowgraph is so simple, using GDB to get a > backtrace might point you to the offending code pretty quickly. For > more details on how to do this, check out this page on our > Wiki: > https://wiki.gnuradio.org/index.php/TutorialsDebugging#Expert_debugging_tools > > > > Have you tried this already? If so, can you share the backtrace? > > > > Cheers, > > Ben > > > > > > > > On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto > <jessica.iwam...@aero.org <mailto:jessica.iwam...@aero.org>> wrote: > > Hi again, > > > > Attached is the code that I’m using if anyone would like to try to > replicate my issue. The test_msg_py.py file contains the custom > python block code for a simple message sink. The test_msg_impl.cc, > test_msg_impl.h, and test_msg.h files contain the custom C++ code > for a message sink. The test.py file contains a simple flowgraph > that connects a message strobe to my custom message sink blocks. > When I run test.py with either of the blocks on my desktop, it > works correctly. However, when I run test.py after cross compiling > on the E310, it works correctly with the test_msg_py block and > produces the following error with the test_msg block: > > Could not find port: in in: > > system > > Bus error > > > > Thanks, > > Jessica > > > > *From:* Discuss-gnuradio > [mailto:discuss-gnuradio-bounces+jessica.iwamoto > <mailto:discuss-gnuradio-bounces%2Bjessica.iwamoto>=aero....@gnu.org > <mailto:aero....@gnu.org>] *On Behalf Of *Jessica Iwamoto > *Sent:* Wednesday, May 10, 2017 9:53 AM > *To:* discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> > *Subject:* [Discuss-gnuradio] Custom C++ blocks on E310 > > > > Hi all, > > > > I have built custom C++ blocks that work on my PC, but don’t work > when cross compiled for the E310. Specifically, I am trying to > build a custom C++ block with a message port and cross compile it > for the E310. I am using version 3.7.12 of GNU radio and the > latest version of the SDK/toolchain for the E310. I have built a > simple message sink block with just a message input port and put > it in a flowgraph with a message strobe. My code runs correctly on > my PC but when I run it on the E310, I get the error: > > Could not find port: msg in: > > system > > Bus error > > > > I am able to create custom python blocks with message ports and > run them on the E310 and my PC with no issues. Additionally, I am > unable to create custom C++ blocks with normal input and output > streams on the E310 (the program seg faults when I try to connect > the custom block to another block), but they run correctly on my > PC. Any suggestions on what could be causing this? > > > > Thanks, > > Jessica > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto: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
