public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "abidh at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/27827] New: GDB can crash while calling a function that returns a class with virtual base.
Date: Thu, 06 May 2021 11:07:37 +0000	[thread overview]
Message-ID: <bug-27827-4717@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=27827

            Bug ID: 27827
           Summary: GDB can crash while calling a function that returns a
                    class with virtual base.
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: abidh at sourceware dot org
  Target Milestone: ---

I recently observed that calling a function that returns a class which has a
virtual base causes memory access at location 0. To reproduce, run to the
testsuite/gdb.cp/non-trivial-retval.cc:151 and then issue the following command
(gdb) p f4(1,2)

On x86_64, You will see 
[remote] Packet received: 505d5555555500000300000080030000
[remote] Sending packet: $m0,8#01
[remote] Packet received: E01
$2 = {<D> = <invalid address>, _vptr.E = 0x555555555d50 <VTT for E>, e = 3}

But on some targets (e.g. on a nios2 simulator) which returns some memory for
address 0, it can even cause a crash.

Packet received: c02300000300000000000000
$1 = {Sending packet: $m0,4#fd...Ack
Packet received: 14100080
Sending packet: $m80001008,4#5e...Ack
Packet received: 3b1109e0
Sending packet: $me009113b,4#c2...Ack
Packet received: efefbeef
<D> = Sending packet: $m0,4#fd...Ack
Packet received: 14100080
Sending packet: $m80001008,4#5e...Ack
Packet received: 3b1109e0
Aborted (core dumped)

It seems that this problem is related to FIXME in gnu-v3-abi.c. Tom has
mentioned it in 7d79de9a4be2. Not setting valaddr causes code to take the
address of a not_lval value. This is where the address 0 seems to be coming
from.

The crash backtrace is
#0  __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:319
#1  value_contents_copy_raw (dst=0x5555562d0e10, dst_offset=0,
src=0x5555562d0d10, src_offset=-536276677, length=4) at value.c:1327
#2  value_primitive_field (arg1=0x5555562d0d10, offset=0, fieldno=0,
arg_type=0x5555562be980) at value.c:3019
#3  cp_print_value_fields (val=0x5555562d0d10, stream=0x55555625a180,
recurse=1, options=0x7fffffffd080, dont_print_vb=0x55555617cea0,
dont_print_statmem=0)
    at cp-valprint.c:333
#4  cp_print_value (val=0x555556224250, stream=0x55555625a180, recurse=1,
options=0x7fffffffd080, dont_print_vb=0x0) at cp-valprint.c:519
#5  cp_print_value_fields (val=0x555556224250, stream=0x55555625a180,
recurse=0, options=0x7fffffffd080, dont_print_vb=0x0, dont_print_statmem=0)
    at cp-valprint.c:159
#6  c_value_print_struct (val=0x555556224250, stream=0x55555625a180, recurse=0,
options=0x7fffffffd080) at c-valprint.c:385
#7  c_value_print_inner (val=0x555556224250, stream=0x55555625a180, recurse=0,
options=0x7fffffffd080) at c-valprint.c:462
#8  language_defn::value_print_inner (this=0x5555560365a0
<cplus_language_defn>, val=0x555556224250, stream=0x55555625a180, recurse=0,
options=0x7fffffffd080)
    at language.c:651
#9  do_val_print (value=0x555556224250, stream=0x55555625a180, recurse=0,
options=0x7fffffffd170, language=0x5555560365a0 <cplus_language_defn>)
    at valprint.c:982
#10 common_val_print (val=0x555556224250, stream=0x55555625a180, recurse=0,
options=0x7fffffffd170, language=0x5555560365a0 <cplus_language_defn>)
    at valprint.c:1085
#11 c_value_print (val=0x555556224250, stream=0x55555625a180,
options=0x7fffffffd340) at c-valprint.c:613
#12 language_defn::value_print (this=0x5555560365a0 <cplus_language_defn>,
val=0x555556224250, stream=0x55555625a180, options=0x7fffffffd340)
    at language.c:633
#13 value_print (val=0x555556224250, stream=0x55555625a180,
options=0x7fffffffd340) at valprint.c:1123
#14 print_formatted (val=0x555556224250, size=0, options=0x7fffffffd340,
stream=0x55555625a180) at printcmd.c:320
#15 print_value (val=0x555556224250, opts=...) at printcmd.c:1187
#16 print_command_1 (args=0x555556252862 "f4 (1, 2)", voidprint=1) at
printcmd.c:1221

-- 
You are receiving this mail because:
You are on the CC list for the bug.

             reply	other threads:[~2021-05-06 11:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 11:07 abidh at sourceware dot org [this message]
2022-09-20  9:13 ` [Bug gdb/27827] " abidh at sourceware dot org

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=bug-27827-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).