Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panic: in loadDebugInfoMapsCompileUnit: interface {} is nil, not dwarf.Offset #1636

Closed
tbg opened this issue Jul 26, 2019 · 1 comment
Closed

Comments

@tbg
Copy link

tbg commented Jul 26, 2019

Delve Debugger
Version: 1.2.0
Build: $Id: 068e2451004e95d0b042e5257e34f0f08ce01466 $
go version go1.12.7 linux/amd64
lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

(this is an instance on AWS)

Trying to attach to a cockroach process:

$ dlv attach 24490
panic: interface conversion: interface {} is nil, not dwarf.Offset

goroutine 13 [running]:
github.com/go-delve/delve/pkg/proc.(*BinaryInfo).loadDebugInfoMapsCompileUnit(0xc000001800, 0xc0000c60e0, 0xc0000fe6e0, 0xc0000ac480, 0xc0147b5950)
	/home/ubuntu/go/src/github.com/go-delve/delve/pkg/proc/types.go:414 +0x1861
github.com/go-delve/delve/pkg/proc.(*BinaryInfo).loadDebugInfoMaps(0xc000001800, 0xc0000fe6e0, 0xc0069fc000, 0xcb4b4b, 0xcb4b4b, 0xc0000b6bb0, 0x0)
	/home/ubuntu/go/src/github.com/go-delve/delve/pkg/proc/types.go:267 +0x591
created by github.com/go-delve/delve/pkg/proc.loadBinaryInfoElf
	/home/ubuntu/go/src/github.com/go-delve/delve/pkg/proc/bininfo.go:904 +0x3d5

Hopefully repros for others via this binary: https://drive.google.com/file/d/1-CkILyxXwzjTBLIvzCJ21-ud6vuBHs6w/view?usp=sharing (definitely repros here)

dlv exec ./cockroach.boom version

I worked around this via the following diff:

diff --git a/pkg/proc/types.go b/pkg/proc/types.go
index b560d29..017ebc8 100644
--- a/pkg/proc/types.go
+++ b/pkg/proc/types.go
@@ -411,7 +411,8 @@ func (bi *BinaryInfo) loadDebugInfoMapsCompileUnit(ctxt *loadDebugInfoMapsContex
                                                break
                                        }
                                        if entry.Tag == dwarf.TagInlinedSubroutine {
-                                               originOffset := entry.Val(dwarf.AttrAbstractOrigin).(dwarf.Offset)
+                                               originOffset, ok := entry.Val(dwarf.AttrAbstractOrigin).(dwarf.Offset)
+                                               if ok {
                                                name := ctxt.abstractOriginNameTable[originOffset]
                                                if ranges, _ := image.dwarf.Ranges(entry); len(ranges) == 1 {
                                                        ok1 = true
@@ -431,6 +432,9 @@ func (bi *BinaryInfo) loadDebugInfoMapsCompileUnit(ctxt *loadDebugInfoMapsContex
                                                                Parent:   &fn,
                                                        })
                                                }
+                                               } else {
+                                                       fmt.Println("would've crashed")
+                                               }
                                        }
                                        reader.SkipChildren()
                                }

and was able to use dlv normally. (It printed the message dozens of times during startup).

As an additional clue, the issue does not occur with a binary that I thought would be similar:

https://binaries.cockroachdb.com/cockroach-v19.2.0-alpha.20190701.linux-amd64.tgz

aarzilli added a commit to aarzilli/delve that referenced this issue Jul 26, 2019
GCC produces DW_TAG_inlined_subroutine entries without a
DW_AT_abstract_origin attribute.
From the bug report:

 <1><1fe6c7c>: Abbrev Number: 41 (DW_TAG_subprogram)
    <1fe6c7d>   DW_AT_external    : 1
    <1fe6c7d>   DW_AT_name        : (indirect string, offset: 0x485814): MultiGetImpl
    (omissis)
 <2><1fe6c9e>: Abbrev Number: 65 (DW_TAG_inlined_subroutine)
    <1fe6c9f>   DW_AT_low_pc      : 0x311023a
    <1fe6ca7>   DW_AT_high_pc     : 0x5
    <1fe6caf>   DW_AT_call_file   : 10
    <1fe6cb0>   DW_AT_call_line   : 1690
 <2><1fe6cb2>: Abbrev Number: 20 (DW_TAG_inlined_subroutine)
    <1fe6cb3>   DW_AT_abstract_origin: <0x1ffb534>
    <1fe6cb7>   DW_AT_entry_pc    : 0x311023f
    <1fe6cbf>   DW_AT_ranges      : 0xe9bf20
    <1fe6cc3>   DW_AT_call_file   : 10
    <1fe6cc4>   DW_AT_call_line   : 1690

