Boost logo

Boost Testing :

Subject: Re: [Boost-testing] [boost] [regression] Tests for 'develop' not showing
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-09-30 14:00:23

Tom Kent wrote:
> On Tue, Sep 29, 2015 at 8:30 PM, Tom Kent<lists_at_[hidden]> wrote:
>> /home/tomkent/tmp/boost_reports/boost-reports/develop/incoming/develop/processed/CrystaX.NET-apilevel-21-armeabi.xml
>> Merging expected results
>> Segmentation fault (core dumped)
>> I tried deleting the whole boost-reports/develop*, but that didn't seem to
>> have any affect. Any ideas how to track this down? Anyone know where the
>> dumped core goes on ubuntu?
>> I got it to produce the core file, here's what I was able to get out of it:
> tomkent_at_eddie:/mnt/fs1/tmp/boost_reports⟫ gdb
> boost-reports/boost_regression/stage/bin/boost_report
> boost-reports/develop/core
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <

In "normal" circumstances an XML file containing the results has around
10 to 50 MB top, this file has 3 GB.

> Core was generated by
> `/mnt/fs1/tmp/boost_reports/boost-reports/boost_regression/stage/bin/boost_repor'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00000000004472b5 in boost::re_detail::perl_matcher<char const*,
> std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char,
> boost::cpp_regex_traits<char> > >::find_restart_any() ()
> Traceback (most recent call last):
> File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.
>", line 63, in <module>
> from libstdcxx.v6.printers import register_libstdcxx_printers
> ImportError: No module named 'libstdcxx'
> (gdb) quit

Regarding the above segfault. AFAIR the only place where regex matching
is used is here:
I've added it some time ago in order to find text phrases indicating a
type of an error. This could be done without Regex so we could drop this
dependency but I don't know it this would fix the problem. The whole
call stack would be helpful.

For now I've tested the report tool on a different platform (win7,
msvc-10) so my results may be not very reliable. In x84 it throws
bad_alloc here:
where the whole file is copied into an in-memory storage (vector). In
x64 it correctly generates the files for me, but it takes a few GB of
memory in the process.


Boost-testing list run by mbergal at