/cc @randall77 @griesemer

CC @thanm

Thanks, I'll take a look.

This is definitely an oddball of a bug.

The code in question is from https://github.com/unidoc/unipdf. For some reason, the author(s) of this code have run it through an obfuscating tool, which renames local variables and compacts a lot of code down into a single line. Here is the offending line of code in its original form:

func (_bbfa *PdfColorCalRGB )ToInteger (bits int )[3]uint32 {_fdbd :=_ag .Pow (2,float64 (bits ))-1;return [3]uint32 {uint32 (_fdbd *_bbfa .A ()),uint32 (_fdbd *_bbfa .B ()),uint32 (_fdbd *_bbfa .C ())};};func (_affae *PdfAppender )replaceObject (_agaf ,_adgf _aa .PdfObject ){switch _cecg :=_agaf .(type ){case *_aa .PdfIndirectObject :_affae ._dcbb [_adgf ]=_cecg .ObjectNumber ;case *_aa .PdfObjectStream :_affae ._dcbb [_adgf ]=_cecg .ObjectNumber ;};};

The function that triggers the problem is "replaceObject" above; prior to 1.16 we would not inline this function (since it contains a type switch). Now that we're inlining, it exposes a problem in the DWARF-gen code.

Here is a slightly smaller reproducer:

package a

type O interface{}
type IO int
type OS int

type A struct {
	x int
}

// original versions of the two functions
func (p *A) UO(o O) {
	p.r(o, o)
}
func (p *A) r(o1, o2 O) {
	switch x := o1.(type) {
	case *IO:
		p.x = int(*x)
	case *OS:
		p.x = int(*x + 2)
	}
}

// now the obfuscated versions
var myverylongname0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 int ; func (p *A) UO2(o O) { p.r2(o, o); }; func (p *A) r2(o1, o2 O) { switch x := o1.(type) { case *IO:	p.x = int(*x); 	case *OS: 	p.x = int(*x + 2); } }

The problem lies with type switch in the A.r method. For this switch the compiler manufactures a new PAUTO named "x" for each arm of the switch. Ordinarily these variables would be given a unique source position (that of the line of the associated "case" clause), but here due to the obfuscation each of the temps is given the same line number. In the source code above, the variables do have different columns, but in the current implementation of the Go parser/lexer the maximum allowable column number is 255.

As a result, the DWARF code winds up seeing two AUTO variables with the same name, file, line, and column (which it is not expecting).

Given the late stage of 1.16, probably the best way to handle this is by detecting this sort of breakdown in the DWARF code, as opposed to trying to do anything with the parser's handling of columns.

I'll work on putting together a CL.

Change https://golang.org/cl/294289 mentions this issue: cmd/compile: fix panic in DWARF-gen handling obfuscated code

@gopherbot please consider this for backport to 1.16

Backport issue(s) opened: #44433 (for 1.16).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

Change https://golang.org/cl/294789 mentions this issue: cmd/compile: fix panic in DWARF-gen handling obfuscated code

Change https://golang.org/cl/295129 mentions this issue: test: add test for issue 38698