Inlined subroutine at 1fe6c9e doesn't have abstract origin, a name or a
declaration location. It's unclear whether this is in-standard and what
it even means.

Let's ignore it.

Fixes go-delve#1636
@aarzilli
Copy link
Member

Thank you for providing a binary.

cgxxv pushed a commit to cgxxv/delve that referenced this issue Mar 25, 2022
go-delve#1637)

GCC produces DW_TAG_inlined_subroutine entries without a
DW_AT_abstract_origin attribute.
From the bug report:

 <1><1fe6c7c>: Abbrev Number: 41 (DW_TAG_subprogram)
    <1fe6c7d>   DW_AT_external    : 1
    <1fe6c7d>   DW_AT_name        : (indirect string, offset: 0x485814): MultiGetImpl
    (omissis)
 <2><1fe6c9e>: Abbrev Number: 65 (DW_TAG_inlined_subroutine)
    <1fe6c9f>   DW_AT_low_pc      : 0x311023a
    <1fe6ca7>   DW_AT_high_pc     : 0x5
    <1fe6caf>   DW_AT_call_file   : 10
    <1fe6cb0>   DW_AT_call_line   : 1690
 <2><1fe6cb2>: Abbrev Number: 20 (DW_TAG_inlined_subroutine)
    <1fe6cb3>   DW_AT_abstract_origin: <0x1ffb534>
    <1fe6cb7>   DW_AT_entry_pc    : 0x311023f
    <1fe6cbf>   DW_AT_ranges      : 0xe9bf20
    <1fe6cc3>   DW_AT_call_file   : 10
    <1fe6cc4>   DW_AT_call_line   : 1690

Inlined subroutine at 1fe6c9e doesn't have abstract origin, a name or a
declaration location. It's unclear whether this is in-standard and what
it even means.

Let's ignore it.

Fixes go-delve#1636
abner-chenc pushed a commit to loongson/delve that referenced this issue Mar 1, 2024
go-delve#1637)

GCC produces DW_TAG_inlined_subroutine entries without a
DW_AT_abstract_origin attribute.
From the bug report:

 <1><1fe6c7c>: Abbrev Number: 41 (DW_TAG_subprogram)
    <1fe6c7d>   DW_AT_external    : 1
    <1fe6c7d>   DW_AT_name        : (indirect string, offset: 0x485814): MultiGetImpl
    (omissis)
 <2><1fe6c9e>: Abbrev Number: 65 (DW_TAG_inlined_subroutine)
    <1fe6c9f>   DW_AT_low_pc      : 0x311023a
    <1fe6ca7>   DW_AT_high_pc     : 0x5
    <1fe6caf>   DW_AT_call_file   : 10
    <1fe6cb0>   DW_AT_call_line   : 1690
 <2><1fe6cb2>: Abbrev Number: 20 (DW_TAG_inlined_subroutine)
    <1fe6cb3>   DW_AT_abstract_origin: <0x1ffb534>
    <1fe6cb7>   DW_AT_entry_pc    : 0x311023f
    <1fe6cbf>   DW_AT_ranges      : 0xe9bf20
    <1fe6cc3>   DW_AT_call_file   : 10
    <1fe6cc4>   DW_AT_call_line   : 1690

Inlined subroutine at 1fe6c9e doesn't have abstract origin, a name or a
declaration location. It's unclear whether this is in-standard and what
it even means.

Let's ignore it.

Fixes go-delve#1636
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants