text:
access: Approver Access to Oauth2

See https://golang.org/wiki/GerritAccess
I've been trying to merge a change to oauth2 package for a while now, and it's been very difficult to find enough people who are capable of giving Trust +1 and/or merging the branch, as some of the previous owners are no longer associated with this project, as recommended to me by @tbpg .  I'm working on new features for the project, and this is bottlenecking future changes too.
email: ithuriel@google.com
group url: https://go-review.googlesource.com/#/admin/groups/1005,members

/cc @golang/release

Any updates on this?

Any updates on this?

@cagedmantis you CC'd golang/release, but when I click on that link I get taken to a 404 page.  Did you reference the wrong thing?  My apologies for the bother.

@cagedmantis you CC'd golang/release, but when I click on that link I get taken to a 404 page.  Did you reference the wrong thing?  My apologies for the bother.

@gIthuriel The @golang/release team exists. We are reviewing the request. We are approaching a release and have been very busy with many tasks. I anticipate responding early next week. Thank you for your patience.

@gIthuriel The @golang/release team exists. We are reviewing the request. We are approaching a release and have been very busy with many tasks. I anticipate responding early next week. Thank you for your patience.

No worries- thanks for the clarification.  I just wanted to follow up and make sure that the thread didn't get lost in the weeds.

No worries- thanks for the clarification.  I just wanted to follow up and make sure that the thread didn't get lost in the weeds.

I'm not, sorry- I ended up transferring to work on some different projects.
On Tue, Aug 30, 2022 at 9:06 AM Heschi Kreinick @.***>
wrote:

Hi, looks like you haven't sent any CLs for quite a while. Are you still
interested in this?
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/42928#issuecomment-1231872215, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ARGUCISZZA54JVSVHX7K5SLV3YWPTANCNFSM4UJONLWQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

No problem, thanks for the response!

authors: cagedmantis gIthuriel heschi


text:
x/pkgsite: floating header obscures printout

If you go to a multipage doc like https://pkg.go.dev/github.com/google/go-cmp/cmp and print from Chrome, you can see in the PDF preview that the floating header is printed at the top of every page. Unfortunately, on all but the first page, the floating header is printed on top of actual text that would be useful to be able to read.
If I edit the page with Chrome to make the UnixFixedHeader div "display: none" then the printout is fine. So maybe doing that in print-specific CSS would be enough.

Yes, and we should also hide DocNavMobile, I'm working on it.

Thanks!

source: gharchive/issue

authors: oiooj rsc

repo: golang/go

license_type: permissive

license_source: github-api


text:
log: use sync.Pool to reduce allocations

What version of Go are you using (go version)?

$ go version
go version go1.16.3 darwin/arm64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.16.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.16.3/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build87690164=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Investigating a server application with a larger number of active log.Loggers (with different prefixes) I've noticed that memory consumption kept growing and pprof showed memory consumed in log.Output. It seems that the reason is the allocated, grow-only buffer in conjunction with extensive logging of e.g. HTTP traffic, see https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/log/log.go#L178.
What did you expect to see?
Flat memory consumption for logging, almost flat total.
What did you see instead?
Growing memory consumption as more live objects with expensive loggers are added.
I would like to suggest to make log.Logger use a sync pool like this:
var bufPool = sync.Pool{
	New: func() interface{} {
		return []byte{}
	},
}

where Output becomes:
	// l.buf = l.buf[:0]
	buf := bufPool.Get().([]byte)

        // as before
	l.formatHeader(&buf, now, file, line)
	buf = append(buf, s...)
	if len(s) == 0 || s[len(s)-1] != '\n' {
		buf = append(buf, '\n')
	}
	_, err := l.out.Write(buf)

        // put small buffers back
	if cap(buf) < 256 {
		bufPool.Put(buf[:0])
	}
	return err

That way particulary long log lines would no longer cause memory consumption at the cost of additional allocations. Might also chose a higher limit for putting resources back to the pool.
Would be happy to provide a PR.

Agreed this can be worked around. It still felt surprising that logging larger amounts of data actually added that data to the resident amount of program memory. If there were any real-life application test that I could validate I'd be happy to try and see if the proposed change could make a difference.


text:
expvar: BenchmarkRealworldExpvarUsage times out on specific arm64 server

This benchmark only get stuck in one type of our arm64/linux servers with n1 cpu and many cores.

What version of Go are you using (go version)?

$ go version
go version devel go1.17-8a7ee4c51e Mon Aug 2 17:18:57 2021 +0000 linux/arm64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/admin/.cache/go-build"
GOENV="/home/admin/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/admin/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/admin/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/admin/go-master"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/admin/go-master/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="devel go1.17-8a7ee4c51e Mon Aug 2 17:18:57 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/admin/go-master/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2046940622=/tmp/go-build -gno-record-gcc-switches"

What did you do?
go test -bench BenchmarkRealworldExpvarUsage -count 5

What did you expect to see?
Pass
What did you see instead?
The benchmark is stuck.
Linux kernel
Linux  5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
gcc version
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Debug with delve:
(dlv) goroutines
Goroutine 1 - User: /home/admin/go-master/src/testing/benchmark.go:284 testing.(*B).doBench (0xdf89c) [chan receive 451881h53m35.653003271s]
Goroutine 2 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [force gc (idle) 451881h53m39.747847302s]
Goroutine 3 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC sweep wait]
Goroutine 4 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC scavenge wait]
Goroutine 5 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [finalizer wait 451881h53m39.747877342s]
Goroutine 52 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747886983s]
Goroutine 53 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747895183s]
Goroutine 54 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747903383s]
Goroutine 55 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747913623s]
Goroutine 56 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747925623s]
Goroutine 57 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747933983s]
Goroutine 58 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747942263s]
Goroutine 59 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747951704s]
Goroutine 60 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747961824s]
Goroutine 61 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747970264s]
Goroutine 62 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747979704s]
Goroutine 63 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747991544s]
Goroutine 64 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.747999904s]
Goroutine 65 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748008384s]
Goroutine 66 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748023545s]
Goroutine 67 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748032265s]
Goroutine 68 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748061625s]
Goroutine 69 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748070545s]
Goroutine 70 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748078385s]
Goroutine 71 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748086826s]
Goroutine 72 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748097186s]
Goroutine 73 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748106586s]
Goroutine 74 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748116626s]
Goroutine 75 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748125946s]
Goroutine 76 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748134306s]
Goroutine 77 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748144986s]
Goroutine 78 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748154827s]
Goroutine 79 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748165027s]
Goroutine 80 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748174827s]
Goroutine 81 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748184147s]
Goroutine 82 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748193947s]
Goroutine 83 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748202787s]
Goroutine 84 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748212027s]
Goroutine 85 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748221588s]
Goroutine 86 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748232188s]
Goroutine 87 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748244028s]
Goroutine 88 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748252228s]
Goroutine 89 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748260308s]
Goroutine 90 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748269828s]
Goroutine 91 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748279348s]
Goroutine 92 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748289989s]
Goroutine 93 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748300709s]
Goroutine 94 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748310549s]
Goroutine 95 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748318669s]
Goroutine 96 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748326509s]
Goroutine 97 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 98 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748345669s]
Goroutine 99 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74835567s]
Goroutine 100 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74836411s]
Goroutine 101 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74837199s]
Goroutine 102 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74838067s]
Goroutine 103 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74839023s]
Goroutine 104 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74839907s]
Goroutine 105 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74840859s]
Goroutine 106 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74841655s]
Goroutine 107 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748423871s]
Goroutine 108 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748432151s]
Goroutine 109 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748440551s]
Goroutine 110 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748449031s]
Goroutine 111 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748457191s]
Goroutine 112 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748465551s]
Goroutine 113 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748474391s]
Goroutine 114 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748485111s]
Goroutine 115 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748493592s]
Goroutine 116 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748502192s]
Goroutine 117 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748511592s]
Goroutine 118 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748520192s]
Goroutine 119 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748530632s]
Goroutine 120 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748540752s]
Goroutine 121 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748550832s]
Goroutine 122 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748560273s]
Goroutine 123 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748570913s]
Goroutine 124 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748579593s]
Goroutine 125 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748588073s]
Goroutine 126 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748597713s]
Goroutine 127 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748608273s]
Goroutine 128 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748617753s]
Goroutine 129 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748630874s]
Goroutine 130 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748640954s]
Goroutine 131 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748650394s]
Goroutine 132 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748660274s]
Goroutine 133 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748669994s]
Goroutine 134 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748680314s]
Goroutine 135 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748693915s]
Goroutine 136 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748702435s]
Goroutine 137 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748710915s]
Goroutine 138 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748720075s]
Goroutine 139 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748730115s]
Goroutine 146 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748740875s]
Goroutine 147 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748751075s]
Goroutine 148 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748760156s]
Goroutine 149 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748768356s]
Goroutine 150 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748778196s]
Goroutine 151 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748788436s]
Goroutine 152 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748798476s]
Goroutine 153 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748808636s]
Goroutine 154 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748818556s]
Goroutine 155 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748827637s]
Goroutine 156 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748838517s]
Goroutine 157 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748848757s]
Goroutine 158 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748859077s]
Goroutine 159 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748869117s]
Goroutine 160 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 161 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627432639s]
Goroutine 162 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748898598s]
Goroutine 163 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748908478s]
Goroutine 164 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748918318s]
Goroutine 165 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748927558s]
Goroutine 166 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748937438s]
Goroutine 167 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.748945398s]
Goroutine 168 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 169 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 170 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627519241s]
Goroutine 171 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 172 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 173 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 174 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 175 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 178 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74902396s]
Goroutine 179 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m39.74903464s]
Goroutine 180 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 181 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 182 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627607802s]
Goroutine 183 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 184 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627626442s]
Goroutine 185 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 186 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.600443748s]
Goroutine 187 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.600454228s]
Goroutine 188 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 189 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 190 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.600479148s]
Goroutine 191 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 194 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.600496028s]
Goroutine 195 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 196 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627716044s]
Goroutine 197 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627723444s]
Goroutine 198 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 199 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 200 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 201 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 202 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 203 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 204 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 205 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 206 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 207 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 208 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 209 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 210 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627831965s]
Goroutine 211 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 212 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 213 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.654495733s]
Goroutine 214 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 215 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 216 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627880726s]
Goroutine 217 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 226 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.627897966s]
Goroutine 227 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle) 451881h53m35.654545534s]
Goroutine 228 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 229 - User: /home/admin/go-master/src/runtime/proc.go:367 runtime.gopark (0x4b52c) [GC worker (idle)]
Goroutine 4162 - User: /home/admin/go-master/src/runtime/sema.go:56 sync.runtime_Semacquire (0x79b58) [semacquire]
Goroutine 5978 - User: /home/admin/go-master/src/runtime/netpoll.go:229 internal/poll.runtime_pollWait (0x782e4) [IO wait]
[167 goroutines]
(dlv) goroutine 5978
Switched from 0 to 5978 (thread 3744652)
(dlv) bt
0  0x000000000004b52c in runtime.gopark
at /home/admin/go-master/src/runtime/proc.go:367
1  0x0000000000043568 in runtime.netpollblock
at /home/admin/go-master/src/runtime/netpoll.go:445
2  0x00000000000782e4 in internal/poll.runtime_pollWait
at /home/admin/go-master/src/runtime/netpoll.go:229
3  0x00000000000a13f8 in internal/poll.(*pollDesc).wait
at /home/admin/go-master/src/internal/poll/fd_poll_runtime.go:84
4  0x00000000000a1cc4 in internal/poll.(*pollDesc).waitRead
at /home/admin/go-master/src/internal/poll/fd_poll_runtime.go:89
5  0x00000000000a1cc4 in internal/poll.(*FD).Read
at /home/admin/go-master/src/internal/poll/fd_unix.go:167
6  0x0000000000160014 in net.(*netFD).Read
at /home/admin/go-master/src/net/fd_posix.go:56
7  0x000000000016ad5c in net.(*conn).Read
at /home/admin/go-master/src/net/net.go:183
8  0x00000000001a2008 in expvar.BenchmarkRealworldExpvarUsage.func5
at ./expvar_test.go:588
9  0x000000000007d0c4 in runtime.goexit
at /home/admin/go-master/src/runtime/asm_arm64.s:1133

