December 2016 - Boost - lists.boost.org

Re: [boost] Boost 1.63.0 Release Candidate 2
by Stephan T. Lavavej 24 Dec '16

24 Dec '16

[Marshall Clow] > The second release candidate for the 1.63.0 release is now available at: > https://sourceforge.net/projects/boost/files/boost/1.63.0/ > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. 1.63.0 RC2 successfully built for mingw-w64, without any workarounds. (Boost.Fiber is detecting my lack of std::mutex and simply not building, which is fine by me.) Notably, this is the first time that I've ever been able to build Boost without patches or workarounds. This is after bootstrap.sh was fixed for mingw-w64/msys2, Context/Coroutine/Coroutine2 were fixed to build for mingw-w64, and Python auto-detection started working again. Yay! Thanks, STL

2 1

Stacktrace review: concern, probable solution and review news
by Antony Polukhin 24 Dec '16

24 Dec '16

Hi, The biggest concern with the stacktrace library is it's usability in async-signal-handlers. Here are some facts: * users definitely want to use the library in async-signal-handlers to print stacktraces on SIGSEGV/SIGBUS/SIGABRT * the only cross-platform async-signal-safe thing that can be done - is to print function addresses (without names and source line locations) * reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations). So, the solution: * Change `basic_stacktrace<size_t>` to `basic_stacktrace<class Allocator = std::allocator<void*>>` and make it's constructor async-unsafe and add additional runtime parameter for stack depth. * Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)` * Provide an example with dumping callstack to a file and printing it on program restart Does it seem reasonable? Does it satisfy your needs? Review news: * User named LogicalKnight tested the library on MacOS and it works well. A few issues in examples must be fixed: https://github.com/apolukhin/stacktrace/issues/10 My list of TODOs for the library: * Fix the async unsafe code in signal catching example * ? Provide a low-level API for getting stacktrace as array of void pointers * MinGW fails to compile, because of missing "Dbgeng.h" headers. This must be fixed by manyally forward declaring required functions using the boost.winapi way. * Add a note about the Boost.Exception usage to the example with embedding stack into exception. * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution * ? Deserialization/inspection of stacktrace on other machine * BOOST_NOINLINE inline trick to avoid printing internals in the stacktrace + fix Intel warnings * At github one of the users was complaining about the performance of ostreaming operations. There is a way to significantly speedup ostreaming without changing the interface of the library. I'll do the optimization after the Boost Review. * Improve docs for the "Build, Macros and Backends" sections (say that library is using system headers, no 3rd party libraries must be installed or manually linked; backtrace() is LINUX specific, not POSIX) * Add a note to the docs that library is header only by default and usable in C++98/C++03. Things NOT to do ever: * Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those ideas are out of the library scope * Callbacks to do things on stacktraces - no way to satisfy all the needs and make them optimal on all the platforms. Do some caching instead -- Best regards, Antony Polukhin

5 11

Re: [boost] [Stacktrace] review
by Barrett Adair 23 Dec '16

23 Dec '16

On Wed, Dec 14, 2016 at 2:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > The formal review of the Stacktrace library by Antony Polukhin starts > today 14th Dec and will conclude before Christmas. I appreciate we > are likely a bit tired out from the many library reviews recently and > of course it's Christmas, but given the lack of a portable way to > work with stack backtraces, which you inevitably need to do > eventually in any non-toy production application, Stacktrace needs > your review! > > For your review you may wish to consider the following questions: > > What is your evaluation of the design? I like it. > What is your evaluation of the implementation? I've never implemented a stacktrace reader, so I don't have much to add. The code did not raise any red flags for me, though. > What is your evaluation of the documentation? Documentation is solid. > What is your evaluation of the potential usefulness of the library? Very useful. I will likely use this at work. > Did you try to use the library? With what compiler? Did you have any problems? Yes, GCC 5.3, no problems. This stacktrace made me smile: 0# boost::stacktrace::detail::backend::backend(void**, unsigned long) 1# s::~s() 2# void __gnu_cxx::new_allocator<s>::destroy<s>(s*) 3# void std::allocator_traits<std::allocator<s> >::destroy<s>(std::allocator<s>&, s*) 4# std::_Sp_counted_ptr_inplace<s, std::allocator<s>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() 5# std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 6# std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() 7# std::__shared_ptr<s, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() 8# std::shared_ptr<s>::~shared_ptr() 9# hello()::{lambda()#1}::~hello() 10# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) 11# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Function_base::_Base_manager<hello()::{lambda()#1}> const&, std::_Manager_operation) 12# std::_Function_base::~_Function_base() 13# std::function<void ()>::~function() 14# void std::_Destroy<std::function<void ()> >(std::function<void ()>*) 15# void std::_Destroy_aux<false>::__destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 16# void std::_Destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 17# void std::_Destroy<std::function<void ()>*, std::function<void ()> >(std::function<void ()>*, std::function<void ()>*, std::allocator<std::function<void ()> >&) 18# std::vector<std::function<void ()>, std::allocator<std::function<void ()> > >::~vector() 19# hello() 20# main 21# __libc_start_main 22# _start > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 45 minutes total. I skimmed the code, the documentation, and the test cases. Then, I made a little test program. > Are you knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes, unequivocally. The concerns about async safety are interesting, but ultimately this library is useful to me (and likely many others) regardless of signal support. Barrett

1 0

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Remi Chateauneu 22 Dec '16

22 Dec '16

Maybe the RDTSC instruction might help for x86 processors, as it returns a number of ticks which is reset at startup. It is also extremely fast. Le 22 déc. 2016 13:04, "Thomas Dahms" <thomas.dahms(a)native-instruments.de> a écrit : Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 1

[interprocess] Getting boot-up time is unreliable on Windows
by Thomas Dahms 22 Dec '16

22 Dec '16

Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com

1 0

Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

The release candidates for the 1.63.0 release are now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The SHA256 checksums are as follows: 010699561c6011e6d97dc453d55bc5e54cdc192622434eff7b8ac559efac846c boost_1_63_0_rc1.7z d8ebf8d90b2f823f04119445ac339d704395d655907333ec0fab863040119d24 boost_1_63_0_rc1.tar.bz2 dabe29b8a60369ae7c15c20681a32717f3c37d97e5dc6d39c5b2fd0494b8e995 boost_1_63_0_rc1.tar.gz 1683942022fd63c205c48fb2155af6094c67ef67aa13ffb3e1db78fecf817efe boost_1_63_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

12 25

Please update Track config
by Antony Polukhin 21 Dec '16

21 Dec '16

Hi, Please, change the default owner for variant issues from ebf to apolukhin (it's me, I'm taking care of the library for last few years). This change will help me to react faster on variant issues. Also, please add the dll component into the list of components so that people could properly report Boost.DLL issues https://github.com/boostorg/dll. Make me (apolukhin) the default responsible for the issues. Thanks in advance! -- Best regards, Antony Polukhin

1 0

Re: [boost] [Boost] [Stacktrace] review
by Nat Goodspeed 21 Dec '16

21 Dec '16

On Wed, Dec 14, 2016 at 3:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > I'm generally pleased with the design. There's a documentation section "Exceptions with stacktrace" that discusses techniques for incorporating stacktrace data into your own exceptions. I see a real possibility for integration with Boost.Exception, perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the stacktrace at the throw point. This is not an objection to accepting the library, but rather a feature request for when we do. I do have a question about use of a template parameter to constrain the number of entries, rather than a runtime parameter. Presumably that's necessary to permit certain backend implementations to be async-signal-safe? (Whatever the rationale, a note in the documentation explaining it would be nice.) My objection to that is that apparently, with the present design, if I want to write a function that accepts any specialization of basic_stacktrace, that must itself be a template function. If I'm correct about the reason for using a template parameter, would it be reasonable to split the class into a non-template base class supporting all the methods, with a template subclass that provides the storage? The base class could store a (pointer, length) passed by the subclass constructor. Without having looked at the implementation, I expect that you wouldn't even need virtual-function dispatch: the only indirection would be through the data buffer pointer. That would even permit a subclass that provides dynamic storage, for async-signal-unsafe use. Then a processing function could accept reference-to-base-class and handle any stacktrace instance. > - What is your evaluation of the implementation? Sorry, I haven't looked at the implementation. > - What is your evaluation of the documentation? > Generally good. It could stand a cleanup pass; there are a few typos here and there. I do like that each method explicitly states both complexity and async signal safety. The description of the nullary frame() constructor says that source_line() will return both empty string and 0. > - What is your evaluation of the potential usefulness of the > library? > VERY! I want this. > - Did you try to use the library? With what compiler? Did you > have any problems? > No, I haven't tried to use it. (A deadline is coming up fast.) > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I read through the documentation. > - Are you knowledgeable about the problem domain? > I have occasionally used platform-specific tactics to try to achieve the same thing, on a couple different platforms. Each time it's been painful enough to make me wish that this problem were solved, once and for all. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost > library? > Yes I do. I would like to see the non-template base class, but that's not a showstopper: I would rather have this library without than not have it at all. As I mentioned, I would like to see integration with Boost.Exception. That just seems like a natural next step. I see further opportunities for integration with Boost.Context, Boost.Fiber...

11 121

Stacktrace library starts review today 14th Dec
by Niall Douglas 21 Dec '16

21 Dec '16

The formal review of the Stacktrace library by Antony Polukhin starts today 14th Dec and will conclude before Christmas. I appreciate we are likely a bit tired out from the many library reviews recently and of course it's Christmas, but given the lack of a portable way to work with stack backtraces, which you inevitably need to do eventually in any non-toy production application, Stacktrace needs your review! Stacktrace is an optionally header-only library providing four implementation backends, libunwind (POSIX only), windbg (Windows only), backtrace (from the C library on most POSIX implementations) and a null backend. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? Most of my personal concerns with this library are with the implementation and I would hugely appreciate feedback from others with substantial experience of using stacktracing "in anger" in non-trivial use case scenarios. - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Finally, thanks to Edward whose announcement of the Synapse library review I borrowed heavily from as I thought it very well structured. Hopefully the above is just as clear. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 21

Re: [boost] [EXTERNAL] Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016 at 2:51 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:49 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: > >> >> >>>>>> >> >>>>>> As I mentioned to Marshall, the results here: >> >>>>> http://www.boost.org/development/tests/develop/developer/ >> config.html >> >>>>> are >> >>>>> horribly outdated - are they actually being run and updated? >> >>>>> >> >>>>> >> >>>> It appears that all 'develop' tests are at least one week late if not >> >>>> much >> >>>> more. >> >>>> >> >>> >> >>> >> >>> I was not aware of the stalled results.. Investigating now. >> >>> >> >> >> >> I think Sandia testers on Darwin and Linux are cycling okay in both >> >> develop and master, there’s results up there from Dec 20th. Are the >> Sandia >> >> config test results wrong or unexpected? >> >> >> > >> > The latest results from Sandia that I can see are from 12th. The report >> > info[1] also says it was run last time on 12th. >> > >> > [1]: http://www.boost.org/development/tests/develop/developer/ >> index.html >> >> >> The report generation issue is now addressed. The results are current and >> show tests from today. >> >> > I see lots of new results for "master", but none for "develop". (yet) > > Interesting. This page: http://www.boost.org/development/tests/develop/developer/config.html shows new results, but this one http://www.boost.org/development/tests/develop/developer/summary.html does not. -- Marshall

3 3