|
| From: | samuel verdon |
| Subject: | Re: [Discuss-gnuradio] [USRP-users] Segmentation fault commands toUSRP with gnuradio |
| Date: | Tue, 11 Dec 2018 16:43:12 +0100 |
Hi Marcus, Thank you for your recommendation, but I am not sure to be able to do it. Provenance : Courrier pour Windows 10 De : Müller, Marcus (CEL) Hi Christoph, The ancient lore goes that this was a evaluation-based decision on account of performance. Technically, intrusive_ptr is nice because the object lies right next to the refcounter, so your memory controller can do the linear fetching thing and things should be nice without jumping through wildly different RAM areas. I haven't been able so far to produce a useful performance metric for PMT operations that reflects this, because real-world PMT usage is dominated by the efficiency of the involved operations, not by the smart pointer derefencing. I do, however, really believe this was done with serious evaluation of performance. Anyway, I'd love to change that, but it would be – pun intended – an intrusive API change, and tbh, I'm not sure I want to get all the tests for that change sorted out before 3.8's release. After 3.8, I'd like to get rid of PMT altogether. However, this situation here changes things. Maybe I'll whip up a test branch this weekend where I just go and make the exact change you recommend and test whether it works without further ado. Thanks! Haven't thought about that, and maybe things are really much easier than I was afraid they were. Best regards, Marcus On Fri, 2018-12-07 at 13:00 +0100, Christoph Mayer wrote: > 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 _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio |
| [Prev in Thread] | Current Thread | [Next in Thread] |