cc @bradfitz

The goroutines wedged in GC worker (idle) look a lot like #47511.

Is this a regression in Go 1.17, or does this test also wedge on the latest Go 1.16 release?

@bcmills was there a different issue you want to reference?

Argh, yeah. I meant #47505.

Is this a regression in Go 1.17, or does this test also wedge on the latest Go 1.16 release?

I just tried Go 1.16.6, the answer is yes.

Yes it's a regression, or yes it reproduces on 1.16.6? 😅

Yes it's a regression, or yes it reproduces on 1.16.6? 😅

Sorry for the confusion, it reproduces on 1.16.6.

After verification, this problem has disappeared, so close this issue.

authors: bcmills erifan seankhliao


text:
cmd/compile: missing debug information for return values of runtime functions

What version of Go are you using (go version)?

$ go version
go version go1.17 windows/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Michael.Obermueller\AppData\Local\go-build
set GOENV=C:\Users\Michael.Obermueller\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Michael.Obermueller\go\pkg\mod
set GONOPROXY=...
set GONOSUMDB=...
set GOOS=windows
set GOPATH=C:\Users\Michael.Obermueller\go
set GOPRIVATE=...
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\workspaces\devtools\go\go-master
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\workspaces\devtools\go\go-master\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\workspaces\repos\go-world\src\GoWorld\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\MICHAE~1.OBE\AppData\Local\Temp\go-build2406948064=/tmp/go-build -gno-record-gcc-switches
GOROOT/bin/go version: go version go1.17 windows/amd64
GOROOT/bin/go tool compile -V: compile version go1.17

What did you do?
Build an application with the Go 1.17 toolchain using command go build -gcflags=all="-N -l" HelloWorld.go:
package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

The DWARF information for Go functions defined in the runtime package does not contain DW_TAG_formal_parameter entries for return values. I have checked multiple runtime functions, for all of them I see the same problem. As an example let's check runtime.mapaccess2 which has the following signature:
func mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool)
What did you expect to see?
DW_TAG_formal_parameter entries for the two return values of runtime.mapaccess2
If I build the program with Go 1.16.8 toolchain the return value entries exist:

DWARF Go 1.16.8
debug_1_16_8.txt:
 <1><be36>: Abbrev Number: 3 (DW_TAG_subprogram)
    <be37>   DW_AT_name        : runtime.mapaccess2
    <be4a>   DW_AT_low_pc      : 0x40f9c0
    <be52>   DW_AT_high_pc     : 0x40fd2a
    <be5a>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <be5c>   DW_AT_decl_file   : 0x26
    <be60>   DW_AT_external    : 1
 <2><be9a>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <be9b>   DW_AT_name        : t
    <be9d>   DW_AT_variable_parameter: 0
    <be9e>   DW_AT_decl_line   : 452
    <bea0>   DW_AT_type        : <0x39b60>
    <bea4>   DW_AT_location    : 0xa10c (location list)
 <2><bea8>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <bea9>   DW_AT_name        : h
    <beab>   DW_AT_variable_parameter: 0
    <beac>   DW_AT_decl_line   : 452
    <beae>   DW_AT_type        : <0x39b7f>
    <beb2>   DW_AT_location    : 0xa13f (location list)
 <2><beb6>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <beb7>   DW_AT_name        : key
    <bebb>   DW_AT_variable_parameter: 0
    <bebc>   DW_AT_decl_line   : 452
    <bebe>   DW_AT_type        : <0x34320>
    <bec2>   DW_AT_location    : 0xa173 (location list)
 <2><bec6>: Abbrev Number: 15 (DW_TAG_formal_parameter)
    <bec7>   DW_AT_name        : ~r3
    <becb>   DW_AT_variable_parameter: 1
    <becc>   DW_AT_decl_line   : 452
    <bece>   DW_AT_type        : <0x34320>
    <bed2>   DW_AT_location    : 0 byte block: 	()
 <2><bed3>: Abbrev Number: 15 (DW_TAG_formal_parameter)
    <bed4>   DW_AT_name        : ~r4
    <bed8>   DW_AT_variable_parameter: 1
    <bed9>   DW_AT_decl_line   : 452
    <bedb>   DW_AT_type        : <0x344ba>
    <bedf>   DW_AT_location    : 0 byte block: 	()
...

What did you see instead?
With Go 1.17 toolchain the return value entries are missing:

DWARF Go 1.17
debug.txt:
 <1><f8bc>: Abbrev Number: 3 (DW_TAG_subprogram)
    <f8bd>   DW_AT_name        : runtime.mapaccess2
    <f8d0>   DW_AT_low_pc      : 0x40dc60
    <f8d8>   DW_AT_high_pc     : 0x40df30
    <f8e0>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <f8e2>   DW_AT_decl_file   : 0x27
    <f8e6>   DW_AT_external    : 1
 <2><f8e7>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <f8e8>   DW_AT_name        : t
    <f8ea>   DW_AT_variable_parameter: 0
    <f8eb>   DW_AT_decl_line   : 452
    <f8ed>   DW_AT_type        : <0x45c77>
    <f8f1>   DW_AT_location    : 0xf86c (location list)
 <2><f8f5>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <f8f6>   DW_AT_name        : h
    <f8f8>   DW_AT_variable_parameter: 0
    <f8f9>   DW_AT_decl_line   : 452
    <f8fb>   DW_AT_type        : <0x45c96>
    <f8ff>   DW_AT_location    : 0xf8b2 (location list)
 <2><f903>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <f904>   DW_AT_name        : key
    <f908>   DW_AT_variable_parameter: 0
    <f909>   DW_AT_decl_line   : 452
    <f90b>   DW_AT_type        : <0x3ffa9>
    <f90f>   DW_AT_location    : 0xf920 (location list)
 ...

This might be related to #46845.

CC @thanm

Thanks. As mentioned in #46845, when you build with go build -gcflags=all="-N -l", the Go command is intentionally not disabling optimization for the runtime, since there are runtime functions that have to be built with optimization to function correctly.
With that said, it seems odd that the return params are missing entirely (as opposed to being present, but not having accurate location expressions). I'll take a look and see if I can figure out what the issue is.

