public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "simark at simark dot ca" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug backtrace/29395] blockframe.c:79: internal-error: get_frame_block: Assertion `bl != NULL' failed.
Date: Wed, 21 Dec 2022 04:49:30 +0000 [thread overview]
Message-ID: <bug-29395-4717-dZUc3LSu4O@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29395-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=29395
--- Comment #10 from Simon Marchi <simark at simark dot ca> ---
(In reply to Simon Marchi from comment #9)
> I dissected the debug info a bit while looking at what GDB is doing. The
> execution is stopped in this hierarchy, in /usr/bin/kicad:
>
> 0x0000057d: DW_TAG_compile_unit
> DW_AT_producer ("GNU C++14 12.2.0 -march=x86-64
> -mtune=generic -g -g -O2 -O2 -std=c++14 -fno-plt -fexceptions
> -fstack-clash-protection -fcf-protection=full -fPIE -fvisibility=hidden
> -fvisibility-inlines-hidden")
> DW_AT_language (DW_LANG_C_plus_plus_14)
> DW_AT_name
> ("/usr/src/debug/kicad/kicad/kicad/dialogs/dialog_template_selector_base.
> cpp")
> DW_AT_comp_dir ("/usr/src/debug/kicad/build/kicad")
> DW_AT_ranges (0x0000187d
> ... snip ...
> DW_AT_low_pc (0x0000000000000000)
> DW_AT_stmt_list (0x00000178)
>
>
> 0x00031917: DW_TAG_subprogram
> DW_AT_specification (0x00009a0c
> "_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_")
> DW_AT_decl_file
> ("/usr/include/c++/12.2.0/bits/basic_string.tcc")
> DW_AT_decl_line (273)
> DW_AT_decl_column (0x05)
> DW_AT_object_pointer (0x0003193b)
> DW_AT_low_pc (0x00000000002946d0)
> DW_AT_high_pc (0x00000000002947c8)
> DW_AT_frame_base (DW_OP_call_frame_cfa)
> DW_AT_call_all_calls (true)
> DW_AT_sibling (0x00031ecf)
>
> 0x00031961: DW_TAG_lexical_block
> DW_AT_ranges (0x000017a0
> [0x00000000002946f5, 0x0000000000294729)
> [0x0000000000294750, 0x00000000002947c2))
> DW_AT_sibling (0x00031ec1)
>
> 0x00031c77: DW_TAG_inlined_subroutine
> DW_AT_abstract_origin (0x000327c8
> "_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE13_M_set_lengthEm")
> DW_AT_entry_pc (0x000000000029471d)
> DW_AT_GNU_entry_view (0x0000)
> DW_AT_ranges (0x00001846
> [0x000000000029471d, 0x0000000000294729)
> [0x00000000002947ac, 0x00000000002947b8))
> DW_AT_call_file
> ("/usr/include/c++/12.2.0/bits/basic_string.tcc")
> DW_AT_call_line (293)
> DW_AT_call_column (0x11)
> DW_AT_sibling (0x00031d4e)
>
> 0x00031cee: DW_TAG_inlined_subroutine
> DW_AT_abstract_origin (0x0003290b
> "_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE7_M_dataEv")
> DW_AT_entry_pc (0x0000000000294721)
> DW_AT_GNU_entry_view (0x0001)
> DW_AT_ranges (0x00001858
> [0x0000000000294721, 0x0000000000294721)
> [0x00000000002947ac, 0x00000000002947b8))
> DW_AT_call_file
> ("/usr/include/c++/12.2.0/bits/basic_string.h")
> DW_AT_call_line (268)
> DW_AT_call_column (0x1d)
> DW_AT_sibling (0x00031d17)
>
>
> get_frame_block calls get_frame_address_in_block_if_available, which returns
> 0x2947ab (actually, the relocated version of it, but I'm using the
> unrelocated version here so it matches the debug info above). This is
> because get_frame_address_in_block_if_available returns "pc - 1". This
> address falls outside the block the frame is in, if you look at the last
> DW_TAG_inlined_subroutine's ranges. Another unrelated block is returned by
> block_for_pc. The value returned by frame_inlined_callees (which counts the
> number of inlined frame using the frame_infos) doesn't match the expected
> number of "inlined subroutine block" we see by going up the block tree, we
> eventually reach the global block and try to get its superblock.
>
> So I think that the root of the problem is get_frame_address_in_block not
> returning the right thing.
>
> In addition to checking that `gdb_assert (bl != NULL);`, I think that
> get_frame_block should check that the block obtained from `bl->superblock
> ()` isn't the global block nor the static block. I think we always expect
> to reach a block that comes from a DW_TAG_subprogram or more precise.
Scratch all this, get_frame_address_in_block is working as expected, as
explained by the comment in it. We are inspecting a non-current frame, so
0x2947ac is the address execution will return to. The -1 is to get to an
address belonging to the call instruction just before:
2947a6: ff 15 f4 cc 77 00 call *0x77ccf4(%rip) # a114a0
<wmemcpy@GLIBC_2.2.5>
2947ac: 4c 8b 23 mov (%rbx),%r12
0x2947ab gets us here:
0x00047016: DW_TAG_compile_unit
DW_AT_producer ("GNU C++14 12.2.0 -march=x86-64 -mtune=generic
-g -g -O2 -O2 -std=c++14 -fno-plt -fexceptions -fstack-clash-protection
-fcf-protection=full -fPIE -fvisibility=hi
dden -fvisibility-inlines-hidden")
DW_AT_language (DW_LANG_C_plus_plus_14)
DW_AT_name
("/usr/src/debug/kicad/kicad/kicad/dialogs/dialog_template_selector.cpp")
DW_AT_comp_dir ("/usr/src/debug/kicad/build/kicad")
DW_AT_ranges (0x00003a4b
...snip...
DW_AT_low_pc (0x0000000000000000)
DW_AT_stmt_list (0x0000575b)
0x0007aa2b: DW_TAG_subprogram
DW_AT_specification (0x00050552
"_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_")
DW_AT_decl_file
("/usr/include/c++/12.2.0/bits/basic_string.tcc")
DW_AT_decl_line (273)
DW_AT_decl_column (0x05)
DW_AT_object_pointer (0x0007aa4f)
DW_AT_low_pc (0x00000000002946d0)
DW_AT_high_pc (0x00000000002947c8)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_call_all_calls (true)
DW_AT_sibling (0x0007afe0)
0x0007aa75: DW_TAG_lexical_block
DW_AT_ranges (0x00002a86
[0x00000000002946f5, 0x0000000000294729)
[0x0000000000294750, 0x00000000002947c2))
DW_AT_sibling (0x0007afd2)
0x0007ae94: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0007bd6c
"_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE7_S_copyEPwPKwm")
DW_AT_entry_pc (0x0000000000294788)
DW_AT_GNU_entry_view (0x0001)
DW_AT_low_pc (0x0000000000294788)
DW_AT_high_pc (0x00000000002947ac)
DW_AT_call_file
("/usr/include/c++/12.2.0/bits/basic_string.tcc")
DW_AT_call_line (291)
DW_AT_call_column (0x13)
0x0007af20: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x00096bf5
"_ZNSt11char_traitsIwE4copyEPwPKwm")
DW_AT_entry_pc (0x00000000002947a0)
DW_AT_GNU_entry_view (0x0001)
DW_AT_low_pc (0x00000000002947a0)
DW_AT_high_pc (0x00000000002947ac)
DW_AT_call_file
("/usr/include/c++/12.2.0/bits/basic_string.h")
DW_AT_call_line (423)
DW_AT_call_column (0x15)
0x0007af6a: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x00057a96 "wmemcpy")
DW_AT_entry_pc (0x00000000002947a0)
DW_AT_GNU_entry_view (0x0004)
DW_AT_low_pc (0x00000000002947a0)
DW_AT_high_pc (0x00000000002947ac)
DW_AT_call_file
("/usr/include/c++/12.2.0/bits/char_traits.h")
DW_AT_call_line (558)
DW_AT_call_column (0x10)
Which makes sense, that gives us three inline frames, which is what
frame_inlined_callees returns. However, block_for_pc returns a seemingly
unrelated block, in a different CU:
0x04037ab0: DW_TAG_compile_unit
DW_AT_producer ("GNU C++14 12.2.0 -march=x86-64 -mtune=generic
-g -g -O2 -O2 -std=c++14 -fno-plt -fexceptions -fstack-clash-protection
-fcf-protection=full -fPIC -fvisibility=hi
dden -fvisibility-inlines-hidden")
DW_AT_language (DW_LANG_C_plus_plus_14)
DW_AT_name
("/usr/src/debug/kicad/kicad/scripting/python_scripting.cpp")
DW_AT_comp_dir ("/usr/src/debug/kicad/build/scripting")
DW_AT_ranges (0x002e47d7
...snip...
DW_AT_low_pc (0x0000000000000000)
DW_AT_stmt_list (0x0070635a)
0x040c6ebb: DW_TAG_subprogram
DW_AT_specification (0x0403c948
"_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_")
DW_AT_decl_file
("/usr/include/c++/12.2.0/bits/basic_string.tcc")
DW_AT_decl_line (273)
DW_AT_decl_column (0x05)
DW_AT_object_pointer (0x040c6edf)
DW_AT_low_pc (0x00000000002946d0)
DW_AT_high_pc (0x00000000002947c8)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_call_all_calls (true)
DW_AT_sibling (0x040c73d8)
0x040c6f05: DW_TAG_lexical_block
DW_AT_ranges (0x002d725f
[0x00000000002946f5, 0x0000000000294729)
[0x0000000000294750, 0x00000000002947c2))
DW_AT_sibling (0x040c73ca)
0x040c7216: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x040d4dcd
"_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE13_M_set_lengthEm")
DW_AT_entry_pc (0x000000000029471d)
DW_AT_GNU_entry_view (0x0000)
DW_AT_ranges (0x002d7305
[0x000000000029471d, 0x0000000000294729)
[0x00000000002947ab, 0x00000000002947b8))
DW_AT_call_file
("/usr/include/c++/12.2.0/bits/basic_string.tcc")
DW_AT_call_line (293)
DW_AT_call_column (0x11)
DW_AT_sibling (0x040c72ed)
0x040c728d: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x040d4f10
"_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE7_M_dataEv")
DW_AT_entry_pc (0x0000000000294721)
DW_AT_GNU_entry_view (0x0001)
DW_AT_ranges (0x002d7317
[0x0000000000294721, 0x0000000000294721)
[0x00000000002947ab, 0x00000000002947b8))
DW_AT_call_file
("/usr/include/c++/12.2.0/bits/basic_string.h")
DW_AT_call_line (268)
DW_AT_call_column (0x1d)
DW_AT_sibling (0x040c72b6)
In fact, there are many DW_TAG_inlined_subroutine DIEs that have that
[0x00000000002947ab, 0x00000000002947b8) range. It appears wrong, as you can
see in the disassembly above, there's no instruction starting at 0x2947ab, so
I'm not sure why a block range would start there. Plus the fact that it's
overlapping with that other DW_TAG_inlined_subroutine.
--
You are receiving this mail because:
You are on the CC list for the bug.
prev parent reply other threads:[~2022-12-21 4:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 13:02 [Bug backtrace/29395] New: " georgepee at gmail dot com
2022-07-25 15:27 ` [Bug backtrace/29395] " georgepee at gmail dot com
2022-08-24 13:20 ` georgepee at gmail dot com
2022-12-15 18:08 ` seth.pellegrino at gmail dot com
2022-12-15 18:11 ` simon.marchi at polymtl dot ca
2022-12-15 18:43 ` seth.pellegrino at gmail dot com
2022-12-15 19:14 ` simon.marchi at polymtl dot ca
2022-12-15 20:09 ` simon.marchi at polymtl dot ca
2022-12-15 20:27 ` simon.marchi at polymtl dot ca
2022-12-15 21:02 ` seth.pellegrino at gmail dot com
2022-12-15 21:12 ` simon.marchi at polymtl dot ca
2022-12-16 16:27 ` tromey at sourceware dot org
2022-12-20 23:03 ` simark at simark dot ca
2022-12-21 4:49 ` simark at simark dot ca [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=bug-29395-4717-dZUc3LSu4O@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).