I observed this on GR 3.7.9.1. On Fri, Mar 25, 2016 at 10:10 AM, Martin Braun <martin.br...@ettus.com> wrote:
> 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" <mrjacobagilb...@gmail.com> 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 <martin.br...@ettus.com> >> 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 >>> > <usrp-us...@lists.ettus.com <mailto:usrp-us...@lists.ettus.com>> >>> 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 >>> > > usrp-us...@lists.ettus.com <mailto:usrp-us...@lists.ettus.com> >>> > > >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> > > >>> > >>> > >>> > _______________________________________________ >>> > USRP-users mailing list >>> > usrp-us...@lists.ettus.com <mailto:usrp-us...@lists.ettus.com> >>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> > >>> > >>> >>> >>> _______________________________________________ >>> 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