Some background material on this bug:
When optimization is turned on, the DWARF-gen code that emits variable and formal_parameter DIEs draws info from two places: the SSA name table, and the "Dcl" slice for the function (code here), which has entries for in and out parameters and locals for the function.
The general rule is that if a variable is SSA-able, it will get entered into the SSA name table, and will be incorporated into the DWARF by the locationlists code. If a var is not in the SSA name table, then dwarfgen will pick it up from the "Dcl" slice for the function.
Here's an example function:
  func foo(x int, s string, b GiantBlob, unusedParam [128]byte) uintptr {
    var unusedLocal [15]string
    ...
  }

For this function "x" and "s" are passed in register, "b" and "unusedParam" are passed on the stack.
At SSA construction time, the "Dcl" slice for function foo will contain entries for all of the vars above, e.g.
	Name		Class
	x		PARAM
	s		PARAM
	b		PARAM
	unusedParam	PARAM
	~r0		PARAMOUT
	unusedLocal	AUTO
	...

After we enter SSA and optimization starts, the back end will optimize things away, remove dead code, etc, until we arrive at the "stackframe" SSA pass. This pass sorts locals by size and assigns concrete offsets to things in the stack frame, and will prune away autos from the Dcl list that are no longer referenced (code here).  The upshot is that if a variable gets pruned by "stackframe" because it is unused (and also doesn't appear in the SSA name table) then we don't emit a DWARF DIE for it (as with "unusedLocal" above).
During the register ABI work, a change was made in CL 302071 to "stackframe" to treat register-resident output parameter (PARAMOUT) variables that same as locals, which meant that if they were unused, we'd delete them from the "Dcl" slice.
The second thing that happened during the register ABI work is that we changed the code emitted by the back end for "return" statements changed. Whereas before a statement like
  return 42

would be lowered to a store into the PARAMOUT variable (e.g. "~r0"), with the register ABI turned on this code would be lowered into a "MakeResult" op, which doesn't refer to the PARAMOUT variable at all.
Bottom line is that we now skip PARAMOUT vars during DWARF variable DIE generation unless they are not register-resident, since they no longer appear either the SSA name table or the "Dcl" slice.
There are a couple of different ways we could fix this bug. One possibility would be to just cache away a copy of the pre-optimization "Dcl" slice and use that as a way to pick up PARAMOUT nodes. A second possibility would be to move away from using the "Dcl" slice entirely, and instead operate off the function signature type itself (since the optimizer is not going to be messing with that). The one pothole/wrinkle there is that the DWARF param/var DIE includes DeclLine and DeclFile attributes, and we can't get that sort of info just from the signature type.

authors: PeterFeicht ianlancetaylor michael-obermueller thanm


text:
internal/fuzz: generated corpus not being run before fuzzing

It looks like there is a regression with the beta2 where the generated corpus is not being run before fuzzing begins.
This also means that we have a gap in our testing that needs to be fixed as well.
It can be shown with two fuzzing executions back to back:
➜ go test -fuzz=Fuzz
fuzz: elapsed: 0s, gathering baseline coverage: 0/4 completed
fuzz: elapsed: 0s, gathering baseline coverage: 4/4 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 353778 (117925/sec), new interesting: 31 (total: 31)
fuzz: elapsed: 6s, execs: 977881 (208033/sec), new interesting: 35 (total: 35)
PASS
ok      example/fuzz    9.176s

35 entries were added to the generated corpus
➜ go test -fuzz=Fuzz
fuzz: elapsed: 0s, gathering baseline coverage: 0/4 completed
fuzz: elapsed: 0s, gathering baseline coverage: 4/4 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 452608 (150863/sec), new interesting: 31 (total: 31)
fuzz: elapsed: 6s, execs: 1025174 (190850/sec), new interesting: 35 (total: 35)
fuzz: elapsed: 9s, execs: 1554990 (176613/sec), new interesting: 35 (total: 35)
fuzz: elapsed: 12s, execs: 2087450 (177490/sec), new interesting: 37 (total: 37)
PASS
ok      example/fuzz    12.994s

Note that only 4 entries were run for the baseline coverage, which is the size of the seed corpus. So the generated corpus wasn't run.

Ah, this is a dupe of Issue #50913 and has been fixed.


text:
x/tools/gopls:

gopls version
golang.org/x/tools/gopls v0.9.3
golang.org/x/tools/gopls@v0.9.3 h1:wfh4cfJAKwOG49sCE4ldafYeD5rlejE/gJQ7JAR5yX0=
go env

What did you do?
I tries to invoke a go language specific function is vscode such as "Go To Definition" for a function.77
Ever since version 0.9.2 was released (and 0.9.3 as well).  I am not able to use any go language specific functions in vscode.  If I try to "Go To Definition" in a go file, I see the following error in the Developer tools Window:
What did you expect to see?
I expected VSCODE to position itself on source code for the function.
What did you see instead?
VSCODE displays an endless progress bar and display the following error message in developer tools window:
workbench.desktop.main.js:2279 Error: Header must provide a Content-Length property.
at StreamMessageReader.onData
Editor and settings
I have seen this behaviour it the two latest version 0.9.2 and 0.9.3 when I go back to version 0.9.1 everything returns to normal function.
Logs

Thank you for the issue.
This is golang/vscode-go#2406: a new vet analyzer contains a print statement that breaks jsonrpc2 communication in gopls.
It will be fixed on Monday. We only discovered this midday on Friday, and do not release over the weekend.
Sorry for the breakage.

"Sorry for the breakage"
Thanks for everything that does work - It's great.

:heart: thanks.
BTW, if you hit this bug, your project contains a time format string containing "2006-02-01" instead of "2006-01-02", which is probably incorrect (c.f. #48801)

authors: findleyr zvisavvy


text:
x/website: use of deprecated math/rand.Seed in the tutorial docs

What is the URL of the page with the issue?
https://go.dev/doc/tutorial/random-greeting
What is your user agent?
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Screenshot

What did you do?
Followed the introductory tutorials
What did you expect to see?
n/a
What did you see instead?
Code examples that produced warnings from the go-staticcheck linter based on #56319 or #54880

rand.Seed has been deprecated since Go 1.20 and an alternative has been available since Go 1.0: Programs that call Seed and then expect a specific sequence of results from the global random source (using functions such as Int) can be broken when a dependency changes how much it consumes from the global random source. To avoid such breakages, programs that need a specific result sequence should use NewRand(NewSource(seed)) to obtain a random generator that other packages cannot access.  (SA1019)go-staticcheck

The math/rand module's documentation

Can I work on this?

authors: RemoteSalad adityakode


text:
x/tools/gopls: rename crashes in objectpath

I found this while snooping around in 'gopls stats'. This is v0.12.0.
objectpath.Object(package cache ("golang.org/x/tools/gopls/internal/lsp/cache"), analysisNode.M0) failed: package golang.org/x/tools/gopls/internal/lsp/cache does not contain "analysisNode",
goroutine 7388370 [running]:
runtime/debug.Stack()
	/Users/adonovan/w/homebrew/Cellar/go/1.20.4/libexec/src/runtime/debug/stack.go:24 +0x64
golang.org/x/tools/gopls/internal/bug.report({0x14012efb5c0, 0xbd})
	/Users/adonovan/w/xtools/gopls/internal/bug/bug.go:83 +0xd8
golang.org/x/tools/gopls/internal/bug.Reportf({0x10150a4f8?, 0xf?}, {0x1400d086ff0?, 0x14011a2c580?, 0x1018a58a0?})
	/Users/adonovan/w/xtools/gopls/internal/bug/bug.go:49 +0x28
golang.org/x/tools/gopls/internal/lsp/source.renameExported({0x10191e6c8, 0x140130c40f0}, {0x10192b010, 0x14016d08000}, {0x1400d5a9600, 0x1f, 0x1400d0872b8?}, {0x14028ed6f60, 0x2b}, {0x14024d66950, ...}, ...)
	/Users/adonovan/w/xtools/gopls/internal/lsp/source/rename.go:577 +0x3a0
golang.org/x/tools/gopls/internal/lsp/source.renameOrdinary({0x10191e6c8, 0x140130c40f0}, {0x10192b010, 0x14016d08000}, {0x10191f560, 0x1400a0bc6c0}, {0xd087508?, 0x140?}, {0x1400fd2f5e0, 0x7})
	/Users/adonovan/w/xtools/gopls/internal/lsp/source/rename.go:430 +0x6bc
golang.org/x/tools/gopls/internal/lsp/source.Rename({0x10191e6c8?, 0x1401f9fbf80?}, {0x10192b010, 0x14016d08000}, {0x10191f560, 0x1400a0bc6c0}, {0xd6f0960?, 0x140?}, {0x1400fd2f5e0, 0x7})
	/Users/adonovan/w/xtools/gopls/internal/lsp/source/rename.go:234 +0x120
golang.org/x/tools/gopls/internal/lsp.(*Server).rename(0x140204cbb00?, {0x10191e620, 0x1400998c690}, 0x140204cbb00)
	/Users/adonovan/w/xtools/gopls/internal/lsp/rename.go:29 +0x1a4
golang.org/x/tools/gopls/internal/lsp.(*Server).Rename(0x1401a4b6140?, {0x10191e620?, 0x1400998c690?}, 0x1017a5d80?)
	/Users/adonovan/w/xtools/gopls/internal/lsp/server_gen.go:208 +0x24
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x10191e620, 0x1400998c690}, {0x10192dd28, 0x140001db040}, 0x1401f9fbe90, {0x10191e8f8, 0x140002a3400})
	/Users/adonovan/w/xtools/gopls/internal/lsp/protocol/tsserver.go:515 +0xb6c
golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x10191e620, 0x1400998c690}, 0x1401f9fbe90, {0x10191e8f8, 0x140002a3400})
	/Users/adonovan/w/xtools/gopls/internal/lsp/protocol/protocol.go:157 +0x6c
golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x10191e620, 0x1400998c690}, 0x1401f9fbe90, {0x10191e8f8?, 0x140002a3400?})
	/Users/adonovan/w/xtools/gopls/internal/lsp/lsprpc/lsprpc.go:519 +0x768
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x10191e620, 0x1400998c690}, 0x1400e7b06d8, {0x10191e8f8?, 0x140002a3400?})
	/Users/adonovan/w/xtools/internal/jsonrpc2/handler.go:35 +0xf0
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()
	/Users/adonovan/w/xtools/internal/jsonrpc2/handler.go:103 +0x90
created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1
	/Users/adonovan/w/xtools/internal/jsonrpc2/handler.go:100 +0x1dc

I can reproduce this at master by renaming (*cache.analysisNode.String) to String2.

I think the root cause is the behavior of the objectpath package.  Given a syntax package containing an unexported type with an exported method, objectpath.For(obj) will succeed and return a path, even if the unexported type is not reachable from any exported declaration. The resulting path will cause objectpath.Object(path, pkg) to fail if pkg was loaded from export data. I'm not sure whether that's that a bug or a feature.

I'm not sure whether that's that a bug or a feature.

I think that's a bug. IMO objectpath.Object should work for any non-empty path returned by objectpath.For. Can we "fix" this by failing objectpath.For in these cases?

authors: adonovan findleyr


text:
go/types: interface.Complete panics for interfaces with duplicate methods

gopls version: v0.13.1 (go1.20.4)
gopls flags:
update flags: proxy
extension version: 0.39.1
go version: 1.20.4
environment: Visual Studio Code darwin
initialization error: undefined
issue timestamp: Thu, 03 Aug 2023 05:31:10 GMT
restart history:
Wed, 02 Aug 2023 07:06:29 GMT: activation (enabled: true)
ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.
Describe what you observed.

panic: 41710: duplicate method GetByID

goroutine 9767 [running]:
go/types.computeInterfaceTypeSet.func2(0xa2ee, 0x14008235980, 0x1)
	  typeset.go:230  0x570
go/types.computeInterfaceTypeSet(0x0, 0x101123495%3F, 0x140081d3770)
	  typeset.go:257  0x21c
go/types.(*Interface).typeSet(...)
	  interface.go:29
go/types.(*Interface).Complete(...)
	  interface.go:143
golang.org/x/tools/gopls/internal/lsp/cache.typeCheckImpl({0x101576968, 0x140098a8810}, 0x10093fec0%3F, {{0x140015439c8, 0x15}, {0x140015439c8, 0x15}, {0x14001597000, 0x3}, {0x14008de5540, ...}, ...})
	  check.go:1481  0x6f8
golang.org/x/tools/gopls/internal/lsp/cache.(*typeCheckBatch).checkPackage(0x1400d6c6ec8%3F, {0x101576968, 0x140090556b0}, 0x140093dde60)
	  check.go:674  0x190
golang.org/x/tools/gopls/internal/lsp/cache.(*typeCheckBatch).handleSyntaxPackage(0x14007d21da0, {0x101576968, 0x140090556b0}, 0x14000995e00%3F, {0x140015439c8, 0x15})
	  check.go:532  0x3f4
golang.org/x/tools/gopls/internal/lsp/cache.(*snapshot).forEachPackageInternal.func2()
	  check.go:394  0x34
golang.org/x/sync/errgroup.(*Group).Go.func1()
	  errgroup.go:75  0x5c
created by golang.org/x/sync/errgroup.(*Group).Go
	  errgroup.go:72  0xa0
[Error - 12:35:43 PM]
OPTIONAL: If you would like to share more information, you can attach your complete gopls logs.
NOTE: THESE MAY CONTAIN SENSITIVE INFORMATION ABOUT YOUR CODEBASE.
DO NOT SHARE LOGS IF YOU ARE WORKING IN A PRIVATE REPOSITORY.
<OPTIONAL: ATTACH LOGS HERE>

@gopherbot please backport to Go 1.21. This is a deterministic panic when correctly using the go/types API.

@gopherbot please backport to Go 1.20. This is a deterministic panic when correctly using the go/types API.

authors: findleyr istonegithub


text:
proposal: text/template: annotations to enable static checking of syntax and semantics

Proposal Details
(As they say in the movie business, this is only an idea, not yet a concept.)
Go's text/template package defines a dynamically typed sublanguage for templates, analogous to---but much richer than---the sublanguage of fmt.Printf. It would be convenient for template users if their LSP-enabled editor could give them real-time feedback of syntax and type errors while they are editing, just as it does for Go code or for the untyped sublanguage of fmt.Printf.
In some cases it's easy to detect statically that a string literal is passed to template.Parse and is thus subject to discipline of the template parser. In other cases it's trickier because of the complex flow of template string values through the program, or because the templates are in standalone files, perhaps loaded via go:embed. But parsing is only the first step: the parsed template then flows to a call to Execute, along with an operand value and perhaps also with a FuncMap that maps various names to functions. A static checking tool would need to know the template literal, the keys and value types of the FuncMap, and the type of the operand, in order to perform semantic checks on the template.
One approach, taken by the GoLand IDE (https://www.jetbrains.com/help/go/integration-with-go-templates.html), is to require the user to write special comments in the template to indicate the type of the corresponding Go operand. This is a good start, and I imagine that many users are willing to pay the cost of modifying their templates to benefit from improved static checking. But I wonder whether we can take this approach a step further by declaring a standard form for the necessary type annotations, one that would support FuncMaps as well. In the general case, value flow---of template strings, parsed templates, FuncMaps, and operand values--can be arbitrarily complex, but in most cases I suspect the relationships are simple enough that a few heuristics would go a long way.
For example, this case could be supported without annotations:
const src = `{{..template..}}`

var t *template.Template

func parse(bonusFeature bool) {
        fm := template.FuncMap{
   	   "foo":  foo,
	   ...
	}
	if bonusFeature {
	     fm["bonus"] = bonus
	}
        t, _ = template.New("name").Parse(src).Funcs(fm)
}

func expand(x *MyData) {
        t.Execute(os.Stdout, x)
})

func foo(string) int
func bonus(string) string

An analyzer could infer that t was parsed from src, with functions "foo" of type func(string) int and (optionally) "bonus" of type func(int) string, enabling static checking of its syntax and inference of a fancy type for t. The call in expand would combine this fancy type with the type of the operand x and report semantic errors.
But its easy to imagine more complex logic surrounding src, fm, t, and x that obfuscates the checker. The purpose of this issue is to gather ideas about what kinds of relationships it would be necessary to express using an annotation mechanism, to come up with a design, and evaluate an experimental implementation.

TIL that @jba, who sits a mere jellybean-throw away from me, wrote https://pkg.go.dev/github.com/jba/templatecheck, which looks highly relevant.

I see this idea as complementary to the templatecheck package.
If you just want to be pretty sure that your template won't crash in production, then running templatecheck in tests suffices, as we do for pkgsite. It's not perfect. The biggest hole is sub-templates established with define: you have to check those separately by providing a type (search for subs in the code I linked above), and templatecheck does not verify that all calls to the sub-template pass that type.
Of course, test time is too late to provide in-editor syntax checking.
I recently added "strict" checking to templatecheck, which guarantees no type errors provided you stick to restricted semantics. Again, the biggest restriction is passing the same type in every call to a sub-template.
The type CheckedTemplate[T] denotes a template that has satisfied strict checking. Its Execute method accepts values only of type T. If a static analyzer observes a CheckedTemplate[T] and can associate the template text with it, then it should have an easy job. I don't think any annotations in the template text would be needed.
In general, I think the most valuable annotations, and maybe the only ones you'd need, are for the types of sub-templates (and perhaps the main template). I think if you had those then you could derive all the other types, and I think uses of the more relaxed template semantics will be rare outside of passing different types to (sub-)templates. For example, I'd be surprised if there were many instances where the same variable was assigned values of different types, or where an and call whose arguments were of different types was used for its actual value rather than its truth-value.
But I see that GoLand lets you write a type for any part of a template, so maybe I'm wrong about that.

authors: adonovan jba


text:
cmd/compile: the execution order of init functions from different packages is incorrect

