I don't remember if I've posted the actual boost file which has
triggered the error for me: instantiate_predef_macros.cpp. I've
been running creduce on a fully preprocessed version created with
"gcc -P -E". In all cases, the file is from the released boost
1.73.0 tarball. I think all the original gentoo bug reports were
using gcc-10, in my case 10.1 and 10.2. I never had a problem
compiling boost for the system, but only when genkernel was
compiling a version of boost for an initramfs. I've since had
other successful runs of both emerging boost and of genkernel. https://bugs.gentoo.org/show_bug.cgi?id=730406
is the Gentoo bug. One point is that is first showed up only for
folks with -march=znver1, so the CPU does seem to matter. I do
not know whether the error is as inconsistently reproducible for
others as it is for me.
Also, since it's Gentoo, there is no system provided gcc, it's
all built on my own PC. The developer watching the bug gave me
the magic incantations to reguild gcc with bootstrap-asan. He had
tried it and didn't get anything - but he's on a znver2 CPU. I'll
try that later - I'm spending much of the day still clearing
debris from Isaias.
I'm not seeing a crash here on your examples, using your script. I do get errors, e.g.
instantiate_predef_macros.pp.cpp:11136:1: error: ‘constexpr boost::system::detail::system_error_category::system_error_category()’ is private within this context
11136 | };
| ^
instantiate_predef_macros.pp.cpp:11125:16: note: declared private here
11125 | constexpr system_error_category() noexcept: error_category( ( boost::ulong_long_type( 0x8FAFD21E ) << 32 ) + 0x25C5E09B ) {
but no crashes.
I tried both with trunk ( g++ 11.0.0 20200806 ) built with asan, and the system c++ compiler (g++ 9.3.0-10ubuntu2).
Could be a problem in the system-provided compiler... or the hardware :-/
Perhaps if you provided the larger script that reproduces the unreduced problemstarting with the git command to clone boost, I could try reproducing here.Alternately, you could try running it in a container with various otherlinux versions to see if any of them exhibit the problem...- Dan
On Fri, Aug 7, 2020 at 11:32 AM Jack <ostroffjh@users.sourceforge.net> wrote:
Thanks for trying. I'm on Gentoo (source based distro) so I prefer to use or modify an existing ebuild (instructions for fetch/patch/config/compile) if at all possible, but maybe this is occasion for an exception.
By the way, disabling aslr did not make any difference. I also think the latest reduced file is another case of invalid syntax triggering the stack smash. I have no idea how creduce would produce a program with invalid syntax, even though it IS interesting, but I'll be glad to provide examples if anyone wants. From an earlier run, I already submitted to the creduce-bugs list a set of 9, and I have 5 more from the most recent run to send later.
I'm also no gcc wrangler, but there is one monitoring the Gentoo bug, so at least someone who knows what he's doing is watching the proceedings.
On 8/7/20 1:26 PM, Dan Kegel wrote:
Since I suggested building g++ with address sanitizer, even though I've never tried it myself,
I felt honor-bound to give it a shot :-) Note: I am not a professional gcc wrangler, just a hobbyist.
This worked for me:
# One-time preparation
sudo apt build-dep g++sudo apt install libmpc-dev
# work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48879)(cd /usr/include; sudo ln -s asm-generic asm)
# If you don't want to clutter /usr/local, pick some other prefix when running configure
sudo mkdir /usr/localsudo chown $USER /usr/local# build as usual, but --with-build-config=bootstrap-asangit clone git://gcc.gnu.org/git/gcc.git
cd gccmkdir btmp
cd btmp
.../configure --with-arch=native --enable-multiarch --disable-lto --enable-stage1-languages=c --enable-languages=c,c++ --with-build-config=bootstrap-asan
make -j4 bootstrap
make install
Bootstrapping took 8 hours on an i3-4130.
After that, running /usr/local/bin/g++ hello.cc aborts with
==528129==ERROR: LeakSanitizer: detected memory leaks
but setting LSAN_OPTIONS=detect_leaks=0 lets it succeed.
Should be just the ticket for finding internal errors... althoughit was built with -O2, so the backtraces might not be as informativeas you'd like.- Dan
On Thu, Aug 6, 2020 at 2:49 PM Dan Kegel <dank@kegel.com> wrote:
>
> I have not tried it myself, but googling finds references to a --with-build-config=bootstrap-asan option for building gcc itself. I have not checked what it does.
>
> On Thu, Aug 6, 2020, 14:23 Jack <ostroffjh@users.sourceforge.net> wrote:
>>
>> (I didn't get Dan's message directly - perhaps it's still out in the
>> ether...)
>>
>> On 2020.08.06 16:55, John Regehr wrote:
>> >> Can you also bootstrap gcc with address sanitizer? That might help
>> >> detect the error more reliably...?
>> > This is a good idea.
>> A pointer please? I'm not sure how to approach this.
>> >
>> >> Also, in my experience, restarting creduce runs from scratch after
>> >> improving your oracle script etc. is kind of part of the territory...
>> My test.sh is only
>>
>> #!/bin/bash
>> x86_64-pc-linux-gnu-g++ -fvisibility-inlines-hidden -Os -pipe
>> -fomit-frame-pointer -std=c++14 -fPIC -m64 -pthread -finline-functions
>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_DYN_LINK=1
>> -DBOOST_ALL_NO_LIB=1
>> -DNDEBUG -c -o instantiate_predef_macros.o
>> instantiate_predef_macros.pp.cpp > gcc_out.txt 2>&1
>> grep "stack smashing detected" gcc_out.txt >/dev/null 2>&1
>>
>> so there isn't much to change. I suppose I could try removing some of
>> the parameters, but I don't personally understand them well enough to
>> know if they will affect the outcome. I suppose I could try a manual
>> creduce on the command line itself :-)
>>
>> Jack
>>