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

[CEL]

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