Go version
go version devel go1.22-b7c630dc3a
Output of go env in your module/workspace:
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Wingrez\AppData\Local\go-build
set GOENV=C:\Users\Wingrez\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=D:\workspace\my\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=*
set GOOS=windows
set GOPATH=D:\workspace\my\go
set GOPRIVATE=
set GOPROXY=http://cmc-cd-mirror.rnd.huawei.com/goproxy,direct
set GOROOT=D:\workspace\git\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=D:\workspace\git\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=devel go1.22-b7c630dc3a Tue Jan 9 01:36:54 2024 +0000
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\Wingrez\AppData\Local\Temp\go-build3833231449=/tmp/go-build -gno-record-gcc-switches

What did you do?
I compiled the same code using go1.22 and go1.19.3, but the results were different.
This is my code:
main.go
package main

import (
    _ "demo/pkg2"
    _ "demo/pkg1"
)

func init() {
    println("init-main")
}

func main() {
    println("main")
}

pkg1/init.go
package pkg1

func init() {
    println("init from pkg1")
}

pkg2/init.go
package pkg2

func init() {
    println("init from pkg2")
}

What did you see happen?
Using go1.19.3, the result is:
init from pkg2
init from pkg1
init-main
main

Using go1.22, the result is:
init from pkg1
init from pkg2
init-main
main

What did you expect to see?
I think the result from go1.19.3 is correct. Not sure if Go's specifications have changed.

Yes, this was changed recently. From the 1.21 release notes:

package initialization order is now specified more precisely. The new algorithm is:
Sort all packages by import path.
Repeat until the list of packages is empty:

Find the first package in the list for which all imports are already initialized.
Initialize that package and remove it from the list.

This may change the behavior of some programs that rely on a specific initialization ordering that was not expressed by explicit imports. The behavior of such programs was not well defined by the spec in past releases. The new rule provides an unambiguous definition.

Closing as this is working as intended.

authors: ALTree wingrez


text:
cmd/vet: warn when shadowing variable with slices.Delete and friends

Proposal Details
When calling slices.Delete, shadowing the slice variable is almost certainly a bug:
s := slices.Delete(s, 2, 3)  // !! accidentally using := instead of = !!

Playground
Why
Shadowing comes with surprises when used accidentally. In general, vet cannot warn about it because it does not know if a specific use of shadowing is intentional and legit, or not.
Shadowing keeps the original var intact, so it can be reused outside of the current inner scope where the new var is declared. In the specific case of Delete (and friends), we know that reusing the original value is not desirable:
"When calling these functions (Delete. etc.) we must consider the original slice invalid"
I am not aware of any such shadowing that would be legit and useful. If they do exist, the vet warning would be easy to work around by choosing a different var identifier (no shadowing).
On the other hand, I am very aware of the nasty bugs caused by accidental shadowing in general, and by accidental shadowing in the case of slices.Delete and friends.
Suggestion
vet warning:
./prog.go:11:14: shadowing slice 's' on call to slices.Delete

Same for the friends DeleteFunc, Compact, CompactFunc, Replace.
Like #62729, the goal is to minimize the risks associated with incorrectly using the slices package API.

Per cmd/vet/README, vet checks have three criteria: correctness, frequency, and precision.  Is this a mistake that is frequent enough to be worth a vet check?
Separately, if we do this, what about s := append(s, ...)?

For the frequency, I have yet to collect evidence data.
For append, there is a strong difference. append does not dictate who should own the original slice. The ownership concern is on the user. Many legit patterns are used where the caller "knows" in this case append won't reallocate, or "knows" in this case append will reallocate. append is not destructive for the original contents s[0:len(s)], so in many cases other references to the original slice can still expect its content to be intact, which is fine at least for reading.
slices.Delete is destructive and invalidates all references to the original slice (which then contains previously-undefined garbage at the end, now-defined zeros at the end).

I don't think it's as clear as that. A slice has value beyond it's content, you might need to keep the original slice around because you are reusing it's underlying backing array to reduce allocations in your code.

@Jorropo brings up a good point that one can reuse allocations. We would never want to warn on functions that takes a slice as a buffer to use:
func Foo(x, y []string) {
  s := make([]byte, 0, max(len(x), len(y)))
  PossiblyDeleteWithinSlice(s, x)
  PossiblyDeleteWithinSlice(s, y)
}

Is function scope so different than shadowing in blocks? Well yes, but it is reason to be cautious about precision here.
s := append(s, ...) has more obvious uses. Such as the prefix is still valid in a given scope, but not in the outer scope so a 'pop' is implicit for correctness.

Formally, the caller of s := slices.Delete(s, i, j) may assume s[0:i] will be kept unchanged and may want to "share ownership" of s[0:i] with other slice variables. But the original (shadowed) s itself now contains zeroed garbage at the end.
It seems for any useful purpose s = slices.Delete(s, i, j) is better than, or as good as, using :=.
If the original s is a scratch buffer, and the caller wants its size to not be changed, and its exact contents at the end doesn't matter, and the go vet warning is annoying, then using a new identifier t := slices.Delete(s, i, j) should be fine.

authors: Deleplace Jorropo ianlancetaylor timothy-king


text:
net.ParseMAC: invalid MAC address with missing leading zeroes

Go version
1.21.9
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/home/janderson/.cache/go-build'
GOENV='/home/janderson/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/janderson/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/janderson/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/golang'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.21.9 (Red Hat 1.21.9-2.el9_4)'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/janderson/warewulf.git/tree/main/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1065685934=/tmp/go-build -gno-record-gcc-switches'

What did you do?
package main

import (
	"fmt"
	"net"
)

func main() {
	hw, err := net.ParseMAC("44:11:0c:ae:43:b2")
	fmt.Printf("hw: %v\n", hw)
	fmt.Printf("error: %v\n", err)
}

Originally reported at https://github.com/warewulf/warewulf/issues/1293

Although one may find it unusual to write a MAC address without leading zeros, this is what you get from getent ethers

What did you see happen?
hw:
error: address 44:11:c:ae:43:b2: invalid MAC address

What did you expect to see?
hw: 44:11:0c:ae:43:b2
error: <nil>

Related Issues

net: real MAC address cannot be obtained after a NIC is bound on linux #47828
net.Interfaces on Linux have null-terminated Names #1942 (closed)
proposal: net: ParseIP should return an error, like other Parse functions #18757 (closed)
net: reject leading zeros in IP address parsers [freeze exception] #30999 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Based on IEEE reference material (MAC addresses being IEEE EUI-48):

https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/macgrp.pdf
https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf

I don't see any provision allowing for omitting leading zeros, see also #66682

authors: anderbubble gabyhelp seankhliao


text:
cmd/compile: bug in cmd/compile/internal/types.(*Type).IsMemory

Issue created by stacks.
This stack ESvSrA was reported by telemetry:

compile/bug
cmd/compile/internal/base.FatalfAt:+3
cmd/compile/internal/base.Fatalf:=195
cmd/compile/internal/ssagen.(*ssafn).Fatalf:+3
cmd/compile/internal/ssa.(*Func).Fatalf:+10
cmd/compile/internal/ssa.Compile.func1:+9
runtime.gopanic:+50
runtime.panicmem:=262
runtime.sigpanic:+19
cmd/compile/internal/types.(*Type).IsMemory:=1575
cmd/compile/internal/ssa.(*Value).removeable:=562
cmd/compile/internal/ssa.applyRewrite:+47
cmd/compile/internal/ssa.decomposeBuiltIn:+14
cmd/compile/internal/ssa.postExpandCallsDecompose:+2
cmd/compile/internal/ssa.Compile:+67
cmd/compile/internal/ssagen.buildssa:+297
cmd/compile/internal/ssagen.Compile:+1

cmd/compile@go1.23.2 go1.23.2 linux/amd64  (1)

Related Issues

cmd/compile: bug in cmd/compile/internal/ssa.copyelimValue #70999
cmd/compile: bug in cmd/compile/internal/types.(*Type).Pos #71005
cmd/compile: bug in cmd/compile/internal/importer.(*pkgReader).objIdx.func1 #70996
cmd/compile: bug in cmd/compile/internal/inline/interleaved.fixpoint.func2 #71002
cmd/compile: bug in cmd/compile/internal/bitvec.NewBulk #71003
cmd/compile: bug in cmd/compile/internal/importer.(*reader).pkg #71000
cmd/compile: bug in cmd/compile/internal/types.(*Type).Elem #71008
cmd/compile: bug in cmd/compile/internal/noder.readPackage #71004
cmd/compile: bug in cmd/compile/internal/types.NewNamed #71001
cmd/compile: bug in cmd/compile/internal/staticdata.WriteEmbed #70995 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

authors: gabyhelp prattmic


text:
Permission denied on "/dev/gpiomem"

This is a new error I am just starting to get:
thread 'tokio-runtime-worker' panicked at src/hardware_subscription.rs:150:22:
called `Result::unwrap()` on an `Err` value: Permission denied: /dev/gpiomem

The only thing I can think of that has changed is that I updated a lot of packages on Pi OS recently.
uname -a
Linux rpi400 6.6.58-v8+ #1809 SMP PREEMPT Wed Oct 23 11:53:53 BST 2024 aarch64 GNU/Linux

I'll try and track down the exact call and add it here.

Confirmed that running as root avoids the problem.

Make sure /dev/gpiomem has rw permissions set for the gpio group, and the user you're logged in with is part of the gpio group. It looks like you may be running a different distro, which can cause issues. I suggest installing a fresh image of the latest stable Raspberry Pi OS release.

