Compile error using proto in code

[a3sroot]

What version of Garble and Go are you using?

$ garble version
1.19.3
$ go version
1.19.2

What environment are you running Garble on?

go env Output

$ go env

What did you do?

github.com/gogo/protobuf/proto
exit status 1,# github.com/gogo/protobuf/proto :1: cannot use new(struct{gAnS1ywh sync.ZhKsEoKJ; t5ZtpFMU map[int32]Extension}) (value of type *struct{gAnS1ywh uBuv_tzJ.ZhKsEoKJ; t5ZtpFMU map[int32]Extension}) as type *struct{mu uBuv_tzJ.ZhKsEoKJ; extensionMap map[int32]Extension} in assignment :1: cannot use new(struct{gAnS1ywh sync.ZhKsEoKJ; t5ZtpFMU map[int32]Extension}) (value of type *struct{gAnS1ywh uBuv_tzJ.ZhKsEoKJ; t5ZtpFMU map[int32]Extension}) as type *struct{mu uBuv_tzJ.ZhKsEoKJ; extensionMap map[int32]Extension} in struct literal exit status 2 # github.com/golang/protobuf/proto :2: unknown field 'Fuz2DW1T' in struct literal of type U9ByUkhc.H7qJWzJo exit status 2 exit status 2

What did you expect to see?

Normal compilation

What did you see instead?

[mvdan]

What command did you run, exactly? What was your GOGARBLE? Have you tried with GOGARBLE=*?

[chenxu2048]

I met the same problem, with GOGARBLE=*.
It seems like some package is not translated in github.com/gogo/protobuf/proto.

cannot use new(struct{jenTz2av sync.AzrdG1Dc; e4CKCV5a map[int32]Extension}) (value of type *struct{jenTz2av e5Bc0oaH.AzrdG1Dc; e4CKCV5a map[int32]Extension}) as type *struct{mu e5Bc0oaH.AzrdG1Dc; extensionMap map[int32]Extension} in assignment

The original codes in gogo/protobuf:

func NewUnsafeXXX_InternalExtensions(m map[int32]Extension) XXX_InternalExtensions {
	x := &XXX_InternalExtensions{
		p: new(struct {
			mu           sync.Mutex
			extensionMap map[int32]Extension
		}),
	}
	x.p.extensionMap = m
	return *x
}

And the codes generated with -debugdir:

func JJQBRarf(pKKAo9Lb map[int32]Extension) XXX_InternalExtensions {
        bugSTccM := &XXX_InternalExtensions{
                p:  /*line IHC2YGin.go:1*/ new(struct {
                        jenTz2av        sync.AzrdG1Dc
                        e4CKCV5a        map[int32]Extension
                }),
        }
        bugSTccM.p.extensionMap = pKKAo9Lb
        return *bugSTccM
}

The outputs show that it should be jenTz2av e5Bc0oaH.AzrdG1Dc at line 4, not jenTz2av sync.AzrdG1Dc.

[chenxu2048]

Codes are compiled with go version go1.19.2 linux/arm64.

[a3sroot]

GOGARBLE=* garble -literals -tiny -seed=2b2519936fa82dd90a7d9605ee69e2096dd5ee7a239bea5b6354231422d9daab build -trimpath -ldflags "-s -w -buildid="

[theaog]

I'm having the same issue

go version go1.19.4 darwin/amd64
mvdan.cc/garble v0.8.0

Build settings:
       -compiler gc
     CGO_ENABLED 1
          GOARCH amd64
            GOOS darwin
         GOAMD64 v1

GOOS=linux GOARCH=amd64 garble -tiny -literals build

# github.com/golang/protobuf/proto
:2: unknown field 'ZgAHbj18' in struct literal of type g1eviBJpW.EDZ_CfMOS
exit status 2

and it hangs there

[theaog]

solved by downgrading to v0.7.2

[mvdan]

I'm fully aware this is still an issue, by the way - I spent multiple hours debugging it last month but I couldn't spot the fix.

@theaog if an older version of garble works for you, could you try a git bisect to see if it was a regression in garble? Note that you'll have to set a specific GOGARBLE to get consistent behavior, as recent versions changed the default to GOGARBLE=* to obfuscate all packages.

[mvdan]

I'm not sure if this was a bug in garble or in Go, but it appears to be fixed with the latest master version of Go, golang/go@a5a4744.

From https://github.com/golang/protobuf at golang/protobuf@5d5e8c0, with garble as of 98466a1, I get a failure with Go 1.19.4:

$ go version
go version go1.19.4 linux/amd64
$ garble build ./proto
# github.com/golang/protobuf/proto
XK1R08EI.go:2: unknown field 'XEleVhsp5nazDb2' in struct literal of type RpNF0c1r39Zk.A7FyyEd8Xe
exit status 2
exit status 2

