profile
viewpoint

randall77/hprof 71

Heap profile reader for Go

randall77/heapdump14 24

Heap dump reader & visualizer for Go 1.4

randall77/corelib 12

A tool for reading Go core files

randall77/factorlib 5

A library for factoring big integers in Go

randall77/compilercover 4

Tool to generate coverage reports on the Go compiler

randall77/memmove 3

Test for memmove speed

randall77/rulecover 3

Tool for producing a cover profile of SSA .rules files

randall77/prominence 2

A program to compute the prominence of mountains

randall77/2016-talks 1

Slides and Links to slides for 2016 talks

randall77/errors 1

Simple error handling primitives

issue closedgolang/go

return an error instead of panic in case of panic: runtime error

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

$ go version compile environment:

go version go1.14.2 darwin/amd64

running environment:

CentOS Linux release 7.3.1611 (Core)/3.10.0/x64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="off" GOARCH="amd64" GOBIN="" GOCACHE="/Users/abc/Library/Caches/go-build" GOENV="/Users/abc/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOOS="darwin" GOPATH="/Users/abc/go" GOPROXY="https://goproxy.cn,direct" GOROOT="/usr/local/go" GOSUMDB="off" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gq/jd9v5dd95p570hkztblb8ht40000gn/T/go-build162051472=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

We have a redis proxy services, deployed in two servers. They receive responses from clients and redirect other redis services.

What did you expect to see?

The two run well.

What did you see instead?

The two services are crash at 18:17 and the stack is :

panic: runtime error: slice bounds out of range [:81] with capacity 72

goroutine 2382138 [running]:
internal/poll.(*FD).Write(0xc025650e80, 0xc0f7054230, 0x51, 0x48, 0x0, 0x0, 0x0)
        /usr/local/go/src/internal/poll/fd_unix.go:268 +0x405
net.(*netFD).Write(0xc025650e80, 0xc0f7054230, 0x51, 0x48, 0x3c, 0x0, 0x0)
        /usr/local/go/src/net/fd_unix.go:220 +0x4f