I'll check those things and get back to you.
It worked fine before on this machine without changing any permissions..., with same distro/install.
All I did is update all packages....maybe that changed something...

@andrewdavidmackenzie were you able to resolve this issue?

No, I assume it is a distro issue...and in my case an update changed the permissions...

Out of curiosity, what distro are you running? Would be good to know in case this pops up again.

Pi OS
uname -a
Linux rpi400 6.6.58-v8+ #1809 SMP PREEMPT Wed Oct 23 11:53:53 BST 2024 aarch64 GNU/Linux

authors: andrewdavidmackenzie golemparts

repo: golemparts/rppal

license: mit

license_source: bigquery


text:
pandoc-citeproc no longer supported

Earlier this year, I introduced pandoc-citeproc into this repo at https://github.com/gollum/gollum-lib/blob/master/lib/gollum-lib/markups.rb#L61. However, pandoc-citeproc is now deprecated, so I'm getting the following error when I try to use my gollum wiki:
Failed to render page: [WARNING] Deprecated: pandoc-citeproc filter. Use --citeproc instead. Error running filter pandoc-citeproc: Could not find executable pandoc-citeproc

I'm not very familiar with ruby, so I've been having trouble getting the switch to --citeproc to work.

Looks like changing that line to
PandocRuby.convert(content, '--citeproc', :from => 'markdown-tex_math_dollars-raw_tex', :to => :html)

does the trick (at least with my setup)! I'm not sure how we would ensure older versions work as well, though...

Looks like changing that line to
PandocRuby.convert(content, '--citeproc', :from => 'markdown-tex_math_dollars-raw_tex', :to => :html)

does the trick (at least with my setup)! I'm not sure how we would ensure older versions work as well, though...

repo: gollum/gollum-lib

license: MIT


text:
graph/path: fix negative cycle handling by AllShortest and FloydWarshall

