Re: [Discuss-gnuradio] [USRP-users] Segmentation Fault from uhd::transport when stopping/starting flowgraph

[Martin Braun]

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" <address@hidden> 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 <address@hidden> 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

> <address@hidden <mailto:address@hidden>> 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

>     > address@hidden <mailto:address@hidden>
>     > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     >
>
>
>     _______________________________________________
>     USRP-users mailing list
>     address@hidden <mailto:address@hidden>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio