From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id C04FA385840A for ; Thu, 4 Nov 2021 11:55:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C04FA385840A Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 08BB8218D9; Thu, 4 Nov 2021 11:55:15 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E3CAF13C68; Thu, 4 Nov 2021 11:55:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 9ux8NiLKg2HFeQAAMHmgww (envelope-from ); Thu, 04 Nov 2021 11:55:14 +0000 Subject: Re: [PATCH] gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests To: Simon Marchi , Simon Marchi , gdb-patches@sourceware.org References: <20211102203434.3889269-1-simon.marchi@efficios.com> <39183fd0-d31d-feb4-9cfd-8c928b5eaf06@suse.de> From: Tom de Vries Message-ID: <64717568-d061-5435-d43c-79ea13ee7367@suse.de> Date: Thu, 4 Nov 2021 12:55:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 11:55:17 -0000 On 11/3/21 3:45 PM, Simon Marchi wrote: > 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. Agreed. > If an > alloc_dealloc_mismatch problem is ever introduced, then that would be a > GDB bug needing to be fixed. > Ack. >>> 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. > Sorry, copy-pasto, I meant abort_on_error=0 in that particular test-case, but as mentioned before, that didn't help. > 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". Agreed. I have no experience with those, if the extra runtime tradeoff is not too bad, then why not. Thanks, - Tom