Over the past ... time ... I've been having doubts about my claim for the approach obtaining a complete set of negative cycles in a graph using iterated Bellman-Ford probing. Today I checked it and my concerns were well founded, so I have removed that.
Wanting to have some way of doing this, I added an example using Floyd-Warshall and found that with negative cycles, AllShortest will never complete when a negative cycle exists. So I have fixed that by just not providing a mechanism to obtain the path. This is a bit of a dodge, but we can add it later if we want. The additional cost for the FloydWashall is an approximate doubling of time when a negative cycle exists. I think this is OK, but could be convinced otherwise (maybe add an option to retain the data for the call, or add a method to AllShortest to sanitise the distance matrix if needed — I think there is an option to do this lazily as well during the weight/paths calls: for each query, check do the work in the k loop in FloydWarshall for u and v only, storing the NaN if it's found and returning early if u->v is already NaN).
The use of NaN for undefined path weights reflects the behaviour that already existed in BellmanFord/Shortest. Other people use -Inf for this. I'm open to changing this as well.
Please take a look.

Do you have any views on NaN v. -Inf for weights of lowest weight negative cycles? I can see merits in both directions.

What merits do you see for each? In the end it doesn't matter too much? We just need some special value to mark the edges. Since we are marking edges on negative cycles, -Inf would seem to me like a more natural choice, but I think your insight is deeper.

I don't know exactly why I picked NaN originally; maybe because the shortest path is undefined. However, the weight of a path with a negative cycle with a simple path weight in the cycle of -1 has a limit of -Inf for as n approaches inifinity, so perhaps we can say the path is undefined but the weight is -Inf.
As far as the code goes, it gets rid of the IsNaN condition check since -Inf is negative.

I have changed the weight of negative cycles to -Inf.
PTAL

The thing that we lose when we use -Inf as I have here is the capacity to distinguish simple paths that have -Inf weight and negative cycles. I can imagine that -Inf edge weights are sometimes useful to ensure path choice. I can get around that by using NaN internally and translating that to -Inf in calls to the API; NaN weight edges are far less likely to be useful.
I'll think some more, but feel free to chime in.

source: gharchive/pull-request

authors: kortschak vladimir-ch

repo: gonum/gonum


text:
added footer

hey !
I had added the footer below their is pic attached for your convince

please check it out and merge it...

resolve the conflict and please star the repo

Hi!
the conflict has been resolved kindly check it and merge it
sorry for the inconvince..

Check again.

hello @goodchai0 !
I had resolve the conflict kindly merge it


text:
Add attack animation

Give more life to characters

The priority on this depends on the whole artistic direction

repo: goodfoodtruck/mana


text:
'com/goodow/realtime/json/JsonObject.h' file not found

I included the whole GDJson lib in my Xcode project without cocoapods, because pod does not work well with Swift.
I get the following errors:
/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/common/NSMutableDictionary+GDJsonObject.m:23:9: 'com/goodow/realtime/json/JsonObject.h' file not found

/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/generated/com/goodow/realtime/json/JsonType.m:8:10: 'com/goodow/realtime/json/JsonType.h' file not found

/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/common/NSMutableArray+GDJsonArray.m:23:9: 'com/goodow/realtime/json/JsonArray.h' file not found

/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/common/NSDictionary+GDJsonObject.m:22:9: 'com/goodow/realtime/json/JsonObject.h' file not found

/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/generated/com/goodow/realtime/json/JsonFactory.m:7:10: 'com/goodow/realtime/json/JsonArray.h' file not found

/Users/mg/Documents/Grails/GGTS3.6.2/Test111/GDJson/generated/com/goodow/realtime/json/JsonElement.m:7:10: 'com/goodow/realtime/json/JsonElement.h' file not found

You can find these heads at https://github.com/goodow/GDJson/tree/master/Classes/generated/com/goodow/realtime/json

Which version of CocoaPods you use? According to this blog, 0.36 supports Swift.

authors: confile larrytin

repo: goodow/GDJson


text:
LLM Models other than Gemma , falcon, phi, stablelm

Can we use other llm other than Gemma, falcon, phi, stablelm cause when i add other model in llm_conversion notebook its showing error to choosw only 4 of them what ro do can anyone explain ??

The four are set up for that conversion script, but if you want to do anything else/custom, then you'll need to use the AI Edge Torch Generative API

repo: google-ai-edge/mediapipe-samples


text:
The video stream stops running if the page is not in focus.

I use bodyPix. drawBokehEffect(canvas, video,...), then I transfer the media stream via WebRTC. If the browser page is not in focus, the video freezes.

@ErmineApps Can you share the steps to reproduce this issue ?

repo: google-coral/project-bodypix


text:
getNextScrambledWord function in GameFragment.kt in starter branch isn't used

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-viewmodel?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-3%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-viewmodel#1
In which task and step of the codelab can this issue be found?
Step 2, where the user is invited to download the starter code.
Describe the problem
In task 7, "Populate ViewModel", the user is askled to implement the shuffling of the new word in the function "getNextWord()". The method getNextScrambledWord, that can be found in the start code in gameFragment (we can only find in the starter branch and not the main one), is never talked about and never used. It seems it can simply be removed.
Steps to reproduce?

Go to... https://github.com/google-developer-training/android-basics-kotlin-unscramble-app/blob/starter/app/src/main/java/com/example/android/unscramble/ui/game/GameFragment.kt
Click on... line 92
See error... until line 99

Versions
Android Studio version:
API version of the emulator:
Additional information
Include screenshots if they would be useful in clarifying the problem.

Didn't see it was used to effectively scramble the word in the starter app. even if quickly replaced


text:
Android Basics: Fragments Navigation component

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-fragments-navigation-component#7
In which task and step of the codelab can this issue be found?
Set Up the Navigation Graph
Describe the problem
Typo in this paragraph:

Upon creating the XML file, you're presented with a new visual editor. Because you've already referenced nav_graph in the FragmentContainerView's navGraph property, To add a new destination, click the new button in the top left of the screen and create a destination for each fragment (one for fragment_letter_list and one for fragment_word_list).

The specific portion is the second sentence:

Because you've already referenced nav_graph in the FragmentContainerView's navGraph property, To add a new destination

@bernardsmith0892
Thank you for reaching out to us.
Could you please me be more specific describing the issue? Content in both the paragraphs seems to be same.

@jtavva
Thanks for the reply. It looks like the second sentence is missing a second clause. It ends with a comma and immediately goes into a new sentence.


text:
Gemini API: Prompting with Video - genai.upload_file [Errno 60] Operation timed out

How should I handle it so that I can execute the function to upload files locally? Additionally, what does this function correspond to 【POST https://generativelanguage.googleapis.com/upload/v1beta/files】？

Hi, are you running this in an available region by the way?  Seems like this might be related to the other issue: https://github.com/google-gemini/cookbook/issues/72

Hi, are you running this in an available region by the way? Seems like this might be related to the other issue: #72
Yes, I am using a US node

the same proble,genai.upload_file time out.

I find the solution.
Make sure Audio.ipynb works fine. That means the server end is OK.
https://colab.research.google.com/github/google-gemini/cookbook/blob/main/quickstarts/Audio.ipynb
The error happens in the network connection even you change the VPN node. You can set python code as below:
os.environ['http_proxy']='http://127.0.0.1:7890'
os.environ['https_proxy']='http://127.0.0.1:7890'
os.environ['all_proxy']='sock5://127.0.0.1:7890'
genai.configure(api_key=GOOGLE_API_KEY,transport='rest')
It works fine for me. Good luck~

I find the solution.
Make sure Audio.ipynb works fine. That means the server end is OK. https://colab.research.google.com/github/google-gemini/cookbook/blob/main/quickstarts/Audio.ipynb
The error happens in the network connection even you change the VPN node. You can set python code as below: os.environ['http_proxy']='http://127.0.0.1:7890' os.environ['https_proxy']='http://127.0.0.1:7890' os.environ['all_proxy']='sock5://127.0.0.1:7890' genai.configure(api_key=GOOGLE_API_KEY,transport='rest')
It works fine for me. Good luck~

Thank you very much. This configuration is indeed feasible

I find the solution.
Make sure Audio.ipynb works fine. That means the server end is OK. https://colab.research.google.com/github/google-gemini/cookbook/blob/main/quickstarts/Audio.ipynb
The error happens in the network connection even you change the VPN node. You can set python code as below: os.environ['http_proxy']='http://127.0.0.1:7890' os.environ['https_proxy']='http://127.0.0.1:7890' os.environ['all_proxy']='socks5://127.0.0.1:7890' genai.configure(api_key=GOOGLE_API_KEY,transport='rest')
It works fine for me. Good luck~

Works for me. thx a lot 😀 By the way, genai is not supported in HongKong, that's sad😅

authors: TYMichaelChen garmanwu maxuechaogao wangy325

repo: google-gemini/cookbook


text:
[felix] Can we get tensorflow1.x code?

the requirement of felix code confuse me and is not compatible with my environment.
Can we get origin tensorflow1.x code? Thanks a lot.

Hi, we don't plan to release the TF one version, as it tied to internal Google infrastructure. Could you maybe try using the most recent TF2 nightly rather than the one specified in the requirments.txt

authors: Jmallins zhyunlong

repo: google-research/google-research


text:
Provide an interactive class for mixing training and inference.

There's a lot of instructions here about how I could train/fine-tune t5 itself directly on natural language tasks and datasets, but I'm interested in training another model which would take t5 embeds of language as an input.
In order to do this, I would need to interleave t5 inference with my training script, which means I need a way to run t5 on a single batch not just on an entire dataset. How should I go about this?

@kkenealy is working on an InteractiveModel class that will make this easier to do along with a Colab demo.
In the meantime, you should take a look at the Model class interface, which provides a predict_batch method for inference and the Trainer class, which provides a train method that supports single-batch training.

Given an instance of the Model class, you can load a checkpoint using a CheckpointConfig; see these lines for an example: https://github.com/google-research/t5x/blob/999fccbfda10c107de7e4c071c976999621d8a79/t5x/train.py#L268

Hello, should this be closed? Seems that UL2 can now be loaded as InteractiveModel: https://github.com/google-research/t5x/issues/1226

authors: GallagherCommaJack adarob jon-chuang kkenealy


text:
add devtools section to storage doc

@marcacohen I added a DevTools section to your web storage doc. LGTY?

LGTM. I left one comment that is not blocking.

Thanks for this Kayce. Just left you one minor, non-blocking comment.
Otherwise LGTM!
On 19 October 2016 at 10:58, Paul Kinlan notifications@github.com wrote:

LGTM. I left one comment that is not blocking.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/google/WebFundamentals/pull/3701#issuecomment-254768251,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoLl0uqHI2rxZql7YQXKf2GNz_xWnJUks5q1em8gaJpZM4KZIvj
.

--
Marc Cohen
marcacohen@gmail.com
http://about.me/marc1

authors: PaulKinlan kaycebasques marcacohen

repo: google/WebFundamentals


text:
[devtools] update "optimize js execution"

Updates the section that explains how to use DevTools to analyze JS execution by fixing the screenshots and descriptions.

Done... I wonder if I could write a pre-submit hook that checks / fixes that


text:
update tools and dataset recommendations

What's changed, or what was fixed?

update tools and dataset recommendations

Target Live Date: 2019-09-2-

[x] This has been reviewed and approved by (addyosmani)
[x] I have run npm test locally and all tests pass.
[x] I have added the appropriate type-something label.
[x] I've staged the site and manually verified that my content displays correctly.

CC: @addyosmani @petele

Whoops!
There were 3 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2018/07/search-ads-speed.md#L143 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2018/07/search-ads-speed.md#L54 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/updates/2018/07/search-ads-speed.md#L5 - WF Tag 'wf_updated_on' must be within the last 7 days.

:tada: This has been pushed live to https://developers.google.com/web/

authors: WebFundBot igrigorik


text:
Mouse events triggered twice

When using the Access Bridge Explorer, and monitoring for mouse events, those are posted twice in the grid at the bottom of the page. Is there a way to capture mouse events only once? Please advice. Thanks.

Hi @ceconic ,
witch events a captured twice. There are four different mouseevents.

authors: MirkoFl ceconic

repo: google/access-bridge-explorer


text:
Timers and alarms don't work with GPIO/clap triggers

Hi, So now we have successfully managed to update our cardboard friend - thanks to the wonderful guidance yourselves provided - we have what seems to be another problem/issue.
In eduncan911's blog it was mentioned that the timer functionality was included in the new assistant SDK .
So we have found that
IF you setup your trigger to be ok-google - and ask the assistant to set a timer - the assistant will indeed set a timer and after the elapsed time it will tinkle away until you say ok-google stop.
HOWEVER
IF you leave that trigger at the default - which of course is our beloved pi GPIO - the timer functionality does not work - oh nooooooooooooooo
I have an awful feeling THAT (even if you have an PI 2/3 and hence you can use the new SDK) you are only using that new SDK (and its new functionality such as the timer) if you setup to use the hotword trigger.
I have an even worse feeling that whilst the new SDK knows about hotword triggering - it is clueless about GPIO.
Some people are going to want to be able to trigger via GPIO and be able to set a timer and whatever else the google-assistant is able to do down the road. Given the new SDK is only available for the PI it seems inconceivable it isn't usable with GPIO which is fundamental to the PI's being.
I've made some assumptions and may be barking up the wrong tree again. Look forward to hearing from you

Thanks for the feedback, @sheridat!
This is intentional - we were trying to keep things a bit simpler for the user by hiding the differences between the Google Assistant API (used for clap/GPIO trigger) and the Google Assistant Library (used for OK Google). However, it sounds like the missing functionality with the Assistant API means this isn't actually any simpler.
We're working on a new design at the moment that will be easier for people to build into their own applications, so this is great feedback to have.
Anyone reading this who wants to use timers etc with GPIO triggering - please +1 @sheridat's post so we know you're interested.

Thank You for the reply - this is my +1. People have come up with a few ways to trigger the assistant such as dash buttons and scripts. I trigger it by script (that sets the gpio) and in my instance I run that script using an IR remote (using LIRC/irexec)
We really want any new functionality - plus flexible triggering

+1 (even though I'm still on a Zero so cannot use it as yet.)  I really do not understand the differences between the library and the API and what the separation is trying to achieve.

+1 sheridat. I second that...there should be the same functionality regardless of how you trigger. Otherwise it gets very messy. Thanks

@sheridat I've also witnessed this.
It's almost like two different responses are active but the pi only plays one.

+1 for this feature. I'm currently using the customized trigger with snowboy, and the timers/alarms does not work.

Any update on this?

Has there been any fixes to this?

Nope, no update, I'm afraid. #112 contains an example of GPIO trigger with the assistant library, but you'd have to add your custom commands yourself, as the example doesn't use actions.py.

@JonesChi can you post a gist of that? I am trying to setup mine but i can't get it to work.

The assistant_library_with_button_demo.py will allow timers and alarms with a GPIO trigger.

Hi! It looks like the home assistant library is deprecated now. How do I now set a timer with python?

There should probably be a timer trait

authors: JonesChi Shulyaka arman-k aycgit borpin czarnikjak drigz janpIFMS nskrotzki sheridat

repo: google/aiyprojects-raspbian


text:
Add Preview Callback

allows setting a callback that gets invoked on each preview frame.
The callback receives an android.media.Image object, consistent with the Camera 2 API.

I have the same needs

check this https://github.com/google/cameraview/pull/218

authors: doug-precocity sibelius vondear

repo: google/cameraview


text:
Segmentation fault

Clspv fails to compile the following:
typedef unsigned u32;

kernel void foo(global u32 *out, global float *ptr, u32 f) {
    out[0] = atomic_max(reinterpret_cast<u32 *>(ptr), f);
}

godbolt link

Compiling with clspv in DEBUG and -cl-std=CLC++ outputs the following message:
# .---command stderr------------
# | Instruction not handled:   %1 = atomicrmw umax ptr addrspace(4) %0, i32 %f seq_cst, align 4
# | Missing support for instruction
# | UNREACHABLE executed at <clspv>/lib/LowerAddrSpaceCastPass.cpp:345!

authors: bmanga rjodinchr

repo: google/clspv


text:
fix Rewrite Packed Structs pass for opaque pointers

For opaque pointers, do not look for packed structure in kernel arguments.
Instead look for gep on packed structure or on structure with an implicit cast.
Lowering structure (even unpacked) in implicit cast gep is needed to avoid complicated issue (that I don't have a answer for) in replacepointerbitcastpass.
Lower all those GEPs using 2 new functions to rework GEP indices from a source type to a target type.
Also use those functions in Simplifypointerbitcastpass
SimplifyPointerBitcastPass needs to be updated with a new Map containing ImplicitCasts (between 2 GEPs) that can be lower in this pass. This is needed to avoid regression in the CTS.
Other minor fixes:

ReplacePointerBitcastPass::ComputeLoad: CreateGEP might not create a GEP, use getIndexedType to get the Load Type.
BitcastUtils::getEleTypesBitWidths: fix typo in struct size supported.

Fixes #1005
Fixes #1050
No regression on full cts with Swiftshader and Nvidia

RewritePackedStruct pass would be more StructLoweringPass with this PR.
I could rename everything, but I am not sure about it.


text:
Use Ctrl-Up and Ctrl-Down to change the font size in the editor panel.

This solves the problem with projectors and smart boards, as described in Issue 414

Thanks!

This is now live.

authors: alphalambda cdsmith

repo: google/codeworld


text:
Add ir_data_utils.copy and update

This adds ir_data_utils helpers to handle copying and updating ir_data instances. Some instances of CopyFrom that aren't associated with a builder are updated to use copy or update.
Part of #118.

FYI @robrussell

Not sure if you saw the question about header_generator_test.py - it has the only remaining direct calls to CopyFrom, did you intend to update those too?

It's used in a few files, the changes I made here were instances that aren't already using a builder. The ones in header_generator_test are all essentially builder(...).CopyFrom.

repo: google/emboss


text:
Setting DepthOfFieldOptions on Android causes performance drop even when disabled

I pulled in the latest changes since the beginning of the year and noticed as significant performance drop. I traced it to the setting the DepthOfFieldOptions property on my View object to a new object instance. Even though the enabled flag is set to false there is a significant reduction in performance unless I also set the filter to be NONE.
I couldn't see anything obvious in Renderer.cpp, which appears to be checking the enabled flag before registering dof for post-processing.

That seems quite strange since all we do is check the enabled flag. The presence of a new instance shouldn't matter (esp. at the native level since it's just a struct).

I forgot to mention that this was on Android. I will try and reproduce it with one of the sample projects, but it wants me to change to Java 11 and I don't want to mess with my build setup at the moment.

What do you mean by "unless I also set the filter to be NONE."?

What do you mean by "unless I also set the filter to be NONE."?

The filter property:
val dof = View.DepthOfFieldOptions()
dof.filter = View.DepthOfFieldOptions.Filter.NONE
dof.enabled = false
view.depthOfFieldOptions = dof

Okay, that is super strange. I will have a look. Thanks for the report.

I can't reproduce this problem at all -- I tried in Android.
A better repro case would be useful here.

I'm struggling to even get DoF to do anything in the Android samples. I've added the following to setupView in sample-texture-object:
val dof = View.DepthOfFieldOptions()
dof.enabled = true
dof.cocScale = 40f
view.depthOfFieldOptions = dof
camera.focusDistance = 0.1f

My expectation is that this should make everything very blurry. Have I missed a step?

Try to change your camera aperture to ƒ/2.8 for instance.

Try to change your camera aperture to ƒ/2.8 for instance.

I tried camera.setExposure(2.8f, 1.0f / 125.0f, 100.0f) and a few other combinations, but all it did was make it brighter.

I still can't make it blur more than a pixel with any combination of settings or positioning of the model and camera. Previously I could blur out the whole screen easily. I'm not actually using this feature anymore so feel free to close the issue if it's too obscure.

The best way to play with this stuff is to use our remote ui for gltf-viewer, have you tried that?
I will double check that something didn't break on mobile, this has happened before.

I've just discovered that and you are right - it's working on the remote viewer. I'll chalk it up to "one of those things" and close the issue for now.

authors: pixelflinger rawnsley romainguy

repo: google/filament


text:
Module.tabulate doesn't show activation layers.

Provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible also provide a summary of what steps or workarounds you have already tried.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Red Hat 8.2

Flax, jax, jaxlib versions (obtain with pip show flax jax jaxlib:

Name: flax
Version: 0.6.4
Summary: Flax: A neural network library for JAX designed for flexibility
Home-page: https://github.com/google/flax
Author: Flax team
Author-email: flax-dev@google.com
License:
Location: /home/ace14560le/venv/jax/lib/python3.10/site-packages
Requires: jax, matplotlib, msgpack, numpy, optax, orbax, PyYAML, rich, tensorstore, typing-extensions
Required-by: clu, orbax
Name: jax
Version: 0.4.2
Summary: Differentiate, compile, and transform Numpy code.
Home-page: https://github.com/google/jax
Author: JAX team
Author-email: jax-dev@google.com
License: Apache-2.0
Location: /home/ace14560le/venv/jax/lib/python3.10/site-packages
Requires: numpy, opt_einsum, scipy
Required-by: chex, clu, flax, optax, orbax
Name: jaxlib
Version: 0.4.2+cuda11.cudnn86
Summary: XLA library for JAX
Home-page: https://github.com/google/jax
Author: JAX team
Author-email: jax-dev@google.com
License: Apache-2.0
Location: /home/ace14560le/venv/jax/lib/python3.10/site-packages
Requires: numpy, scipy
Required-by: chex, clu, optax, orbax

Python version: 3.10.4
GPU/TPU model and memory: A100
CUDA version (if applicable): 11.8

Problem you have encountered:
Module.tabulate method doesn't show the activation layers.
What you expected to happen:
Module.tabulate shows the activation layers like pytorch model.
import torchvision.models.resnet as resnet

model = resnet.resnet18()
print(model)

ResNet(
  (conv1): Conv2d(3, 64, kernel_size=(7, 7), stride=(2, 2), padding=(3, 3), bias=False)
  (bn1): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
  **(relu): ReLU(inplace=True)**
  (maxpool): MaxPool2d(kernel_size=3, stride=2, padding=1, dilation=1, ceil_mode=False)
  (layer1): Sequential(
    (0): BasicBlock(
      (conv1): Conv2d(64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1), bias=False)
      (bn1): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
      **(relu): ReLU(inplace=True)**
      (conv2): Conv2d(64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1), bias=False)
      (bn2): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
    )
    (1): BasicBlock(
      (conv1): Conv2d(64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1), bias=False)
      (bn1): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
      **(relu): ReLU(inplace=True)**
      (conv2): Conv2d(64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1), bias=False)
      (bn2): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
    )
  )
  (layer2): Sequential(
    (0): BasicBlock(
      (conv1): Conv2d(64, 128, kernel_size=(3, 3), stride=(2, 2), padding=(1, 1), bias=False)
      (bn1): BatchNorm2d(128, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
      **(relu): ReLU(inplace=True)**

Logs, error messages, etc:
Steps to reproduce:
Whenever possible, please provide a minimal example. Please consider submitting it as a Colab link.
When use relu as the activation layer
class ExplicitMLP(nn.Module):
  features: Sequence[int]

  def setup(self):
    # we automatically know what to do with lists, dicts of submodules
    self.layers = [nn.Dense(feat) for feat in self.features]
    # for single submodules, we would just write:
    # self.layer1 = nn.Dense(feat1)

  def __call__(self, inputs):
    x = inputs
    for i, lyr in enumerate(self.layers):
      x = lyr(x)
      if i != len(self.layers) - 1:
        x = nn.relu(x)
    return x

key1, key2 = random.split(random.PRNGKey(0), 2)
x = random.uniform(key1, (4,4))

model = ExplicitMLP(features=[3,4,5])
print(model.tabulate(key2, x))

Output:

When use tanh as the activation layer:
  features: Sequence[int]

  def setup(self):
    # we automatically know what to do with lists, dicts of submodules
    self.layers = [nn.Dense(feat) for feat in self.features]
    # for single submodules, we would just write:
    # self.layer1 = nn.Dense(feat1)

  def __call__(self, inputs):
    x = inputs
    for i, lyr in enumerate(self.layers):
      x = lyr(x)
      if i != len(self.layers) - 1:
        x = nn.tanh(x)
    return x

key1, key2 = random.split(random.PRNGKey(0), 2)
x = random.uniform(key1, (4,4))

model = ExplicitMLP(features=[3,4,5])
print(model.tabulate(key2, x))

Output:

The outputs of the two model are the same. To make the differences in the models clear, a line describing the activation layer should be inserted between the layers_0 and layers_1.

Hey @zguo235, currently activation function such as nn.relu or nn.tanh are not Flax Modules but just regular JAX functions which is why they don't appear in the tabulate summary. If want them to appear consider creating wrapper Modules like this e.g:
class Relu(nn.Module):
  def __call__(self, x):
    return nn.relu(x)

@cgarciae Thank you for the reply! I will close this issue as your answer solved my problem perfectly. However, I think the activation function should be Flax Module instead of just JAX functions. I know the flax.linen is stable and it may be difficult to change the type of activation functions, but as activation functions are also layers of neural network, the default method in nn.Module should be available in activation layers.

repo: google/flax