From: Simon Marchi <simark@simark.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: Wed, 3 Nov 2021 10:45:54 -0400 [thread overview]
Message-ID: <b8626138-8a02-09cf-ae10-7719db7e5379@simark.ca> (raw)
In-Reply-To: <d2d9108f-6773-2a2b-5e00-a6249d763ca0@suse.de>
On 2021-11-03 8:28 a.m., Tom de Vries via Gdb-patches wrote:
> On 11/3/21 11:24 AM, Tom de Vries 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.
Ok, I'll push that patch.
>> 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.
Ok, thanks. Since the issue is fixed, do you think we still need to add
alloc_dealloc_mismatch=0? I would think not. If an
alloc_dealloc_mismatch problem is ever introduced, then that would be a
GDB bug needing to be fixed.
>> Also there a few test-cases which fail when using asan, we could
>> annotate those perhaps with abort_on_error=1 or some such.
>
> FTR, I meant f.i.:
> ...
> AddressSanitizer can not provide additional info.^M
> SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xf15fa) in __libc_poll^M
> ==23338==ABORTING^M
> FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: $saw_fatal_msg
> ...
> but I didn't find an ASAN_OPTIONS settting to disable this.
>
> BTW, this is with gcc 7.5.0 (using libasan.so.4 according to ldd), I
> don't see this when doing an address sanitizer build with gcc 11.2.1,
> but then I see fails in gdb.base/early-init-file.exp.
Indeed. I haven't compared a no-asan build with an asan build yet.
I am not sure how abort_on_error would here in
gdb.base/bt-on-fatal-signal.exp. The output that the test is looking
for seems to be printed regardless of whether ASan calls abort later or
not. But I am trying with gcc 11, so perhaps that's the difference with
gcc 7 you are talking about. In any case, I wouldn't mind enabling
abort_on_error all the time, that may just help making crashes more
apparent.
Also, looking at:
https://clang.llvm.org/docs/AddressSanitizer.html
... it seems like there are some disabled-by-default checks that we
could enable, like "check_initialization_order=1" and
"detect_stack_use_after_return=1".
Simon
next prev parent reply other threads:[~2021-11-03 14:45 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 [this message]
2021-11-04 11:55 ` Tom de Vries
2021-11-04 20:04 ` Simon Marchi
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=b8626138-8a02-09cf-ae10-7719db7e5379@simark.ca \
--to=simark@simark.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).