public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom de Vries <tdevries@suse.de>,
	Simon Marchi <simon.marchi@efficios.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests
Date: Thu, 4 Nov 2021 16:04:53 -0400	[thread overview]
Message-ID: <972f3e77-0788-e0e7-e524-e8617e4a4aee@polymtl.ca> (raw)
In-Reply-To: <39183fd0-d31d-feb4-9cfd-8c928b5eaf06@suse.de>

On 2021-11-03 06:24, Tom de Vries via Gdb-patches wrote:
> On 11/2/21 9:34 PM, Simon Marchi via Gdb-patches wrote:
>> We see some additional failures when running the testsuite against a GDB
>> compiled with ASan, compared to a GDB compiled without ASan.  Some of
>> them are caused by the memory leak report shown by the GDB process when
>> it exits, and the fact that it makes it exit with a non-zero exit code.
>>
>> I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
>> environment when running the tests, but I don't always do it.  I think
>> it would be nice if the testsuite did it.  I don't see any use to have
>> leak detection when running the tests.  That is, unless we ever have a
>> test that ensures GDB doesn't leak memory, which isn't going to happen
>> any time soon.
>>
> 
> I like the idea.  I also use the setting in my test scripts.
> 
> FWIW, in addition, I also use "alloc_dealloc_mismatch=0", that error was
> triggered at some point.  I've just done a run without this setting, and
> it didn't trigger anything.
> 
> I tried to understand why, and stumbled onto
> https://sourceware.org/pipermail/gdb-patches/2021-May/178413.html ,
> which seems to have been approved, but never committed.  The problem
> described there, using LD_PRELOAD like so:
> ...
> $ LD_PRELOAD=/usr/lib64/libasan.so.6 ./gdb
> ...
> does reproduce for me, and applying the patch fixes it.  I've done a
> build and test run, and will commit shortly.
> 
> Also there a few test-cases which fail when using asan, we could
> annotate those perhaps with abort_on_error=1 or some such.

Starting with this commit, I get these 4 errors with clang 12, in a
non-ASan build.  The 2 -Wimplicit-exception-spec-mismatch can be fixed
by adding "noexcept", but I don't know about the -Wmissing-prototypes
ones.  It might indicate that the prototype of the functions isn't
right, but I can't find the problem.

Note that with Clang, I build with -std=gnu++17 in CXXFLAGS to avoid
the problem with gnulib headers in the string_view selftests.


    $ clang++  -DHAVE_CONFIG_H -I. -I/home/simark/src/binutils-gdb/gdbsupport  -I/home/simark/src/binutils-gdb/gdbsupport/../include -I/home/simark/src/binutils-gdb/gdbsupport/../gdb -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbsupport/../gnulib/import -I.. -I/home/simark/src/binutils-gdb/gdbsupport/..  -I../bfd -I/home/simark/src/binutils-gdb/gdbsupport/../bfd   -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wno-sign-compare -Wno-mismatched-tags -Wno-error=deprecated-register -Wsuggest-override -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wformat -Wformat-nonliteral -Werror -std=gnu++17 -g3 -O0 -D_GLIBCXX_DEBUG=1   -MT new-op.o -MD -MP -MF .deps/new-op.Tpo -c -o new-op.o /home/simark/src/binutils-gdb/gdbsupport/new-op.cc
    
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:102:1: error: function previously declared with an explicit exception specification redeclared with an implicit exception specification [-Werror,-Wimplicit-exception-spec-mismatch]
    operator delete (void *p)
    ^
    /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/new:130:6: note: previous declaration is here
    void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
         ^
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:114:1: error: no previous prototype for function 'operator delete' [-Werror,-Wmissing-prototypes]
    operator delete (void *p, std::size_t) noexcept
    ^
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:113:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
    void
    ^
    static 
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:120:1: error: function previously declared with an explicit exception specification redeclared with an implicit exception specification [-Werror,-Wimplicit-exception-spec-mismatch]
    operator delete[] (void *p)
    ^
    /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/new:132:6: note: previous declaration is here
    void operator delete[](void*) _GLIBCXX_USE_NOEXCEPT
         ^
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:132:1: error: no previous prototype for function 'operator delete[]' [-Werror,-Wmissing-prototypes]
    operator delete[] (void *p, std::size_t) noexcept
    ^
    /home/simark/src/binutils-gdb/gdbsupport/new-op.cc:131:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
    void
    ^
    static 
    4 errors generated.

Simon

  parent reply	other threads:[~2021-11-04 20:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-02 20:34 Simon Marchi
2021-11-03 10:24 ` Tom de Vries
2021-11-03 12:28   ` Tom de Vries
2021-11-03 14:45     ` Simon Marchi
2021-11-04 11:55       ` Tom de Vries
2021-11-04 20:04   ` Simon Marchi [this message]
2021-11-05 10:03     ` [gdb/build] Fix Wimplicit-exception-spec-mismatch in clang build Tom de Vries
2021-11-05 14:24       ` Simon Marchi
2021-11-05 17:00         ` Pedro Alves
2021-11-05 17:07       ` Pedro Alves
2021-11-10 13:32         ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=972f3e77-0788-e0e7-e524-e8617e4a4aee@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@efficios.com \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).