Go 1.5.1 issues

Russ Cox

unread,

Aug 25, 2015, 2:26:36 PM8/25/15

to golang-dev

There are at least two issues (a compiler bug and a runtime bug) that will require issuing a Go 1.5.1.

Are there any other issues people would like to nominate, that are not already in the Go1.5.1 milestone on GitHub?

Thanks.

Russ

David Chase

unread,

Aug 26, 2015, 6:35:17 AM8/26/15

to Russ Cox, golang-dev

I'd like to nominate #12290, float64 RNG is not uniform. That won't go away, and the fix is short and clean.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rob Pike

unread,

Aug 26, 2015, 7:47:50 AM8/26/15

to David Chase, Russ Cox, golang-dev

That's not a critical fix and the issue has been around a long time. There are also issues about the need for a stable output between releases. I think it can wait for 1.6.

-rob

Vincent Vanackere

unread,

Aug 26, 2015, 9:45:13 AM8/26/15

to Russ Cox, golang-dev

Hi,

Although not critical, it would be nice to have issue 12232 fixed
for go 1.5.1:
- in our case it prevents vendoring of packages with import path checking
- the fix is trivial and only impacts GO15VENDOREXPERIMENT so there is
no risk of regression here

I can send a CL if necessary.

Regards,

Vincent

Russ Cox

unread,

Aug 26, 2015, 11:54:00 AM8/26/15

to Rob Pike, David Chase, golang-dev

On Wed, Aug 26, 2015 at 7:47 AM, Rob Pike <r...@golang.org> wrote:

That's not a critical fix and the issue has been around a long time. There are also issues about the need for a stable output between releases. I think it can wait for 1.6.

To expand on this, see https://github.com/golang/go/wiki/Go-Release-Cycle. Minor releases are for problems that are critical and for which there is no workaround. There is a trivial workaround if you don't like math/rand: use something else. Examples of things with no workaround are typically 'compiler miscompiles your code' or 'runtime crashes incorrectly in your program'. And even those we typically only fix if the problem is new in this release. If people have lived with a problem for the entire previous major release (and usually earlier ones as well), it's not critical enough to fix before the next major release.

Russ

Alexandre Cesaro

unread,

Aug 27, 2015, 6:36:02 AM8/27/15

to golang-dev, r...@golang.org, drc...@google.com

I just ran into a "fatal error: bad pointer in write barrier" in some legacy code. It looks like it is due to a data race.

This piece of code runs once a day and had never thrown an error on Go 1.4. It was recompiled with Go 1.5 a few days ago.

So I'm happy it allowed me to find that data race but I wonder whether this kind of error is an expected behavior when there are data races or if it is a bug.

Should I open an issue?

Ian Lance Taylor

unread,

Aug 27, 2015, 10:13:34 AM8/27/15

to Alexandre Cesaro, golang-dev, Rob Pike, David Chase

On Thu, Aug 27, 2015 at 3:36 AM, Alexandre Cesaro
<alexandr...@gmail.com> wrote:
>
> I just ran into a "fatal error: bad pointer in write barrier" in some legacy
> code. It looks like it is due to a data race.
> This piece of code runs once a day and had never thrown an error on Go 1.4.
> It was recompiled with Go 1.5 a few days ago.
>
> So I'm happy it allowed me to find that data race but I wonder whether this
> kind of error is an expected behavior when there are data races or if it is
> a bug.

In general almost anything can happen when there is a data race,
including this kind of error. The error means that a value that has a
pointer type holds a value that could not possibly be a pointer.

Ian

Dave Mazzoni

unread,

Aug 27, 2015, 1:07:15 PM8/27/15

to golang-dev

This seems to be a bug:

cd /usr/local/go/misc/swig/stdio

$ go-linux-arm build

# _/usr/local/go/misc/swig/stdio

gcc: error: unrecognized command line option '-marm'

While go build works perfectly.

minux

unread,

Aug 27, 2015, 1:12:13 PM8/27/15

to Dave Mazzoni, golang-dev

Are you using linux/arm cross C compiler when building for

linux/arm?

Dave Mazzoni

unread,

Aug 27, 2015, 1:22:09 PM8/27/15

to golang-dev, dav...@gmail.com

Does this help?

$ go-linux-arm build -x

WORK=/tmp/go-build975911020

mkdir -p $WORK/_/usr/local/go/misc/swig/stdio/_obj/

mkdir -p $WORK/_/usr/local/go/misc/swig/

swig -version

cd $WORK