and success with Go at the master commit shown above:

$ go version
go version devel go1.20-a5a4744250 Mon Dec 19 21:17:00 2022 +0000 linux/amd64
$ garble build ./proto
[success]

I burned some CPU to bisect what change in upstream Go magically fixed the issue, and it points to https://go-review.googlesource.com/c/go/+/422235. It's not too surprising, since unified IR is meant to deduplicate code and fix subtle bugs or discrepancies in the toolchain.

I'm still unsure what exactly caused the problem, but I'm inclined to not spend more hours trying to investigate the cause if Go 1.20 will apparently fix it for us. As far as I can tell, we're not misusing Go libraries like go/types.

For those of you getting this error: could you please try Go 1.20rc1 and see if you still get the same error? You'll need to build garble with that version of Go as well.

[Techno-Fox]

I'm also having this error with garble version v0.9.1
The command

I wanted to test it without any literals, or tiny, just a build.

garble build

# github.com/golang/protobuf/proto
Sj40W8042Q.go:2: unknown field 'ECpZxVu' in struct literal of type hFpR5kL.ElHRx2K8vRcD
exit status 2
# github.com/gogo/protobuf/proto
B2GiuYvGxlV.go:1: cannot use new(struct{wNh7q9 sync.IQ9YbR; nFztqw4zeB map[int32]Extension}) (value of type *struct{wNh7q9 sync.IQ9YbR; nFztqw4zeB map[int32]Extension}) as type *struct{mu sync.IQ9YbR; extensionMap map[int32]Extension} in assignment
AsT7EP_HCu9.go:1: cannot use new(struct{wNh7q9 sync.IQ9YbR; nFztqw4zeB map[int32]Extension}) (value of type *struct{wNh7q9 sync.IQ9YbR; nFztqw4zeB map[int32]Extension}) as type *struct{mu sync.IQ9YbR; extensionMap map[int32]Extension} in struct literal
exit status 2
exit status 2

though, golang 1.20 release date, if I'm not wrong is 2nd of February 2023. Tomorrow. If and when it comes out, I'll try it again, and see if the error is still occurring.

[mvdan]

For what it's worth, you don't have to wait to try it out. Go 1.20-rc3 came out earlier this month.

[mvdan]

Ha, Go 1.20 is out now :) Narrowly missed it with the comment above.

[jomar83]

Still broken with 1.20 for me. Same error as reported by others. Go 1.20 and garble 0.9.3.

[theaog]

use the latest master: go install mvdan.cc/garble@master
using go1.20 and garblev0.9.4-0.20230212205717-9a8608f0611f
projects w/ proto compiled and work seamlessly

do a go clean -modcache before compiling, i used garble -tiny -literals build

[mvdan]

To confirm that this now works, CI now obfuscates the entire protobuf module as well. #682

[eyevanovich]

I'm not sure this is fixed. At least it isn't for me.
CGO_ENABLE=1 garble -literals -tiny -seed=random build ...
go version = 1.20.0
garble version = 0.9.3

and am getting

# github.com/gogo/protobuf/proto
:1: cannot use new(struct{oTk7xY2cZNt sync.LxXHV19Ip2; biFXyGHRei map[int32]Extension}) (value of type *struct{oTk7xY2cZNt sync.LxXHV19Ip2; biFXyGHRei map[int32]Extension}) as *struct{mu sync.LxXHV19Ip2; extensionMap map[int32]Extension} value in assignment
:1: cannot use new(struct{oTk7xY2cZNt sync.LxXHV19Ip2; biFXyGHRei map[int32]Extension}) (value of type *struct{oTk7xY2cZNt sync.LxXHV19Ip2; biFXyGHRei map[int32]Extension}) as *struct{mu sync.LxXHV19Ip2; extensionMap map[int32]Extension} value in struct literal
exit status 2
exit status 1

Note I've also tried to install from the master branch v0.9.4-0.20230228221609-6a8dda9b8e7f and have had no luck there either. Any help would be appreciated. Thanks.

[lu4p]

This is a separate issue already see #685

[dannywynn]

this is still aissuse i think.

[mvdan]

If so, raise a new issue following the template with reproduction steps.

[dannywynn]

If so, raise a new issue following the template with reproduction steps.

the issue is already opened #906 i use a package that use protobuf
and the package is in my vendor folder which is on root folder of project

i can't share the full reproduction steps, because its just a hello world program with this package whatsmeow

[dannywynn]

do you think vendor folder might be causing the panic ?
ps: i am not deeply familiar with golang

[mvdan]

OK. That is not a compiler error so it's an entirely different kind of issue. Please use #906 instead, and avoid replying in closed threads.