Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 00/10] Enable undefined behavior sanitizer
Date: Wed, 12 Sep 2018 11:49:00 -0000	[thread overview]
Message-ID: <87lg87j5rl.fsf@tromey.com> (raw)
In-Reply-To: <20180830024416.23386-1-tom@tromey.com> (Tom Tromey's message of	"Wed, 29 Aug 2018 20:44:06 -0600")

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> This is v2 of the series to enable the undefined behavior sanitizer
Tom> for gdb.  This is done by default in development mode, but can be
Tom> disabled.

Update on this series...

Tom> I believe this version addresses all the review comments.

For the record, subsequently, Pedro and I discussed the need to document
this a bit more.  I'll include a patch for this in the next revision of
the series.

Tom> Tested (*) by the buildbot.

Tom> (*) However, as I mentioned in another thread, the s390 builders do
Tom> not like this series.  I get many, many failures.  Looking at the
Tom> gdb.log, though, the failures seem to be coming from libstdc++ debug
Tom> mode -- which this series does not enable.

This is all explained now.

Sergio pointed out that the builders are enabling -D_GLIBCXX_DEBUG.  I'm
glad that mystery is solved.

A failure with -D_GLIBCXX_DEBUG enabled just results in a crash, without
much useful information to go by.  This is often fine, but in this case
I could only reproduce on s390, where I couldn't log in to reproduce for
myself.

So, I hacked the testsuite Makefile to run just a single test .exp that
I knew to fail, and then arranged to get a real stack trace.  See the
appended patch.

This pointed out that there was a bug in one of the patches in the series.
Namely, this code in dwarf2-frame.c:

	    struct dwarf2_frame_state_reg *retaddr_reg =
	      &fs.regs.reg[fs.retaddr_column];

... will reference past the end of the array in some cases.  When reg is
just an ordinary pointer this is "ok" -- possibly undefined behavior
depending on the index in use, but not likely to cause a crash.  But the
series changes reg to a std::vector, where this is invalid.

Tom

diff --git a/gdb/testsuite/Makefile.in b/gdb/testsuite/Makefile.in
index 07e0928a9f8..3bfc4d9f847 100644
--- a/gdb/testsuite/Makefile.in
+++ b/gdb/testsuite/Makefile.in
@@ -48,7 +48,7 @@ EXPECT = `if [ "$${READ1}" != "" ] ; then \
 
 RUNTEST = $(RUNTEST_FOR_TARGET)
 
-RUNTESTFLAGS =
+override RUNTESTFLAGS := gdb.cp/extern-c.exp
 
 FORCE_PARALLEL =
 
@@ -153,7 +153,11 @@ CHECK_TARGET = $(if $(RACY_ITER),$(addsuffix -racy,$(CHECK_TARGET_TMP)),$(CHECK_
 # because GNU make 3.82 has a bug preventing MAKEFLAGS from being used
 # in conditions.
 check: all $(abs_builddir)/site.exp
-	$(MAKE) $(CHECK_TARGET)
+	-$(MAKE) $(CHECK_TARGET)
+	cat gdb.log
+	/bin/gdb -batch -ex 'run' -ex 'bt' \
+		--args ../gdb -batch -ex 'file outputs/gdb.cp/extern-c/extern-c' \
+		-ex 'break c_func' -ex 'run' -ex 'rbreak c_funcs'
 
 check-read1:
 	$(MAKE) READ1="1" check


      parent reply	other threads:[~2018-09-12 11:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30  2:44 Tom Tromey
2018-08-30  2:44 ` [PATCH v2 05/10] Avoid undefined behavior in read_subrange_type Tom Tromey
2018-08-30  2:44 ` [PATCH v2 10/10] Add --enable-ubsan Tom Tromey
2018-08-30  2:44 ` [PATCH v2 09/10] Avoid undefined behavior in expression dumping Tom Tromey
2018-08-30  2:44 ` [PATCH v2 03/10] Use unsigned as base type for some enums Tom Tromey
2018-08-30  2:44 ` [PATCH v2 01/10] Do not pass NULL to memcpy Tom Tromey
2018-08-30  2:44 ` [PATCH v2 08/10] Avoid undefined behavior in ada_operator_length Tom Tromey
2018-08-30  2:44 ` [PATCH v2 06/10] Avoid undefined behavior in parse_number Tom Tromey
2018-08-30  2:44 ` [PATCH v2 04/10] Avoid undefined behavior in extract_integer Tom Tromey
2018-08-30  2:44 ` [PATCH v2 02/10] Change dwarf2_frame_state_reg_info::reg to be std::vector Tom Tromey
2018-08-30  2:44 ` [PATCH v2 07/10] Avoid undefined behavior in read_signed_leb128 Tom Tromey
2018-09-12 11:49 ` Tom Tromey [this message]

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=87lg87j5rl.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    /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