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) <[email protected]> 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 > > > À : [email protected]; 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 > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > > 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