/usr/local/go/pkg/tool/linux_amd64/compile -o ./_/usr/local/go/misc/swig/stdio/_obj/_go_.o -trimpath . -p main -complete -buildid c3a5e31344fc433bb86c9181542c384d49121c52 -D _$WORK ./swig_intsize.go

cd /usr/local/go/misc/swig/stdio

swig -go -cgo -intgosize 32 -module file -o $WORK/_/usr/local/go/misc/swig/stdio/_obj/file_wrap.c -outdir $WORK/_/usr/local/go/misc/swig/stdio/_obj/ file.swig

CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/usr/local/go/misc/swig/stdio/_obj/ -importpath _/usr/local/go/misc/swig/stdio -- -I $WORK/_/usr/local/go/misc/swig/stdio/_obj/ $WORK/_/usr/local/go/misc/swig/stdio/_obj/file.go

# _/usr/local/go/misc/swig/stdio

gcc: error: unrecognized command line option '-marm'

minux

unread,

Aug 27, 2015, 1:27:12 PM8/27/15

to Dave Mazzoni, golang-dev

On Thu, Aug 27, 2015 at 1:22 PM, Dave Mazzoni <dav...@gmail.com> wrote:

Does this help?
$ go-linux-arm build -x
WORK=/tmp/go-build975911020
mkdir -p $WORK/_/usr/local/go/misc/swig/stdio/_obj/
mkdir -p $WORK/_/usr/local/go/misc/swig/
swig -version
cd $WORK
/usr/local/go/pkg/tool/linux_amd64/compile -o ./_/usr/local/go/misc/swig/stdio/_obj/_go_.o -trimpath . -p main -complete -buildid c3a5e31344fc433bb86c9181542c384d49121c52 -D _$WORK ./swig_intsize.go
cd /usr/local/go/misc/swig/stdio
swig -go -cgo -intgosize 32 -module file -o $WORK/_/usr/local/go/misc/swig/stdio/_obj/file_wrap.c -outdir $WORK/_/usr/local/go/misc/swig/stdio/_obj/ file.swig
CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/usr/local/go/misc/swig/stdio/_obj/ -importpath _/usr/local/go/misc/swig/stdio -- -I $WORK/_/usr/local/go/misc/swig/stdio/_obj/ $WORK/_/usr/local/go/misc/swig/stdio/_obj/file.go
# _/usr/local/go/misc/swig/stdio
gcc: error: unrecognized command line option '-marm'

If you haven't installed gcc cross compiler for linux/arm and set $CC to it,

then it's probably the cause for the build failure.

Dave Mazzoni

unread,

Aug 27, 2015, 1:46:15 PM8/27/15

to golang-dev, dav...@gmail.com

Good point. Previously I was doing this:

$ CC=arm-xilinx-linux-gnueabi-gcc GOOS=linux GOARCH=arm CGO_ENABLED=1 go build

# _/usr/local/go/misc/swig/stdio

/tmp/go-build891892343/_/usr/local/go/misc/swig/stdio/_obj/_cgo_gotypes.go:9: can't find import: "runtime/cgo"

If I use build -x it's clearly calling the cross compiler. Am I missing something else?

Chris Broadfoot

unread,

Sep 2, 2015, 11:42:06 PM9/2/15

to Russ Cox, golang-dev

Previous e-mail had a link to open CLs. Here's one to all CLs on the 1.5.1 branch:

https://go-review.googlesource.com/#/q/project:go+branch:release-branch.go1.5

On Wed, Sep 2, 2015 at 8:39 PM, Chris Broadfoot <cb...@golang.org> wrote:

I've just sent out CLs for cherry-picks for all of the closed issues in the 1.5.1 milestone.
https://go-review.googlesource.com/#/q/status:open+project:go+branch:release-branch.go1.5

Are there any other changes that need to be cherry-picked for the 1.5.1 release?

There are still 12 open issues on GitHub:
https://github.com/golang/go/issues?q=is%3Aissue+milestone%3AGo1.5.1+is%3Aopen

--cbro

Chris Broadfoot

unread,

Sep 2, 2015, 11:42:07 PM9/2/15

to Russ Cox, golang-dev

I've just sent out CLs for cherry-picks for all of the closed issues in the 1.5.1 milestone.

https://go-review.googlesource.com/#/q/status:open+project:go+branch:release-branch.go1.5

Are there any other changes that need to be cherry-picked for the 1.5.1 release?

There are still 12 open issues on GitHub:

https://github.com/golang/go/issues?q=is%3Aissue+milestone%3AGo1.5.1+is%3Aopen

--cbro

On Tue, Aug 25, 2015 at 11:26 AM, Russ Cox <r...@golang.org> wrote:

Reply all

Reply to author

Forward