[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [creduce-dev] question on creduce usage

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 problem
starting with the git command to clone boost, I could try reproducing here.
Alternately, you could try running it in a container with various other
linux 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
(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/local
sudo chown $USER /usr/local
# build as usual, but --with-build-config=bootstrap-asan
git clone git://gcc.gnu.org/git/gcc.git 
cd gcc
mkdir 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... although 
it was built with -O2, so the backtraces might not be as informative
as 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
>> -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