Jacob, This is a gr-uhd issue (not UHD) if it is what I think it is, so the uhd version is probably immaterial. Which gnu radio version are you running?
M On 25 Mar 2016 07:53, "Jacob Gilbert" <[email protected]> wrote: > I have tried it two ways: > > 1) calling stop() wait() on the top_block > 2) having a block return WORK_DONE to the scheduler to stop the flowgraph > > Both ways result in segfaults. I'll try calling stop() on the USRP block > directly. I am currently running the 3.9.2 release but will update when I > get a chance. > > Thanks > > On Thu, Mar 24, 2016 at 10:34 PM, Martin Braun <[email protected]> > wrote: > >> Oh, I see -- you're calling stop() on the top_block, or the usrp block? >> I know we fixed a segfault issue in >> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f (the praise goes to Marcus >> Müller for the fix), but this is not on maint, only on master. What are >> you running? >> >> Cheers, >> Martin >> >> On 03/24/2016 05:25 PM, Jacob Gilbert wrote: >> > Sorry for not being explicit, I am doing this using GR (stock gr-uhd). >> > >> > Jacob >> > >> > On Thu, Mar 24, 2016 at 5:22 PM, Martin Braun via USRP-users >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > Jacob, >> > >> > are you using GNU Radio or straight UHD? Your email seems to imply >> the >> > former, but I want to confirm. >> > >> > Your backtrace looks familiar; in benchmark_rate we used to >> sometimes >> > run into cases where we'd segfault and then they might look like >> this. >> > The reason was we were shutting down stuff out of order. >> > >> > If you have your custom app, make sure the streamer is stopped, then >> > flushed, then destroyed before the multi_usrp object is destroyed. >> > If you don't do that, the recv thread might be trying to access >> samples >> > for which there are no more valid buffers. The converter would be >> the >> > first to see this => matches your bt. >> > >> > Cheers, >> > Martin >> > >> > >> > On 03/24/2016 06:54 AM, Jacob Gilbert via USRP-users wrote: >> > > I have a flowgraph that requires stopping and starting to >> reconfigure >> > > its output, and have run into two different segfaults originating >> from >> > > within UHD. >> > > >> > > Starting and stopping is done based on user input and by either >> > issuing >> > > the stop() wait() sequence, or by having a block return >> "WORK_DONE" >> > > (-1). Both have been shown to produce both types of segfault, >> however >> > > the WORK_DONE method anecdotally appears to be less frequent. The >> > errors >> > > always occur while waiting for the wait() function to return and >> > > occasionally hang for an extremely long time before actually >> throwing >> > > sigsev. >> > > >> > > BT's of the segfaults are here: >> > > >> > > ------------ >> > > >> > > Program received signal SIGSEGV, Segmentation fault. >> > > [Switching to Thread 0x7f8704fe9700 (LWP 103995)] >> > > 0x00007f87b25589d0 in >> > > >> > >> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned >> > > long) () from /usr/local/lib/libuhd.so.003 >> > > (gdb) i trace >> > > No tracepoints. >> > > (gdb) bt >> > > #0 0x00007f87b25589d0 in >> > > >> > >> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned >> > > long) () from /usr/local/lib/libuhd.so.003 >> > > #1 0x00007f87b26e8433 in >> > task_impl::task_loop(boost::function<void ()> >> > > const&) () >> > > from /usr/local/lib/libuhd.so.003 >> > > #2 0x00007f87be684e7a in ?? () from >> > > /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0 >> > > #3 0x00007f87d2831182 in start_thread (arg=0x7f8704fe9700) at >> > > pthread_create.c:312 >> > > #4 0x00007f87d255e47d in clone () at >> > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >> > > >> > > ------------ >> > > >> > > Program received signal SIGSEGV, Segmentation fault. >> > > [Switching to Thread 0x7fce1cff9700 (LWP 112591)] >> > > 0x00007fcebb8e0b83 in >> > > >> > >> >> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void >> > > const*> const&, uhd::ref_vector<void*> const&, unsigned long) () >> from >> > > /usr/local/lib/libuhd.so.003 >> > > (gdb) bt >> > > #0 0x00007fcebb8e0b83 in >> > > >> > >> >> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void >> > > const*> const&, uhd::ref_vector<void*> const&, unsigned long) () >> from >> > > /usr/local/lib/libuhd.so.003 >> > > #1 0x00007fcebbb33ad9 in >> > > >> > >> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned >> > > long) () from /usr/local/lib/libuhd.so.003 >> > > #2 0x00007fcebbcc3433 in >> > task_impl::task_loop(boost::function<void ()> >> > > const&) >> > > () from /usr/local/lib/libuhd.so.003 >> > > #3 0x00007fcec7c5fe7a in ?? () >> > > from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0 >> > > #4 0x00007fcedbe0c182 in start_thread (arg=0x7fce1cff9700) >> > > at pthread_create.c:312 >> > > #5 0x00007fcedbb3947d in clone () >> > > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >> > > (gdb) >> > > >> > > ------------ >> > > >> > > System Details: >> > > OS: Ubuntu 14.04-3 >> > > UHD 3.9.2 >> > > GNU Radio: 3.7.9.1 >> > > >> > > Thanks, >> > > Jacob >> > > >> > > >> > > >> > > _______________________________________________ >> > > USRP-users mailing list >> > > [email protected] <mailto:[email protected]> >> > > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > >> > >> > >> > _______________________________________________ >> > USRP-users mailing list >> > [email protected] <mailto:[email protected]> >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > >> > >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