net.(*conn).Write(0xc07798ea28, 0xc0f7054230, 0x51, 0x48, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:196 +0x8e
git.abc.com/redisproxy/proxy/doublewriter.(*Worker).start(0xc0006accc0)
        /Users/abc/go/src/git.abc.com/redisproxy/proxy/doublewriter/writer.go:169 +0x156
created by git.abc.com/redisproxy/proxy/doublewriter.(*Writer).AddWorker
        /Users/abc/go/src/git.abc.com/redisproxy/proxy/doublewriter/writer.go:80 +0x29f

Problem

I searched issues and found some similar isssues: #22522 #22102 . According to descriptions of those issues, it looks it is OS issue/driver issue. When go call the write syscall.Write, the syscall returns bigger number than input, which caused the panic.

So is it a better solution to check the slice range at https://github.com/golang/go/blob/master/src/internal/poll/fd_unix.go#L267 and returns an error if overflow?

closed time in 9 hours

smallnest

issue commentgolang/go

return an error instead of panic in case of panic: runtime error

The slices passed to these functions look bad. Their length is 0x51 but their capacity is only 0x48. You might want to check where git.abc.com/redisproxy/proxy/doublewriter.(*Worker).start gets its slice from. Particularly, check any uses of unsafe or cgo - you should not be able to construct such a slice with pure Go. Also run with the race detector, as a data race could cause this as well.

Closing, as this does not appear to be a bug in Go (yet). Please reopen if you find more evidence pointing to Go itself.

I don't think this issue is related to #22522 or #22102 at all. They have input slices with valid len/cap.

smallnest

comment created time in 9 hours

issue commentgolang/go

Compilation error with ARM processor (reoccurance)

Those line numbers look like they don't correspond to tip. Could you retry with the latest x/sys?

Martin555

comment created time in 14 hours

issue commentgolang/go

x/tools/go/analysis/passes/asmdecl: false error report for 16 byte move

Related CL (support for complex128): https://go-review.googlesource.com/c/tools/+/204537

mmcloughlin

comment created time in 17 hours

issue closedgolang/go

The method set of S shouldn't include promoted methods with receiver *T when S contains an embedded field T

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

go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?

YES

What operating system and processor architecture are you using (go env)?

bogon:~ benjamin$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
......

What did you do?

I wrote a simple golang program as follow,

package main

import (
	"fmt"
)

type people struct {
	age  int
	name string
}

func (p *people) Speak() {
	fmt.Println("I am people.")
}

func (p people) Eat() {
	fmt.Println("People like cake.")
}

type student struct {
	people
	score int
}

func main() {
	p := people{30, "ben"}
	s := student{p, 80}
	s.Speak()
	s.Eat()

	fmt.Println(s)
}

What did you expect to see?

I expected to see a compiling error or a runtime panic. Based on the golang spec as below, The method set of S shouldn't include promoted methods with receiver *T. In my example, the student shouldn't include prometed method Speak() with receiver *people.

If S contains an embedded field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T.

What did you see instead?

I did not see any error, and the output of my example program was as below,

I am people.
People like cake.
{{30 ben} 80}

closed time in 20 hours

ahrtr

issue commentgolang/go

The method set of S shouldn't include promoted methods with receiver *T when S contains an embedded field T

From the spec:

If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m():

So your call s.Eat() is actually (&s).Eat() and then that falls in the second sentence of the part of the spec you quoted.

So this is working as intended. Closing.

ahrtr

comment created time in 20 hours

issue commentgolang/go

runtime/race: inconsistent snapshot of vector clocks during finalizer sync leads to false positive

*p = foo
*y = bar

Ah, now I see what the issue is. The last pointer to the object being finalized is overwritten, not just dropped. It might not live in a live map (i.e. be on the stack) anywhere where we can extend its lifetime.

So we execute *y = bar, making our object unreachable, then we get interrupted and GC is run. GC decides to schedule the finalizer and it runs before the goroutine that is about to execute *p = foo ever gets scheduled.

This would be hard to do in the current garbage collector - you have to time it just right or the write barrier will prevent collection of the overwritten pointer. But not impossible, I guess.

The preemptive scheduler makes this worse by making everywhere a safe point. Before that, only call sites are safe points so we need only prevent reordering writes across calls.

So yes, it looks like this would prevent reordering writes where at least one of them is a pointer write? Or we have to mark such reorderings as unsafe points, perhaps?

nvanbenschoten

comment created time in a day

issue commentgolang/go

runtime/race: inconsistent snapshot of vector clocks during finalizer sync leads to false positive

Yes, you need the value of f live somewhere where I noted. Not the variable f. The variable could have been overwritten, sure. So when reordering stores, the lifetime of the values of the pointers being stored to cannot shrink. The value of each pointer must live on somewhere (not necessarily in f, just somewhere marked live) until at least its original source location.

nvanbenschoten

comment created time in a day

issue commentgolang/go

runtime/race: inconsistent snapshot of vector clocks during finalizer sync leads to false positive

f := new(...)
runtime.SetFinalizer(f, ...)
p := new(...)
p.x = 7
f.p = p

Yes, if the compiler reorders the last two writes, and it does not extend the lifetime of f until after the now-last p.x = 7 statement, then we have a problem. So store-reordering optimizations are certainly possible, they just need to keep some sense of the pre-reordered liveness map around.

f := new(...)
runtime.SetFinalizer(f, ...)
p := new(...)
f.p = p
// f can't die here, even though it looks like it does
p.x = 7
// f has to die (at least) here

Is that saying the same thing that Ian said? I think so. I hope so.

As Ian mentioned, reordering by the hardware shouldn't matter - the stop-the-world at the start of the GC (and allocating black during GC?) should save us.

nvanbenschoten

comment created time in a day

issue commentgolang/go

runtime/race: inconsistent snapshot of vector clocks during finalizer sync leads to false positive

Just so I understand, you're worried about:

  f := new(...)
  runtime.SetFinalizer(f, ...)
  p := new(...)
  f.p = p
  p.x = 7
  runtime.KeepAlive(f) // last use of f

You're worried that the finalizer might not see f.p.x == 7?

I don't think that's a problem in the current compiler, as runtime.KeepAlive is modeled as a write operation, and will not be reordered with other writes. (GC does not reorder writes at all.)

Without the runtime.KeepAlive, this code might not see f.p.x == 7, and we should report a race, because the finalizer could happen before the p.x = 7 statement.

nvanbenschoten

comment created time in 2 days

issue commentgolang/go

runtime/race: inconsistent snapshot of vector clocks during finalizer sync leads to false positive

I don't see how this could be a problem. How could there be a point in the program where we still have a pending write to an object, but we no longer have a pointer to it? I could see the hardware doing that, but the compiler can't.

nvanbenschoten

comment created time in 2 days

issue commentgolang/go

go.dev: proposal for search filters: language features and possible compatibility issues

If the intend is to avoid bugs a better rating would be amount of warning from static-check since I suspect most bugs don't come from unsafe usage.

Sure, that would be a good signal also. Probably a better signal. But we don't have to choose just one.

Unsafe is almost always used when it brings a significant performance improvement, if it isn't necessary nobody would use it. But sometimes it is necessary and we shouldn't judge a package by its unsafe unsafe. (unless it is significantly slower than a "safe" alternative, then judge away)

If I'm looking for a package which is performance-critical, I would absolutely consider unsafe packages, especially if their performance was better than alternatives. On the other hand, if I'm looking for something which isn't performance-critical, I would avoid unsafe packages unless there was no alternative (or the alternatives were bad for other reasons).

fgergo

comment created time in 5 days

issue commentgolang/go

go.dev: proposal for search filters: language features and possible compatibility issues

I think we do want to discourage use of unsafe, at least to a degree. Avoiding unsafe eliminates a wide variety of possible bugs. Of course, bugs can be avoided other ways (more tests, fuzzing, etc.) so as with any signal, it should probably not stand alone.

If there are two packages that do the same thing, everything else being equal I would choose the one that didn't use unsafe.

fgergo

comment created time in 5 days

issue commentgolang/go

proposal: spec: decide ambiguity in comparing array/structs with interface fields/elements

That sounds ok to me.

I'm not sure we actually need to add it to the spec, though. It's really an esoteric corner case. Is there any place we record decisions about making consistent implementations, that isn't in the spec? Things like

  • complex NaN / Inf behavior
  • defer of a nil function
  • defer of recover
mdempsky

comment created time in 7 days

issue commentgolang/go

cmd/link: binary on darwin takes up more space on disk

Note that copying the result to a new file fixes the problem.

kokes

comment created time in 9 days

issue commentgolang/go

runtime: Darwin slow when using signals + int->float instructions

The link works fine for me. It is behind a login, though. Not sure if that would give you a 404 or not.

randall77

comment created time in 9 days

issue closedgolang/go

cmd/compile: Program should arguably panic, but doesn't

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

<pre> $ go version go version go1.14.3 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/home/mero/.cache/go-build" GOENV="/home/mero/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/mero" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/mero/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/mero/go/pkg/tool/linux_amd64" GCCGO="/usr/bin/gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build637886539=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

I used unsafe to create a []int with len/cap 1 and data pointing at 0:

Program 1

func main() {
	x := *(*[]int)(unsafe.Pointer(&reflect.SliceHeader{Len: 1, Cap: 1}))
	p := &x[0]
	fmt.Println(p, p == nil, interface{}(p) == (*int)(nil))
}

Program 2

func main() {
	x := *(*[]int)(unsafe.Pointer(&reflect.SliceHeader{Len: 1, Cap: 1}))
	p := x[0]
	fmt.Println(p)
}

What did you expect to see?

According to the spec, both programs should panic:

If the evaluation of x would cause a run-time panic, then the evaluation of &x does too.

What did you see instead?

Only Program 2 panics. Also, even though p is nil in Program 1, comparing it to nil evaluates to false. I assume this is due to the compiler seeing how p is initialized and optimizing the comparison out - if you pass it through interface{}, the comparison ends up returning true (presumably fooling this optimization).

Now, arguably it is fine to violate the spec in this case, as we're using unsafe to trick the compiler. I haven't tested if something similar happens if we'd, say, create a PROT_NONE mapping and do the same addressing (I assume it does, though). I just wanted to tell you about it after I found it.

closed time in 10 days

Merovius

issue commentgolang/go

cmd/compile: Program should arguably panic, but doesn't

I used unsafe to create a []int with len/cap 1 and data pointing at 0:

That's not a legal slice. The compiler/runtime assume that a slice with a nonzero length has a non-nil data pointer.

Using unsafe you can always put the system into a weird state it wasn't prepared for. For example, a string with a negative length. Users of unsafe need to be prepared for all kinds of restrictions (that aren't specified anywhere).

I'm going to close this issue. I don't see anything actionable here. Unless you are proposing we remove optimizations to handle weird unsafe cases like this?

I haven't tested if something similar happens if we'd, say, create a PROT_NONE mapping and do the same addressing (I assume it does, though).

The spec makes no promises about non-zero faulting pointers. We currently crash (not panic) if we dereference one.

Merovius

comment created time in 10 days

issue commentgolang/go

cmd/compile: builds not reproducible on single-cpu vs multiple-cpu machines

I'm not sure what that code has to do with my suggestion. I'm not suggesting that that code be moved.

I'm not suggesting we compile the wrappers early, just generate them. I guess that would require removing the funccompile call at the end of genwrapper, and replacing that with adding the function to the xtop list instead?

mjl-

comment created time in 12 days

issue commentgolang/go

cmd/compile: builds not reproducible on single-cpu vs multiple-cpu machines

I think we just try to keep as many complicated bits out of the parallel phase as possible. We've historically had trouble with symbols, errors, etc. showing up in the parallel phase and having to jump through hoops to serialize them deterministically. The less we do in the parallel phase, the better, at least from a code maintenance perspective (i.e. as long as it is a tiny fraction of compile time).

mjl-

comment created time in 12 days

issue commentgolang/go

cmd/compile: builds not reproducible on single-cpu vs multiple-cpu machines

I'd like to propose a 5th option. Not sure if this would actually fix the issue, but...

Before compilation, can we iterate through xtop, find all the wrappers that need to be generated, and generate them? Including making any inline decisions for them. Then we're not generating new functions to compile while compiling, which has always been a thorny source of nondeterminism.

mjl-

comment created time in 12 days

issue commentgolang/go

cmd/compile: several arm64 code-gen issues

... and will probably need backporting as well, depending on what the fix looks like.

shawn-xdji

comment created time in 13 days

issue commentgolang/go

cmd/compile: several arm64 code-gen issues

This issue is causing incorrect code generation on (at least) arm64 and arm. It's a pretty esoteric case (comparisons after integer overflow), so I don't think it should block beta1, but should be fixed before release.

shawn-xdji

comment created time in 13 days

issue commentgolang/go

proposal: Add functions to convert between uints and byte arrays

If encoding/binary is too expensive, we should optimize it, not jump immediately to adding new API. That starts with a benchmark demonstrating the problem.

This code:

func f(x [8]byte) uint64 {
     return binary.LittleEndian.Uint64(x[:])
}

already compiles to just 2 instructions (2 MOVQ, from the input stack slot to a register, and from the register to the output stack slot).

geraldss

comment created time in 13 days

issue commentgolang/go

proposal: Add functions to convert between uints and byte arrays

We already have functions very much like this in encoding/binary.

geraldss

comment created time in 13 days

issue commentgolang/go

runtime/race: potential false positive from race detector

the len(cCh) statement is 100% not a data race, just looking at the language specifications:

You're right, this is not a race. Why then did it report the line number of the len call? Your repro reports the close call on the next line.

I agree with Ian. The compiler converts:

select {
case ...:
case s.C() <- v:
}

To

tmp := s.C()
select {
case ...:
case tmp <- v:
}

In between the assignment and the select statement, the wait group can be decremented to 0 (inside the 3rd C call), allowing the main routine to run to the close statement and cause a race with the select case.

EVODelavega

comment created time in 13 days

issue commentgolang/go

A strange question for bool

Might be #35881

laomz

comment created time in 14 days

issue commentgolang/go

runtime/race: potential false positive from race detector

The len(cCh) is the access that caused the race in the report you showed us. At least, assuming broker_test.go you gave us and stuff_test.go you ran with are identical. If there is still a race without that line, show us that updated race report. (It will probably be on the close(cCh) because that also races with the channel send.)

EVODelavega

comment created time in 14 days

issue commentgolang/go

runtime/race: potential false positive from race detector

That looks like a race between reading the length of the channel and writing to the channel. That looks like a correct report to me.

EVODelavega

comment created time in 14 days

issue commentgolang/go

runtime: missing deferreturn on linux/ppc64le

@danscales

4a6f656c

comment created time in 14 days

issue commentgolang/go

runtime: rare TestSpuriousWakeupsNeverHangSemasleep failures

@odeke-em

Those other two errors you found grepping the logs look different. They are not timeouts.

I think we might need to just increase the timeout. If there is too much work going on on the machine, timers, or responses to them, might be delayed.

FiloSottile

comment created time in 16 days

issue commentgolang/go

map: a key-value pair may be GC

I don't see a bug in maps here, although it is hard to tell. I suspect a bug in your map, not the builtin map. With this patch:

