Re: [Discuss-gnuradio] [USRP-users] Segmentation fault commands to USRP with gnuradio

[Christoph Mayer]

Hi Marcus,

what is the reason for having
  typedef boost::intrusive_ptr<pmt_base> pmt_t;
and not using a shared_ptr?

As far as I understand, if a shared_ptr instead of
boost::intrusive_ptr were used, one could use either the method
described here:
https://www.boost.org/doc/libs/1_68_0/libs/smart_ptr/doc/html/smart_ptr.html#techniques_static
or use the aliasing constructor of a shared_ptr (probably better).

Best regards
Christoph

On Fri, Dec 7, 2018 at 11:32 AM Müller, Marcus (CEL) <address@hidden> wrote:
>
> By the way, I think the reason this goes wrong is that a) I've managed
> to run into the Static Initialization Order Fiasco, destructor edition,
> and b) that can't be solved with pmt_t, as pmt_t is actually a typedef
> for smart_pointer<actual_type>, and the moment the statically generated
> object (the smart pointer) leaves scope of the consuming function the
> first time, its destructor is being called.
>
> So, yay, if that assessment is correct, by putting PMT keys into the
> members of class instances, I've only postponed the problem you're
> seeing now to the destruction of blocks, and since that typically
> doesn't happen until the end of programs, it doesn't "hurt" anyone.
>
> It's still wrong, and would lead to unpredictable behaviour in case
> someone cleans up blocks at runtime. Which they should be able to do.
>
> Soooo argh. No simple solution here. Anyone a great idea?
>
> Best regards,
> Marcus
> On Fri, 2018-12-07 at 10:21 +0000, Müller, Marcus (CEL) wrote:
> > Hi Samuel,
> >
> > so, my guess is that once again, we're running into the C++-specific
> > static initialization order fiasco (SIOF, yes, it's a term) for the PMT
> > keys used in the dicts.
> >
> > Solution: I've extracted functions to return these keys and statically
> > initialize them but once, because PMT's pmt_symbol creation is
> > relatively CPU-intense, and shouldn't be done at run time.
> >
> > Somehow, it seems, that can sometimes lead to different notions of the
> > same symbol.
> >
> > Solution: I was going to go in there, and instead of having these
> > functions that all look like
> >
> > const pmt::pmt_t gr::uhd::cmd_time_key()
> > {
> >   static const pmt::pmt_t val
> > = pmt::mp("time");
> >   return val;
> > }
> >
> > just go in there, and give each instance of a usrp_block its own const
> > fields of the same name, and initialize them in block constructor
> > initialization list; that's what I did for the rest of GR, and I hope
> > it works there.
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
> > > Hi Marcus and Martin,
> > > Thank you for your help!
> > > Do you now how I can follow the problem?
> > > Or if is it already solved, how can I fix it?
> > >
> > > Thanks a lot!
> > >
> > > Samuel
> > >
> > >
> > > De : Marcus Müller
> > > Envoyé le :Wednesday, December 5, 2018 13:50
> > > À : address@hidden; samuel verdon
> > > Cc : Martin Braun
> > > Objet :Re: [USRP-users] Segmentation fault commands to USRP with gnuradio
> > >
> > > <ugly expletive>
> > > this looks like my fault. Not feeling well enough to fix now, but wait
> > > a day and I'll have something to test.
> > > On Wed, 2018-12-05 at 12:56 +0100, Marcus Müller wrote:
> > > > Hi Samuel,
> > > >
> > > > cool! That's really helpful :)
> > > >
> > > > I'm now cross-posting this to discuss-gr, because it's a GNU Radio-
> > > > land
> > > > issue. The maintainers of gr-uhd are active over there, too, so this
> > > > seems the smarter place to continue discussion.
> > > >
> > > >
> > > > so, in medias res:
> > > >
> > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
> > > > > #3  0x00007f7f15906700 in pmt::dict_has_key (dict=..., key=...) at
> > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
> > > >
> > > > möp möööp. Our favorite (only) variadic type library leads to
> > > > segfaults.
> > > >
> > > > I'll look into that and be back in a while.
> > > >
> > > > Best regards,
> > > > Marcus
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio