This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Possible regression on gdb.gdb/complaints.exp
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 04 Jun 2018 19:29:18 -0400
- Subject: Re: Possible regression on gdb.gdb/complaints.exp
- References: <20180522050704.10845-1-tom@tromey.com> <87a7saz4d2.fsf@redhat.com> <87lgbu44h6.fsf@tromey.com>
On Monday, June 04 2018, Tom Tromey wrote:
>>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
> Sergio> (gdb) PASS: gdb.gdb/complaints.exp: run until breakpoint at captured_command_loop
> Sergio> set stop_whining = 2
> Sergio> (gdb) PASS: gdb.gdb/complaints.exp: set stop_whining = 2
> Sergio> set var $cstr = "Register a complaint"
> Sergio> (gdb) PASS: gdb.gdb/complaints.exp: set var $cstr = "Register a complaint"
> Sergio> call complaint_internal ($cstr)
> Sergio> free(): invalid pointer
>
> This seems fishy. I wonder if debugging gdb running under valgrind
> would show anything interesting.
I did try that this weekend, but it hasn't gotten me very far. What I
did was to start a valgrind gdbserver debugging ./gdb/gdb, and then
attach a GDB to it (also debugging ./gdb/gdb). When the abort happens,
valgrind doesn't report something useful:
==6539== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==6539== /path/to/gdb ./gdb/gdb
==6539== and then give GDB the following command
==6539== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=6539
==6539== --pid is optional if only one valgrind process is running
==6539==
==6539== Jump to the invalid address stated on the next line
==6539== at 0x0: ???
==6539== Address 0x0 is not stack'd, malloc'd or (recently) free'd
Strangely enough, I also tried doing some printf-debugging on
complaint_internal, but nothing is printed.
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/