diff --git a/cykv_test.go b/cykv_test.go
index c45c202..855499f 100644
--- a/cykv_test.go
+++ b/cykv_test.go
@@ -66,8 +66,10 @@ func TestMapCorrect(t *testing.T) {
 
        startTime := time.Now()
        maxCount := int64(0)
+       var strs []string
        for i := 0; i < int(60e6); i++ {
                str := genRandomStr(TestStrLen)
+               strs = append(strs, str)
                realValue, exist := checker[str]
                checker[str]++
                debugLog.Printf("Start: key=%+v, bytes=%+v", str, []byte(str))
@@ -78,8 +80,14 @@ func TestMapCorrect(t *testing.T) {
 
                if value != checker[str] {
                        debugBuf.Flush()
-                       t.Logf("wrong map, the value before incresing: %+v, exist=%+v", realValue, exist)
-                       t.Fatalf("value: %+v, real: %+v", value, checker[str])
+                       n := 0
+                       for _, s := range strs {
+                           if s == str {
+                              n++
+                           }
+                       }
+                       t.Logf("wrong map, the value before incresing: %+v, exist=%+v, slice=%d", realValue, exist, n)
+                       t.Fatalf("value: %+v, real: %+v slice=%d", value, checker[str], n)
                }
 
                passCount++

I get an error like:

    cykv_test.go:90: value: 2, real: 1 slice=1

Which means the builtin map is correct, and the map you get with NewMap is wrong.

yah01

comment created time in 18 days

issue closedgolang/go

Race detector should not require cgo

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

<pre> $ go version go version go1.13.10 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/tmp/.gocache" GOENV="/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="0" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build323659760=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

CGO_ENABLED=0 go install -race <cmd>

What did you expect to see?

I expected it to create an executable without cgo that has race detection instrumentation.

We want to be able to run the resulting executable inside a FROM scratch docker container, so any dynamic linking against C libraries is not acceptable.

What did you see instead?

go install: -race requires cgo; enable cgo by setting CGO_ENABLED=1

If I turn on cgo, I can see there are some dynamically linked libraries, so the executable is not usable.

linux-vdso.so.1 (0x00007ffd8db6e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcf44b3e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf4474d000) /lib64/ld-linux-x86-64.so.2 (0x00007fcf44d5d000)

closed time in 19 days

rittneje

issue commentgolang/go

Race detector should not require cgo

Dup of #9918 and #6508 .

rittneje

comment created time in 19 days

issue commentgolang/go

proposal: spec: decide ambiguity in comparing array/structs with interface fields/elements

Maps, of course, use equality under the hood:

The comparison operators == and != must be fully defined for operands of the key type; thus the key type must not be a function, map, or slice. If the key type is an interface type, these comparison operators must be defined for the dynamic key values; failure will cause a run-time panic.

This statement is very vague about when it will cause a runtime panic. Currently, we will panic on the first hash of such a key. Currently also, that will be on the first insert, lookup, or delete of that key. But I could imagine other implementations that do other things (e.g. going from 0 to 1 element, we really don't need to hash).

Fortunately, we always panic on the hash of a key that would panic on a comparison. So everything that makes it into the map is good, so any subsequent == calls will never panic.

mdempsky

comment created time in 21 days

issue commentgolang/go

Illegal Instruction on POWER8 with go 1.13

@laboger If you try it with tip, it should print the bytes for the instruction that caused the SIGILL. That might help.

trdyer

comment created time in 21 days

issue commentgolang/go

SIGILL: illegal instruction on any go tool under macOS

@pm-harshad-mane That looks like a different issue. Can you open a new one?

carlca

comment created time in 22 days

issue commentgolang/go

cmd/compile: arm64 ssa check compilation failure

I can't reproduce now. (CL 216418 is in, so just trying at tip.) Was this fixed? By accident, or on purpose?

josharian

comment created time in 23 days

issue commentgolang/go

Incorrect handling of literal -0.0

There's a tradeoff. For instance, in Go you can write (1<<64)/10 and get a reasonable answer. In C you cannot. I agree that generating a floating-point -0 is more challenging in Go. That seems like a reasonable tradeoff to me. How many people need a -0?

You may want to read through https://blog.golang.org/constants

kstenerud

comment created time in 23 days

issue closedgolang/go

Incorrect handling of literal -0.0

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

Latest. See playground: https://play.golang.org/p/M0iIlaKMKfY

What did you do?

https://play.golang.org/p/M0iIlaKMKfY

package main

import (
	"fmt"
	"math"
)

func main() {
	v1 := math.Float64frombits(0x8000000000000000)
	v2 := -0.0
	v3 := -(0.0)
	v4 := 0.0
	v4 = -v4
	fmt.Printf("%v\n", v1)
	fmt.Printf("%v\n", v2)
	fmt.Printf("%v\n", v3)
	fmt.Printf("%v\n", v4)
}

What did you expect to see?

-0
-0
-0
-0

What did you see instead?

-0
0
0
-0

closed time in 23 days

kstenerud

issue commentgolang/go

Incorrect handling of literal -0.0

This is intentional, and how constant expressions work.

Constant expressions are always evaluated exactly; intermediate values and the constants themselves may require precision significantly larger than supported by any predeclared type in the language.

In particular, there is no constant -0. That's a float64-ism. Once you have a float64 variable, then you're in IEEE-754 land.

kstenerud

comment created time in 23 days

issue commentgolang/go

Off-by-one-error in runtime.wasmTruncS and runtime.wasmTruncU causes a crash

I'd say the constant in that code (runtime.wasmTrunc{S,U}) is really the problem. The constant is written as an integer, but is converted to a float by the assembler. It is rounded up when converted to a float.

So yes, changing to >= would work. But really we should write a constant that's exactly representable in floating point, and use >.

I believe that constant is 0x7ffffffffffffc00 for signed and 0xfffffffffffff800 for unsigned. Proof:

package main

import "fmt"

func main() {
	for i := int64(1<<63 - 1); i >= 0; i-- {
		f := float64(i)
		x := int64(f)
		if x != -1<<63 {
			fmt.Printf("%x %x\n", i, x)
			break
		}
	}
	for i := uint64(1<<64 - 1); i >= 0; i-- {
		f := float64(i)
		x := uint64(f)
		if x != 1<<63 {
			fmt.Printf("%x %x\n", i, x)
			break
		}
	}
}

We should double-check the less than condition in wasmTruncS also.

evanw

comment created time in 24 days

issue commentgolang/go

cmd/compile: binaries contain many ..type.eq funcs

I tried to noalg slice backing store arrays, but trybots didn't like me: https://go-review.googlesource.com/c/go/+/151497 Never got around to figuring out why.

bradfitz

comment created time in a month

issue commentgolang/go

cmd/compile: binaries contain many ..type.eq funcs

In https://go-review.googlesource.com/c/go/+/191198 I did a similar thing for hash functions. Only the ones we know are needed are generated. The rest are done reflect-like inside the runtime. The slowdown wasn't too bad (20%) and it saved a lot of binary size (1%). The nice thing about maps is we know most of the hash functions we need, as interface-keyed maps are the only exception and they are fairly rare (rarer still, non-pointer interface keys). It's less clear for == because those comparison functions are used in more places.

bradfitz

comment created time in a month

issue commentgolang/go

cmd/compile: unnecessary full complex multiplication for x*c where x is complex and c a real constant

I'm not sure if this is a correct optimization. I think it's the equivalent of the rule x * 0 == 0, which isn't actually true for float64.

(x+yi)*(c+0i) = (x*c-y*0) + (x*0+y*c) i

Say x == +inf, y == c == 1. Then the complex result is +inf + NaN i. Just multiplying both parts by 1 gives +inf + i.

Having said that, I think our story on inf/nan complex numbers is haphazard at best.

griesemer

comment created time in a month

issue closedgolang/go

Want to support some Go issue can i assign

Want to support some Go issue can i assign

closed time in a month

rajendraprasad9

issue commentgolang/go

Want to support some Go issue can i assign

You might look through https://golang.org/doc/contribute.html Also look for issues in this tracker with the "help wanted" label.

This is not an issue with something to be fixed, closing.

rajendraprasad9

comment created time in a month

issue commentgolang/go

cmd/compile: invalid pointer on stack calling syscall.LazyProc.Call (a go:uintptrescapes function)

This bug was reported against github.com/konsorten/go-windows-terminal-sequences as https://github.com/konsorten/go-windows-terminal-sequences/issues/4, which was fixed with this commit: https://github.com/konsorten/go-windows-terminal-sequences/commit/71a52a12b06309f8b640fb3169d40575b2085a98

Does that fix work for you?

wxj95

comment created time in a month

issue commentgolang/go

proposal: handle type conversion of interface-slices similar to interfaces

var rc io.ReadCloser var r io.Reader = rc rc is still io.ReadCloser, r refers to that rc but it is an io.Reader.

That works fine because the assignment at line 2 makes a copy. The value contained in rc is never modified.

The situation with slices is more like this:

var rc io.ReadCloser
rcp := &rc
rp := (*io.Reader)(rcp)
*rp = ... something that is a Reader, but not a Closer ...

Now what does rc contain?

To be problematic, you need to be able to write an io.Reader to a slot that originally contained an io.ReadCloser.

glooms

comment created time in a month

issue commentgolang/go

proposal: handle type conversion of interface-slices similar to interfaces

x[0] is still an io.ReadCloser

But it isn't, I just assigned something that doesn't have a Close method to x[0] (via y[0]).

Or are you suggesting that the cast make a copy of the slice's backing store?

glooms

comment created time in a month

issue commentgolang/go

proposal: handle type conversion of interface-slices similar to interfaces

var x []io.ReaderCloser = ...
y := ([]io.Reader)(x)
y[0] = ... something that is a Reader, but not a Closer ...

What is now in x[0]? Can it be closed?

glooms

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

Here's a simple reproducer.

foo.go:

package main

import "C"
import "os"

//export Foo
func Foo() {
     println(os.Stdout)
}
func main() {
}

main.go:

package main

/*
#include <dlfcn.h>
#cgo LDFLAGS: -ldl
void f() {
   void *x = dlopen("libfoo.so", RTLD_LAZY);
   void (*Foo)() = (void(*)())dlsym(x, "Foo");
   Foo();
}
*/
import "C"

func main() {
     C.f()
}
$ go build -o libfoo.so -buildmode=c-shared foo.go
$ go run main.go

This prints 0x0 on a mac. It prints something nonzero on linux.

Something is wrong with the Go->C->Go path. When we get back to Go, we have an uninitialized evironment.

khaitranvan96kt

comment created time in a month

issue commentgolang/go

cmd/compile: generates invalid instruction when using bit shifts on amd64

(BTR(L|Q)const [c] (BTR(L|Q)const [d] x)) -> (AND(L|Q)const [^(1<<uint32(c) | 1<<uint32(d))] x)

That rule is just wrong. We need c<32 and d<32 as preconditions. Just typing it won't help - it will still lose the upper bits of the mask (for the Q version, at least).

kynrai

comment created time in a month

issue closedgolang/go

math: MaxUint64 doesn't return correct result but an error?

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> $ go@1.12

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<pre> $ amd64

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> <pre> I just use the const in math packge: math.MaxUint64 </pre>

What did you expect to see?

<pre> 18446744073709551615 </pre>

What did you see instead?

<pre> ./main.go:169:29: constant 18446744073709551615 overflows uint </pre>

Notice that "1<<64" in "math.MaxUint64 = 1<<64 - 1" may cause overflow, perhas you can use "math.MaxUint64 = ^uint64(0)" instead.

closed time in a month

IIvyPy

issue commentgolang/go

math: MaxUint64 doesn't return correct result but an error?

Closing, this is working as intended. As @bmkessler says, explicitly type your variable instead of using :=.

IIvyPy

comment created time in a month

issue commentgolang/go

cmd/compile: internal compiler error: name too long

This might have been fixed with CL 214239. I believe that CL made it into 1.14. 1.14 fixes the OP's example for me.

elagergren-spideroak

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

Ok, I can reproduce the problem.

Not sure what is going on yet. One thing to try would be to move the python initialization code out of an init function and into main. That way, we make sure that all packages are initialized before calling into python and back to Go again.

khaitranvan96kt

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

I downloaded your code and tried to run it, but ran into problems. We need exact instructions on how to get to the error posted. Show us every command you issued.

$ go run main.go
# pkg-config --cflags  -- python-2.7
pkg-config: exec: "pkg-config": executable file not found in $PATH
khaitranvan96kt

comment created time in a month

issue commentgolang/go

math.MaxUint64 doesn't return correct result but an error?

Show us your code. This code works fine:

package main

import "math"

func main() {
	var x uint = math.MaxUint64
	_ = x
}

The definition of MaxUint64 as 1<<64-1 has no issues with overflow. It is a constant expression, which in Go is evaluated with arbitrary precision/range.

IIvyPy

comment created time in a month

issue commentgolang/go

cmd/compile: unexpected nil dereference on s390x [1.14 backport]

I believe only CL 228061 is required. Michael, please confirm.

Yes, we should backport. This is a rare issue but is serious. It can lead to arbitrary bad execution.

gopherbot

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

Well that looks like a completely different panic trace. Something is definitely clobbered here, it's crashing because log.std is nil, which can't happen (unless Python is calling back into Go before Go has been initialized)? Looks like memory corruption.

my code runs well in ubuntu but not in macos, what's the difference here?

I do not know. Without a way for us to reproduce it's going to be hard to find out.

khaitranvan96kt

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

how to use the race detector?

Use the -race flag on the go tool.

https://golang.org/doc/articles/race_detector.html

khaitranvan96kt

comment created time in a month

issue commentgolang/go

runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x405ae42

Can you share the program? Have you tried 1.14.2? Does it pass the race detector?

@mknyszek

khaitranvan96kt

comment created time in a month

issue commentgolang/go

spec: when do struct comparisons panic?

It would be unfortunate if, when comparing [100]interface{}, we had to compare all 100 entries even when the first entry reports !=. Not the end of the world, though.

bradfitz

comment created time in a month

issue closedgolang/go

Is assigning a pointer atomic in go

In my project,i encounter problems,this is my code: `var data map[string]string

func main() {

go func() {
	v := data["d"]
	fmt.Println(v)

}()
go func() {

	temp := make(map[string]string)
	temp["a"] = "a"
	data = temp
}()

} one coroutine read the map or list, but one coroutine modify the map or list,is the step:data = temp` atomic ,and is there any problem or bug,

closed time in a month

SmallSmartMouse

issue commentgolang/go

Is assigning a pointer atomic in go

This is a race condition, and is invalid code. Run with the -race flag and you will see an error.

More generally, pointer assignment is atomic, but you need more than that to make an example like yours work.

The Go project does not use the issue tracker for questions. Please use a forum for this discussion. See https://golang.org/wiki/Questions. Thanks.

SmallSmartMouse

comment created time in a month

issue commentgolang/go

Memory freed by GC doesn't seem to claim properly when same slice variable is initialised in a loop

This is all behaving as expected. What about this do you think is wrong?

The garbage collector works in batches. It does not collect unreferenced items immediately.

naveenkak

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

It is cleaned up. Change your print line to

	fmt.Printf(" memory allocated %d %d\n",  m.Alloc, m.NumGC)

And then run again you'll get something like:

test slice length 100000 memory allocated 225856 0
test slice length 100000 memory allocated 332368 0
test slice length 100000 memory allocated 438880 0
test slice length 100000 memory allocated 545392 0
test slice length 100000 memory allocated 651904 0
test slice length 100000 memory allocated 758416 0
test slice length 100000 memory allocated 864928 0
test slice length 100000 memory allocated 971440 0
test slice length 100000 memory allocated 1077952 0
test slice length 100000 memory allocated 1184464 0
test slice length 100000 memory allocated 1290976 0
test slice length 100000 memory allocated 1397488 0
test slice length 100000 memory allocated 1504000 0
test slice length 100000 memory allocated 1610512 0
test slice length 100000 memory allocated 1717024 0
test slice length 100000 memory allocated 1823536 0
test slice length 100000 memory allocated 1930048 0
test slice length 100000 memory allocated 2036560 0
test slice length 100000 memory allocated 2143072 0
test slice length 100000 memory allocated 2249584 0
test slice length 100000 memory allocated 2356096 0
test slice length 100000 memory allocated 2462608 0
test slice length 100000 memory allocated 2569120 0
test slice length 100000 memory allocated 2675632 0
test slice length 100000 memory allocated 2782144 0
test slice length 100000 memory allocated 2888656 0
test slice length 100000 memory allocated 2995168 0
test slice length 100000 memory allocated 3101680 0
test slice length 100000 memory allocated 3208192 0
test slice length 100000 memory allocated 3314704 0
test slice length 100000 memory allocated 3421216 0
test slice length 100000 memory allocated 3527728 0
test slice length 100000 memory allocated 3634240 0
test slice length 100000 memory allocated 3740752 0
test slice length 100000 memory allocated 3847264 0
test slice length 100000 memory allocated 3953776 0
test slice length 100000 memory allocated 4060288 0
test slice length 100000 memory allocated 4166800 0
test slice length 100000 memory allocated 326080 1
test slice length 100000 memory allocated 432608 1
test slice length 100000 memory allocated 539136 1
test slice length 100000 memory allocated 645664 1
test slice length 100000 memory allocated 752192 1
test slice length 100000 memory allocated 858720 1
test slice length 100000 memory allocated 965248 1
test slice length 100000 memory allocated 1071776 1
test slice length 100000 memory allocated 1178304 1
test slice length 100000 memory allocated 1284832 1
test slice length 100000 memory allocated 1391360 1
test slice length 100000 memory allocated 1497888 1
test slice length 100000 memory allocated 1604416 1
test slice length 100000 memory allocated 1710944 1
test slice length 100000 memory allocated 1817472 1
test slice length 100000 memory allocated 1924000 1
test slice length 100000 memory allocated 2030528 1
test slice length 100000 memory allocated 2137056 1
test slice length 100000 memory allocated 2243584 1
test slice length 100000 memory allocated 2350112 1
test slice length 100000 memory allocated 2456640 1
test slice length 100000 memory allocated 2563168 1
test slice length 100000 memory allocated 2669696 1
test slice length 100000 memory allocated 2776224 1
test slice length 100000 memory allocated 2882752 1
test slice length 100000 memory allocated 2989280 1
test slice length 100000 memory allocated 3095808 1
test slice length 100000 memory allocated 3202336 1
test slice length 100000 memory allocated 3308864 1
test slice length 100000 memory allocated 3415392 1
test slice length 100000 memory allocated 3521920 1
test slice length 100000 memory allocated 3628448 1
test slice length 100000 memory allocated 3734976 1
test slice length 100000 memory allocated 3841504 1
test slice length 100000 memory allocated 3948032 1
test slice length 100000 memory allocated 4054560 1
test slice length 100000 memory allocated 4161088 1
test slice length 100000 memory allocated 4266432 2
test slice length 100000 memory allocated 432856 2
test slice length 100000 memory allocated 539384 2
test slice length 100000 memory allocated 645912 2
test slice length 100000 memory allocated 752440 2
test slice length 100000 memory allocated 858968 2
test slice length 100000 memory allocated 965496 2
test slice length 100000 memory allocated 1072024 2
test slice length 100000 memory allocated 1178552 2
test slice length 100000 memory allocated 1285080 2
test slice length 100000 memory allocated 1391608 2
test slice length 100000 memory allocated 1498136 2
test slice length 100000 memory allocated 1604664 2
test slice length 100000 memory allocated 1711192 2
test slice length 100000 memory allocated 1817720 2
test slice length 100000 memory allocated 1924248 2
test slice length 100000 memory allocated 2030776 2
test slice length 100000 memory allocated 2137304 2
test slice length 100000 memory allocated 2243832 2
test slice length 100000 memory allocated 2350360 2
test slice length 100000 memory allocated 2456888 2
test slice length 100000 memory allocated 2563416 2
test slice length 100000 memory allocated 2669944 2
test slice length 100000 memory allocated 2776472 2
test slice length 100000 memory allocated 2883000 2

The memory gets cleaned up, but only when the garbage collector runs (and even then, only around when NumGC goes up, because the garbage collector is asynchronous).

genez

comment created time in a month

issue commentgolang/go

cmd/compile: bugs in mips rules

To be clear, I don't think there is an actual code generation bug.

The docs for SRAconst, for example, just say "arg0 >> auxInt, signed". But I don't think that's what it actually does, at least if you interpret >> as a Go shift. I think they do arg0 >> (auxint%32). In which case, it should say that. But better would be to say that the constant shifts must have an arg 0-31. That would ensure a canonical representation for constant shifts, which might help a bit during CSE, and more generally just be clearer to understand.

That's what we do on other archs, e.g. for amd64/SHLQconst: arg0 << auxint, shift amount 0-63

randall77

comment created time in a month

issue openedgolang/go

cmd/compile: bugs in mips rules

I came across some bugs in the mips rules while reviewing the typed aux conversion for those rules.

Constant shifts require 0-31 as the shift amount. Rules like this:

(SLL x (MOVWconst [c])) => (SLLconst x [c])

Might violate that invariant. Might just need &31 in a few places.

We should check all the other uses of constant shifts to make sure they obey the invariant listed in the opcode definition. Maybe even define a new aux type range0to31 or something to help with enforcement (which the check pass can check).

@ALTree

created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

space for the keys and values themselves won't be reclaimed, as that space is part of the buckets. Only the things referenced by the keys and values will be collected.

Maps are reference types (they are implemented as pointers). For a map of type map[int]map[int]int, deleting an entry from the top-level map should make the entire inner map collectable. Only the pointer slot in the top-level map will be uncollectable.

genez

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

calling runtime.GC() after every delete, will that force memory to be freed.

runtime.GC won't collect anything that isn't collectable with the automatic GC. So it's a no-op with regards to this issue. (It's a hint to collect things more promptly, but does not affect the set of collectable things.)

I was under the impression that once i delete the entry from the top level map, I don,t need to bother about the inner map at all.

Your impression is correct. Maps are implemented as pointers, so once you delete an entry from the top map, the inner map will be unreachable and be eligible for garbage collection.

The major underlying issue seems to be, that there is no way in Go to express "I am done adding/deleting, please finalise the map" which doesn't involve using more memory.

The major underlying issue is that someone has to implement shrink on delete. There's no reason the runtime can't do this (within a constant factor of) optimally, without hints.

genez

comment created time in a month

issue commentgolang/go

runtime: SIGSEGV during runtime init, in gcenable

@mknyszek

wadey

comment created time in a month

issue commentgolang/go

runtime: binary hangs on Catalina

I'm not sure there's anything we can do here, without understanding what syspolicyd is doing, and particularly, what policy it is trying to enforce. Is it something about the Go binary? Are we violating a policy? If so, what policy? Or are we doing something that makes syspolicyd do a lot of work to verify that we're in fact ok policy-wise? Or is it just general slowness with syspolicyd working hard, that tends to affect Go binaries more than others? Or is it just syspolicyd causing general slowness, and Go is just being dinged due to an observer effect?

https://www.reddit.com/r/MacOS/comments/dm4dhd/syspolicyd_high_cpu_usage_on_macos_catalina/

gadelkareem

comment created time in a month

issue commentgolang/go

playground: Map based program timesout

Maybe a dup of #38546 ? Adding another string to one of the printfs fixes it.

ardan-bkennedy

comment created time in a month

issue commentgolang/go

cmd/compile: support named values on RHS of rewrite rules

That syntax seems fine to me. We already do it on the LHS.

josharian

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

Ah, looks like you're hitting our large key optimization - if a key or value is over 128 bytes, we allocate it on the heap and store a pointer to it in the map bucket. Those allocations will get collected when the key is deleted (because we zero the pointer in the map bucket when deleting).

genez

comment created time in a month

issue commentgolang/go

proposal: Go 2: deferred code blocks

With the different return semantics, this is no longer just a cosmetic proposal.

damien-lloyd

comment created time in a month

issue closedgolang/go

cmd/compile: huge waste stack when make function calls

when make function calls, SP decrease at least 0x60 bytes even there is no use of stack at all. The stack waste forces newstack being called more frequently

closed time in a month

zylthinking

issue commentgolang/go

cmd/compile: huge waste stack when make function calls

I see SUBQ $0x58, SP, for a total frame size of 96 bytes.

All that space makes sense to me.

  • 64 bytes for the outargs section of the frame, to call fmt.Fprintln (fmt.Println is inlined).
    • 16 for the io.Writer
    • 24 for the slice
    • 8 for the n return value
    • 16 for the error
  • 16 bytes for the backing store for the slice (a [1]interface{})
  • 8 bytes for the return address
  • 8 bytes for the frame pointer

We can't really make it smaller without going to a register-based calling convention (issue #18597). I'm going to close this as not actionable / working as intended.

zylthinking

comment created time in a month

issue commentgolang/go

proposal: Go 2: deferred code blocks

What happens if a return is in the code block?

func f() int {
    defer {
        return 7
    }
    return 5
}

That's not semantically equivalent to

func f() int {
    defer func() {
        return 7
    }()
    return 5
}

The latter is obviously wrong. Is the former wrong? Or does that return cause 7 to override 5?

Not sure if this is a ding for or against this proposal. It's definitely a weird semantic corner. But maybe, just maybe, if we allow it we can get rid of the must-name-return-values-to-update-them-with-defer problem.

A similar situation applies to goto. What if there is a goto to outside the defer block? Is that allowed? In this case, though, I think it is clearer that this is just an error.

damien-lloyd

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

@ronanwatkins What OSX version did you test on?

The CL above would not fix my test programs. It just fixes the file passing from the go tool to the compiler.

daojianmahun

comment created time in a month

issue commentgolang/go

cmd/compile huge waste stack when make function calls

Please fill out the issue template. Tell us what you did, and how you came to your conclusions. Among the things we need to take any action on this report - Go version, OS, processor architecture, and an example program.

zylthinking

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

I see the same bug(?) on OSX 10.12.6. That makes me thing this doesn't warrant a backport - it has been broken forever, both old Go versions and old OSX versions. Please let me know if you see anything different. The two test programs above should help verify.

daojianmahun

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

Looks like the compiler already has support for a file of input file names. https://go-review.googlesource.com/c/go/+/110395 I think we just need to teach go build to use that.

daojianmahun

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

I don't see anything wrong with Go per se. Here are 2 programs, one Go and one C.

package main

import "syscall"

const N = 18722

func main() {
	var args []string
	args = append(args, "/bin/echo")
	for i := 0; i < N; i++ {
		args = append(args, "hello")
	}
	_, _, err := syscall.StartProcess("/bin/echo", args, &syscall.ProcAttr{})
	if err != nil {
		panic(err)
	}
}
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

#define N 18722

int main(int argcX, char *argvX[]) {
  char *argv[N+2];
  argv[0] = "/bin/echo";
  for(int i = 0; i < N; i++) {
    argv[i+1] = "hello";
  }
  argv[N+1] = NULL;
  char *envp[1] = {NULL};
  int err = execve("/bin/echo", argv, envp);
  printf("%d %s\n", errno, strerror(errno));
}

Both run fine. But increase N by one, and both fail.

It is string length dependent. Replacing "hello" with "hellohello" and the magic number is now 13795. Note that's not anywhere near half of 18722.

All of these limits are lower than a 256K command line limit would indicate. Is there some per-argument overhead, maybe?

daojianmahun

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

So that compiler command line is only 62529 bytes. That's ~4x smaller than the published OSX command line limit. I'm not sure what limit it is bumping up against, then. Maybe the go tool needs to set some shell parameter (ulimit? not sure)?

When I paste that command line into my shell, I get:

compile: -importcfg: open /b001/importcfg: no such file or directory

Which means at least the compiler is starting up fine with that long a command line.

daojianmahun

comment created time in a month

issue commentgolang/go

cmd/go: pass files to compile to compiler in a file instead of on the command line

Could you list more of your compile command line? What, exactly, is underneath that ***1919 go file names from the directory "./platformclientv2"***? Show me the whole command line, excluding a chunk in the middle that's repetitive. Include the first several and last several file names. (Or post the whole thing somewhere and share a link.)

I ask because I'm wondering whether file names are relative or absolute, how long they are, etc. If I'm correct that the command line limit is 256K, then you have file names >100 chars long on average. I want to see why those names need to be so long. Or see that they are shorter, and maybe that 256K limit is wrong.

daojianmahun

comment created time in a month

issue commentgolang/go

binary size explodes for huge return value

""..stmp_0 SRODATA size=536870912
""..stmp_2 SRODATA size=536870912

There are some really big static temps used to initialize instances of type foo. One at the return site of foo (which goes away because foo is inlined?) and one in main to initialize the heap-allocated foo (the compiler heap allocates x because it is too large).

We shouldn't be copying from zeroed data to initialize anything - we should just zero it directly.

An easier fix would be to allocated all-zero static temps in BSS, so at least they don't bloat the binary.

typeless

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

Also your comment for if they contain pointers caught my eye. Is it because of this fix - https://go-review.googlesource.com/c/go/+/3288?

No, I just mean the space for the keys and values themselves won't be reclaimed, as that space is part of the buckets. Only the things referenced by the keys and values will be collected. CL 3288 is only about optimizing GC work - it does not affect what is collected.

Does that means if we are going to keep a big map in the app(with many deletes) as live, we have to choose between memory leaks(non pointer kv) or long GC pauses (pointers)?

Not really. The only situation I see where that choice is relevant is if you're deciding between using string or [100]byte as the key. The former has a pointer in it, so the text of your strings will be collected, but then the GC has to scan the map. With the latter the GC doesn't have to scan the map, but then the space for your keys will not be collected because it is part of the buckets themselves.

Or we keep tracks of number of deletes and copy to a new map after O(n) deletes

That would work fine.

genez

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

This issue is about map buckets, both the standard ones and the overflow buckets. We do not shrink the main buckets array or deallocate the overflow buckets when elements are deleted from the map.

We do zero the slots in the buckets when elements are deleted, so the individual keys and values (if they contain pointers) will be collected by GC correctly.

genez

comment created time in a month

issue commentgolang/go

go refuses to compile hex floats on +build go1.13 file

I think this should work. Having a go1.11 mark in the mod file means we shouldn't define a go1.13 build tag. The bad code never makes it to the compiler. Something earlier in the toolchain is barfing on the input.

@bcmills

kstenerud

comment created time in a month

issue closedgolang/go

Ambiguous defer's behavior

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

<pre> $ go version go1.13.10 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="/go/bin" GOCACHE="/.cache/go-build" GOENV="/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/snap/go/5646" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/snap/go/5646/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build798787028=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

Run simple code: (https://play.golang.org/p/z2YsplDZOfp) <pre> package main

import ( "fmt" )

func a() error { err := fmt.Errorf("Errorrrrrrooo")

defer func() { err = nil }()

return err }

func b() (err error) { err = fmt.Errorf("Errorrrrrrooo")

defer func() { err = nil }()

return err }

func main() { fmt.Println(a()) fmt.Println(b()) } </pre>

What did you expect to see?

<pre> Errorrrrrrooo Errorrrrrrooo </pre>

or

<pre> nil nil </pre>

What did you see instead?

<pre> Errorrrrrrooo nil </pre>

closed time in a month

actopolus

issue commentgolang/go

Ambiguous defer's behavior

This is expected behavior.

In a:

  1. Assign non-nil error to a local variable
  2. Evaluate that local variable (to a non-nil error), set return value to it
  3. Run defer, set local variable to nil

That returns the non-nil error.

In b:

  1. Assign non-nil error to return variable
  2. Evaluate return variable (to a non-nil error), set return value to it
  3. Run defer, set return variable to nil (overwriting what was written in step 2)

That returns a nil error.

We generally discourage return x when there are named return variables. Set them using = and use a bare return.

actopolus

comment created time in a month

issue closedgolang/go

cmd/compile: stringtoslicebytetmp optimization on unescaped slice

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> $ go version go version go1.14 linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details> <summary> <code>go env</code> Output </summary> <br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/tdakkota/.cache/go-build" GOENV="/home/tdakkota/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/tdakkota/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build263265353=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

https://play.golang.org/p/kSKRNgYnQCS

package main

import (
	"fmt"
)

func allocme(n int) string {
	arr := make([]byte, n) // first allocation
	for i := 0; i < n; i++ {
		arr[i] = byte(i + 97)
	}
	return string(arr) // second allocation + copy
}

func main() {
	fmt.Println(allocme(25))
}

Then run with gc's flag -S

$ go build -gcflags "-S" main.go

<details><summary> Output </summary><pre> "".allocme STEXT size=161 args=0x18 locals=0x38 0x0000 00000 (/home/tdakkota/workspace/expirm/main.go:7) TEXT "".allocme(SB), ABIInternal, $56-24 0x0000 00000 (/home/tdakkota/workspace/expirm/main.go:7) MOVQ (TLS), CX 0x0009 00009 (/home/tdakkota/workspace/expirm/main.go:7) CMPQ SP, 16(CX) 0x000d 00013 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $0, $-2 0x000d 00013 (/home/tdakkota/workspace/expirm/main.go:7) JLS 151 0x0013 00019 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $0, $-1 0x0013 00019 (/home/tdakkota/workspace/expirm/main.go:7) SUBQ $56, SP 0x0017 00023 (/home/tdakkota/workspace/expirm/main.go:7) MOVQ BP, 48(SP) 0x001c 00028 (/home/tdakkota/workspace/expirm/main.go:7) LEAQ 48(SP), BP 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $0, $-2 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $1, $-2 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:7) FUNCDATA $0, gclocals·568470801006e5c0dc3947ea998fe279(SB) 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:7) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:7) FUNCDATA $2, gclocals·1cf923758aae2e428391d1783fe59973(SB) 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:8) PCDATA $0, $1 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:8) PCDATA $1, $0 0x0021 00033 (/home/tdakkota/workspace/expirm/main.go:8) LEAQ type.uint8(SB), AX 0x0028 00040 (/home/tdakkota/workspace/expirm/main.go:8) PCDATA $0, $0 0x0028 00040 (/home/tdakkota/workspace/expirm/main.go:8) MOVQ AX, (SP) 0x002c 00044 (/home/tdakkota/workspace/expirm/main.go:8) MOVQ "".n+64(SP), AX 0x0031 00049 (/home/tdakkota/workspace/expirm/main.go:8) MOVQ AX, 8(SP) 0x0036 00054 (/home/tdakkota/workspace/expirm/main.go:8) MOVQ AX, 16(SP) 0x003b 00059 (/home/tdakkota/workspace/expirm/main.go:8) CALL runtime.makeslice(SB) 0x0040 00064 (/home/tdakkota/workspace/expirm/main.go:8) PCDATA $0, $1 0x0040 00064 (/home/tdakkota/workspace/expirm/main.go:8) MOVQ 24(SP), AX 0x0045 00069 (/home/tdakkota/workspace/expirm/main.go:10) MOVQ "".n+64(SP), CX 0x004a 00074 (/home/tdakkota/workspace/expirm/main.go:10) XORL DX, DX 0x004c 00076 (/home/tdakkota/workspace/expirm/main.go:10) JMP 88 0x004e 00078 (/home/tdakkota/workspace/expirm/main.go:11) LEAQ 97(DX), BX 0x0052 00082 (/home/tdakkota/workspace/expirm/main.go:11) MOVB BL, (AX)(DX*1) 0x0055 00085 (/home/tdakkota/workspace/expirm/main.go:10) INCQ DX 0x0058 00088 (/home/tdakkota/workspace/expirm/main.go:10) CMPQ DX, CX 0x005b 00091 (/home/tdakkota/workspace/expirm/main.go:10) JLT 78 0x005d 00093 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ $0, (SP) 0x0065 00101 (/home/tdakkota/workspace/expirm/main.go:14) PCDATA $0, $0 0x0065 00101 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ AX, 8(SP) 0x006a 00106 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ CX, 16(SP) 0x006f 00111 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ CX, 24(SP) 0x0074 00116 (/home/tdakkota/workspace/expirm/main.go:14) CALL runtime.slicebytetostring(SB) 0x0079 00121 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ 40(SP), AX 0x007e 00126 (/home/tdakkota/workspace/expirm/main.go:14) PCDATA $0, $2 0x007e 00126 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ 32(SP), CX 0x0083 00131 (/home/tdakkota/workspace/expirm/main.go:14) PCDATA $0, $0 0x0083 00131 (/home/tdakkota/workspace/expirm/main.go:14) PCDATA $1, $1 0x0083 00131 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ CX, "".~r1+72(SP) 0x0088 00136 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ AX, "".~r1+80(SP) 0x008d 00141 (/home/tdakkota/workspace/expirm/main.go:14) MOVQ 48(SP), BP 0x0092 00146 (/home/tdakkota/workspace/expirm/main.go:14) ADDQ $56, SP 0x0096 00150 (/home/tdakkota/workspace/expirm/main.go:14) RET 0x0097 00151 (/home/tdakkota/workspace/expirm/main.go:14) NOP 0x0097 00151 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $1, $-1 0x0097 00151 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $0, $-2 0x0097 00151 (/home/tdakkota/workspace/expirm/main.go:7) CALL runtime.morestack_noctxt(SB) 0x009c 00156 (/home/tdakkota/workspace/expirm/main.go:7) PCDATA $0, $-1 0x009c 00156 (/home/tdakkota/workspace/expirm/main.go:7) JMP 0 </pre></details>

What did you expect to see?

One allocation at all. arr does not escape, so we can use runtime.slicebytetostringtmp instead of runtime.slicebytetostring

What did you see instead?

Two allocation and copying,

closed time in a month

tdakkota

issue commentgolang/go

cmd/compile: stringtoslicebytetmp optimization on unescaped slice

Closing as dup of #6714.

tdakkota

comment created time in a month

issue commentgolang/go

runtime: maps do not shrink after elements removal (delete)

	for i := 0; i < 10000-1; i++ {
		a[i] = v
	}

	runtime.GC()
	printMemStats("After Map Add 9999 again")

The map will be garbage collected at this runtime.GC. The compiler knows that the map will not be used again. Your later a==nil does nothing - the compiler is way ahead of you.

Try adding fmt.printf("%d\n", len(m)) at various places above to introduce another use of m. If you put it after the runtime.GC, you will see the behavior you are expecting.

genez

comment created time in a month

IssuesEvent

issue commentgolang/go

runtime/race: running with -race misses races (mismatch with memory model)

Tsan changes are in, but the Go side isn't done yet.

dfava

comment created time in a month

more