profile
viewpoint
Lynn Boger laboger IBM Rochester, MN

laboger/bosh-agent 0

BOSH Agent runs on each BOSH deployed VM

laboger/docker 0

Docker - the open-source application container engine

laboger/docker-network 0

Experimental network control tool for Docker

laboger/plan9 0

UC Berkeley release of Plan 9 under the GPLv2

issue commentgolang/go

runtime, x/net/internal/socket: thread sanitizer failing on ppc64le

The thread sanitizer failure was fixed on ppc64le with CL 214919.

randall77

comment created time in 2 days

issue commentgolang/go

runtime: gdb stepping behavior when debugging Go program on ppc64le changed when split-stack prologue marked non-preemptible

So if I set GODEBUG=asyncpreemptoff=1 then the problem doesn't happen. I'm not entirely sure that it only happens at the beginning of a function.

laboger

comment created time in 2 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

I ran the full test set 3 times and didn't see the pc-encoded error message. Appears to resolve it.

laboger

comment created time in 9 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

I also found that this program has trampolines due to its text size. So the program is very large, I'm not sure how I would get it to you? You could build it if you want, I put the directions below. It also seems like it would be good to have a test that walks through the pc-encoded table to detect where the errors are.

Building it is not too hard:

mkdir ~/openshift
export GOPATH=~/openshift
cd ~/openshift && mkdir -p src/github.com/openshift
cd src/github.com/openshift
git clone https://github.com/openshift/origin
cd origin
export PERMISSIVE_GO=y
make build-all
GOTEST_FLAGS='-p 8 -gcflags=all=-d=checkptr=0 -c' TIMEOUT=420s TEST_KUBE=true KUBERNETES_SERVICE_HOST= hack/test-go.sh vendor/k8s.io/kubernetes/pkg/registry/core/replicationcontroller/storage
laboger

comment created time in 12 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

This program is externally linked. And only happens if the -race option is used, which means it is linking in the .syso file, which is C code built by LLVM. So perhaps that combination is somehow causing the pc table to be inconsistent with the actual functions in the final program. Maybe running some significant tests with -race turned on will reproduce it.

One other note, all the failures I have seen with this message have isAsyncSafePoint on the stack that ends up calling pcvalue.

laboger

comment created time in 12 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

Here is what I get on another run:

runtime: invalid pc-encoded table f=github.com/openshift/origin/vendor/k8s.io/client-go/tools/clientcmd.LoadFromFile pc=0x11c0f090 targetpc=0x11c0f360 tab=[0/0]0x0

From the objdump of the test, here is the start and end of the LoadFromFile function:

0000000011c0e920 <github.com/openshift/origin/vendor/k8s.io/client-go/tools/clientcmd.LoadFromFile>: 11c0e920: 10 00 7e e8 ld r3,16(r30) 11c0e924: 18 fe 81 38 addi r4,r1,-488 11c0e928: 40 20 23 7c cmpld r3,r4

.....

11c0f088:   20 00 80 4e     blr
11c0f08c:   00 00 00 00     .long 0x0
11c0f090:   00 00 00 60     nop
11c0f094:   00 00 00 60     nop
11c0f098:   00 00 00 60     nop
11c0f09c:   00 00 00 60     nop

targetpc is this: 0000000011c0f360 <00000042.plt_call.madvise@@GLIBC_2.17>: 11c0f360: 18 00 41 f8 std r2,24(r1) 11c0f364: 70 82 82 e9 ld r12,-32144(r2) 11c0f368: a6 03 89 7d mtctr r12 11c0f36c: 20 04 80 4e bctr

laboger

comment created time in 13 days

issue openedgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

<!-- 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 go1.14rc1 linux/ppc64le <pre> $ go version

</pre>

Does this issue reproduce with the latest release?

yes

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

linux/ppc64le <details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

Build and tested Openshift using Go 1.14rc1 <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

No failures or legitimate error output.

What did you see instead?

Some failures provide error messages that include the following:

runtime: invalid pc-encoded table f=github.com/openshift/origin/vendor/k8s.io/api/imagepolicy/v1alpha1.(*ImageReview).SetOwnerReferences pc=0x11c0f710 targetpc=0x11c0f9c0 tab=[0/0]0x0
        value=-1 until pc=0x11c0f684
        value=-2 until pc=0x11c0f694
        value=-1 until pc=0x11c0f6c4
        value=0 until pc=0x11c0f6c8
        value=1 until pc=0x11c0f6d4
        value=0 until pc=0x11c0f6d8
        value=1 until pc=0x11c0f6dc
        value=0 until pc=0x11c0f710
fatal error: invalid runtime symbol table

goroutine 0 [idle]:
runtime: unexpected return pc for runtime.sigtramp called from 0x3fffb7f90478
stack: frame={sp:0xc000d7cf20, fp:0xc000d7cf80} stack=[0xc000d76000,0xc000d7e000)
000000c000d7ce20:  000000001005d728 <runtime.sigtrampgo+296>  0000000000000000
000000c000d7ce30:  0000000000000000  0000000000000000
000000c000d7ce40:  000000001005d624 <runtime.sigtrampgo+36>  0000000000000000
000000c000d7ce50:  0000000000000000  0000000000000000
000000c000d7ce60:  0000000000000000  000000c001588300
000000c000d7ce70:  0000000000000000  000000001005d75c <runtime.sigtrampgo+348>
000000c000d7ce80:  0000000012121c00  000000c000d7dd78
000000c000d7ce90:  000000c000d7d000  000000001007bacc <runtime.sigtramp+60>
000000c000d7cea0:  0000000000000000  0000000000000000
000000c000d7ceb0:  0000000000000000  000000c000000017
000000c000d7cec0:  000000c000d7dd78  000000c000d7d000
000000c000d7ced0:  000000c001542f00  0000000000000000
000000c000d7cee0:  0000000000000000  0000000000000000
000000c000d7cef0:  0000000000000000  0000000000000000
000000c000d7cf00:  0000000000000000  000000c001542f00
000000c000d7cf10:  000000c000d7dd78  000000c000d7d000
000000c000d7cf20: <00003fffb7f90478  0000000000000000
000000c000d7cf30:  0000000000000000  0000000000000000
000000c000d7cf40:  0000000000000017  000000c000d7dd78
000000c000d7cf50:  000000c000d7d000  0000000000000000
000000c000d7cf60:  0000000000000000  0000000000000000
000000c000d7cf70:  0000000000000000  0000000000000000
000000c000d7cf80: >00003ffc94f9e4a0  0000000000000000
000000c000d7cf90:  0000000000000000  0000000000000000
000000c000d7cfa0:  0000000000000000  0000000000000000
000000c000d7cfb0:  0000000000000000  0000000000000000
000000c000d7cfc0:  0000000000000000  0000000000000000
000000c000d7cfd0:  0000000000000000  0000000000000000
000000c000d7cfe0:  0000000000000000  0000000000000000
000000c000d7cff0:  0000000000000000  0000000000000000
000000c000d7d000:  0000000000000000  0000000000000000
000000c000d7d010:  000000c000d76000  0000000000000000
000000c000d7d020:  0000000000008000  0000000000000000
000000c000d7d030:  0000000000000000  0000000000000000
000000c000d7d040:  0000000000000000  0000000000000000
000000c000d7d050:  0000000000000000  0000000000000000
000000c000d7d060:  0000000000000000  0000000000000000
000000c000d7d070:  0000000000000000  0000000000000000
runtime.throw(0x1206f12b, 0x1c)
        /home/boger/golang/go1.14rc1/go/src/runtime/panic.go:1112 +0x5c
runtime.pcvalue(0x135f6568, 0x136c1ec0, 0x4825e7, 0x11c0f9c0, 0x0, 0x11c0f901, 0x136c1ec0)
        /home/boger/golang/go1.14rc1/go/src/runtime/symtab.go:726 +0x4b0
runtime.pcdatavalue(0x135f6568, 0x136c1ec0, 0x0, 0x11c0f9c0, 0x0, 0x2)
        /home/boger/golang/go1.14rc1/go/src/runtime/symtab.go:814 +0x94
runtime.isAsyncSafePoint(0xc001542f00, 0x11c0f9c0, 0x3ffc94f9e4a0, 0x11c39350, 0x0)
        /home/boger/golang/go1.14rc1/go/src/runtime/preempt.go:396 +0x100
runtime.doSigPreempt(0xc001542f00, 0xc000d7ce88)
        /home/boger/golang/go1.14rc1/go/src/runtime/signal_unix.go:329 +0x120
runtime.sighandler(0xc000000017, 0xc000d7dd78, 0xc000d7d000, 0xc001542f00)
        /home/boger/golang/go1.14rc1/go/src/runtime/signal_unix.go:536 +0x708
runtime.sigtrampgo(0x17, 0xc000d7dd78, 0xc000d7d000)
        /home/boger/golang/go1.14rc1/go/src/runtime/signal_unix.go:444 +0x18c
runtime: unexpected return pc for runtime.sigtramp called from 0x3fffb7f90478
stack: frame={sp:0xc000d7cf20, fp:0xc000d7cf80} stack=[0xc000d76000,0xc000d7e000)
000000c000d7ce20:  000000001005d728 <runtime.sigtrampgo+296>  0000000000000000
000000c000d7ce30:  0000000000000000  0000000000000000
000000c000d7ce40:  000000001005d624 <runtime.sigtrampgo+36>  0000000000000000
000000c000d7ce50:  0000000000000000  0000000000000000
000000c000d7ce60:  0000000000000000  000000c001588300
000000c000d7ce70:  0000000000000000  000000001005d75c <runtime.sigtrampgo+348>
000000c000d7ce80:  0000000012121c00  000000c000d7dd78
000000c000d7ce90:  000000c000d7d000  000000001007bacc <runtime.sigtramp+60>
000000c000d7cea0:  0000000000000000  0000000000000000
000000c000d7ceb0:  0000000000000000  000000c000000017
000000c000d7cec0:  000000c000d7dd78  000000c000d7d000
000000c000d7ced0:  000000c001542f00  0000000000000000
000000c000d7cee0:  0000000000000000  0000000000000000
000000c000d7cef0:  0000000000000000  0000000000000000
000000c000d7cf00:  0000000000000000  000000c001542f00
000000c000d7cf10:  000000c000d7dd78  000000c000d7d000
000000c000d7cf20: <00003fffb7f90478  0000000000000000
000000c000d7cf30:  0000000000000000  0000000000000000
000000c000d7cf40:  0000000000000017  000000c000d7dd78
000000c000d7cf50:  000000c000d7d000  0000000000000000
000000c000d7cf60:  0000000000000000  0000000000000000
000000c000d7cf70:  0000000000000000  0000000000000000
000000c000d7cf80: >00003ffc94f9e4a0  0000000000000000
000000c000d7cf90:  0000000000000000  0000000000000000
000000c000d7cfa0:  0000000000000000  0000000000000000
000000c000d7cfb0:  0000000000000000  0000000000000000
000000c000d7cfc0:  0000000000000000  0000000000000000
000000c000d7cfd0:  0000000000000000  0000000000000000
000000c000d7cfe0:  0000000000000000  0000000000000000
000000c000d7cff0:  0000000000000000  0000000000000000
000000c000d7d000:  0000000000000000  0000000000000000
000000c000d7d010:  000000c000d76000  0000000000000000
000000c000d7d020:  0000000000008000  0000000000000000
000000c000d7d030:  0000000000000000  0000000000000000
000000c000d7d040:  0000000000000000  0000000000000000
000000c000d7d050:  0000000000000000  0000000000000000
000000c000d7d060:  0000000000000000  0000000000000000
000000c000d7d070:  0000000000000000  0000000000000000
runtime.sigtramp(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/boger/golang/go1.14rc1/go/src/runtime/sys_linux_ppc64x.s:346 +0x3c

goroutine 1235 [running]:
FAIL    github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/replicationcontroller/storage    16.260s

The good news is that this bad symbol table output appears for some test failures every time the tests are run. The bad news, it is not always the same test that fails and I can not get the test to fail if it is run by itself, only when the whole set is run.

The bad symbol table message does not happen before commit 14849f0. If I build and test with anything after f511467 the error message occurs. Between these two commits, testing results in the message about unaligned sysUnused.

I am trying to find a smaller reproducer and also see if it fails on x86. It only fails with -race and -d=checkptr=0. If I don't turn off checkptr=0 then the unsafe pointer message occurs.

created time in 13 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

@cherrymui It is not happening with profiling but fails with -race -d=checkptr=0. If I turn off -race it gets a different error. I'll open a new issue.

tonyghita

comment created time in 13 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

I am still working on trying to narrow down the failure that happens on ppc64le. Should I open a separate issue for that?

I believe it began when the page allocator changed in early November but still trying to verify and find a smaller reproducer.

tonyghita

comment created time in 13 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

We see this error in testing Openshift when compiled with go1.14rc1 on ppc64le. By default this testing is done with the -race option on, and that results in a few dozen errors about unsafe pointer arithmetic, since -race now turns on checkptr testing.

If I then run the tests with checkptr=0 along with -race, then I see the same with the invalid pc-encoded symbol table as above.

I'm still trying to isolate the conditions which cause this consistently because from run to run the failures are sometimes different. So far it has only happens when running all the tests, if I try to just run a test that previously failed by itself it does not fail. If I test without -race then different errors occur.

tonyghita

comment created time in 15 days

issue openedgolang/go

runtime: gdb stepping behavior when debugging Go program on ppc64le changed when split-stack prologue marked non-preemptible

<!-- 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 go1.14rc1 </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 linux/ppc64le </pre></details>

What did you do?

Tried to debug Go program on ppc64le using gdb by breaking at a function's address then stepping through the first several instructions. <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

Normal gdb behavior, gdb prompt returning within a reasonable amount of time (usually immediately) when stepping through code at the beginning of a function. This type of stepping works normally for programs compiled with Go 1.13.

I found that this behavior started with b2482e4, so with that knowledge I now know that if I break after the split-stack prologue code the hanging/delay doesn't happen and only happens with functions that have split-stack prologue.

What did you see instead?

Break at the beginning of a function that has a split-stack prolog using its address. After typing 'ni' to go to the next instruction, gdb hangs and the prompt can take a long time and sometimes does not return (or I didn't wait long enough).

created time in 19 days

issue commentgolang/go

libgo: regression in runtime test TestCallersNilPointerPanic on ppc64le with Go 1.14beta1 update

Oh right, I didn't check to see if it was a new test. Do you want me to change the title?

I tried the //go:noinline suggestion and the test still failed.

laboger

comment created time in a month

issue openedgolang/go

libgo: hang in syscall test TestExecPtrace on ppc64le starting sometime in Go 1.13, continuing in Go 1.14beta1beta1

<!-- 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.14beta1 gccgo (GCC) 10.0.1 20200122 (experimental) linux/ppc64le </pre>

Does this issue reproduce with the latest release?

Started in Go 1.13, continues in Go 1.14beta1

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env linux/ppc64le </pre></details>

What did you do?

Running the libgo tests on ppc64le <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

No failures

What did you see instead?

Hang in the syscall test TestExecPtrace which does not happen on golang. This was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567

created time in a month

issue openedgolang/go

libgo: SEGV in runtime test TestChan on ppc64le

<!-- 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.14beta1 gccgo (GCC) 10.0.1 20200122 (experimental) linux/ppc64le </pre>

Does this issue reproduce with the latest release?

This started happening in Go 1.13 and was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564. Continues to happen in Go 1.14beta1

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env linux/ppc64le </pre></details>

What did you do?

Run the libgo tests <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

No failures

What did you see instead?

=== RUN TestChan fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x2 addr=0x7214a61c0000 pc=0x1008eb24]

More details, stacks, and gdb information can be found in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564

created time in a month

issue openedgolang/go

libgo: regression in runtime test TestCallersNilPointerPanic on ppc64le with Go 1.14beta1 update

<!-- 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.14beta1 gccgo (GCC) 10.0.1 20200122 (experimental) linux/ppc64le </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 linux/ppc64le </pre></details>

What did you do?

run the libgo tests <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

Passing tests

What did you see instead?

=== RUN TestCallersNilPointerPanic TestCallersNilPointerPanic: callers_test.go:82: wanted [runtime.Callers runtime_test.TestCallersNilPointerPanic..func1 runtime.gopanic runtime.panicmem runtime.sigpanic runtime_test.TestCallersNilPointerPanic], got [runtime.Callers runtime_test.TestCallersNilPointerPanic..func1 runtime.gopanic runtime.panicmem runtime_test.TestCallersNilPointerPanic testing.tRunner] --- FAIL: TestCallersNilPointerPanic (0.00s)

created time in a month

issue openedgolang/go

libgo: build failure on ppc64le since Go 1.14beta1 update: implicit declaration of function ‘runtime_nanotime

<!-- 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.14beta1 gccgo (GCC) 10.0.1 20200122 (experimental) linux/ppc64le </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 linux/ppc64le </pre></details>

What did you do?

Tried to do a build of gccgo after the update to Go 1.14 in master/trunk. <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

No errors.

What did you see instead?

libtool: compile: /home/boger/gccgo.git.work/bld/./gcc/xgcc -B/home/boger/gccgo.git.work/bld/./gcc/ -B/usr/local/gccgo.trunk/powerpc64le-linux/bin/ -B/usr/local/gccgo.trunk/powerpc64le-linux/lib/ -isystem /usr/local/gccgo.trunk/powerpc64le-linux/include -isystem /usr/local/gccgo.trunk/powerpc64le-linux/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgo -I ../../../gcc/libgo/runtime -I../../../gcc/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../gcc/libgo/../libgcc -I ../../../gcc/libgo/../libbacktrace -I ../../gcc/include -g -O2 -MT runtime/print.lo -MD -MP -MF runtime/.deps/print.Tpo -c ../../../gcc/libgo/runtime/print.c -o runtime/print.o >/dev/null 2>&1 ../../../gcc/libgo/runtime/runtime_c.c: In function ‘runtime_cputicks’: ../../../gcc/libgo/runtime/runtime_c.c:100:10: error: implicit declaration of function ‘runtime_nanotime’; did you mean ‘runtime_nanotime1’? [-Werror=implicit-function-declaration] 100 | return runtime_nanotime() + randomNumber; | ^~~~~~~~~~~~~~~~ | runtime_nanotime1

Changing the call of runtime_nanotime to runtime_nanotime1 fixes the build, but haven't tested it yet.

created time in a month

issue commentgolang/go

time: NewTicker will not emit ticks at a frequency greater than 1/sec on qemu user mode ppc64le

This issue described a QEMU bug for ppc64le which could be related. Check the QEMU versions to see if you have one that includes the QEMU fix.

https://github.com/golang/go/issues/34139

patrickmeiring

comment created time in a month

issue commentgolang/go

x/build: use Google Cloud for aix/ppc64 and linux/ppc64x builders

Interesting, but I doubt it supports linux/ppc64, probably only linux/ppc64le.

bradfitz

comment created time in a month

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

@aclements, it sounds to me like we need to add "--security-opt", "seccomp=unconfined", to x/build/cmd/rundockerbuildlet.

Yes, I think that would be the easiest for now. There could be something documented to state that the use of the race detector within a container requires this option when starting the container.

randall77

comment created time in 2 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

Since my last post I was able to reproduce this in a container. I have confirmed the theory that was mentioned in my post on Nov. 18.

When running LLVM's thread sanitizer code (used by Go's race detector) on a system with ASLR enabled, the address mappings needed for the thread sanitizer are not always usable on ppc64le so it calls the personality syscall to disable ASLR. Outside of a container this works fine, but within a container that is running with the default seccomp profile, it fails as in this testcase. This is because the default seccomp profile restricts the use of the personality syscall.

One solution would be to have an alternate security profile which allows the personality syscall and then use that profile for the container where the testing is done.

If you don't care about the seccomp profile for the container then the container can be run using --security-opt seccomp=unconfined. The test works if that option is used.

This does not fail on amd64 because they don't have the same problem with address ranges apparently. It is needed on arm64 but I don't think they have the race detector working for Go yet.

randall77

comment created time in 2 months

issue commentgolang/go

x/net/http2: TestTransportBody* flaky on android and ppc64

I see this failure intermittently on ppc64le for both power8 and 9 as well as ppc64.

It started soon after this: https://go-review.googlesource.com/c/net/+/181157, which is the change that added the test and the expected error message.

bcmills

comment created time in 2 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

The test starts to fail after I checked in CL https://go-review.googlesource.com/c/go/+/209659, which doesn't seem to be quite related. That CL could make the file size increases or decreases slightly (as it changes some PCDATA), for both exe and pie.

@cherrymui I am testing outside of a container. The test starts the fail with the commit where it was added when I build and test on my Ubuntu 16.04 system. Based on Ian's last comment, it seems to be somewhat random depending on section offsets and sizes.

laboger

comment created time in 3 months

issue openedgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

cmd/link test TestPIESize fails on tip on the ppc64le builders, both power8 and power9.

On some systems, it fails consistently after this test was added. On some systems, which have newer distros it passes. On the dashboard, it didn't start failing until a few commits after that test was added, not sure why.

When it works for me, ld is >= 2.31. It works for me on a Debian Buster machine with gcc 8.3.0 and ld 2.31 and I thought that was what the builders were using so that's a mystery too. The failures occur when ld <= 2.30. Possibly this is related to which systems have gcc pass -pie by default to ld but haven't verified that. @ianlancetaylor

created time in 3 months

issue closedgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version go version go1.12.12 linux/ppc64le </pre>

Does this issue reproduce with the latest release?

The incorrect code exists in the latest release. The failure will only happen when trying to look up the textOff for an off that is at the end of a text section if there are multiple text sections. Multiple text sections are not common but do happen in Kubernetes and Openshift.

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env linux/ppc64le RHEL 7.5 </pre></details>

What did you do?

Built and ran the tests for Openshift. By default -race is used for testing.

mkdir -p ~/gocode/src/github.com/openshift
cd ~/gocode/src/github.com/openshift
git clone https://github.com/openshift/origin
cd ~/gocode/src/github.com/openshift/origin
export GOCODE=~/gocode

To run all the tests:

GOTEST_FLAGS='-p 8' TIMEOUT=360s TEST_KUBE=true KUBERNETES_SERVICE_HOST= hack/test-go.sh

To run the test that just fails:

go test -p 8 -race -cover -covermode atomic -timeout 360s github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage

What did you expect to see?

No failures.

What did you see instead?

[boger@moose1 origin]$ go test -p 8 -race -cover -covermode atomic -timeout 360s github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage
unexpected fault address 0xfe1e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xfe1e pc=0x3fffb7da84fc]

goroutine 1 [running, locked to thread]:
runtime.throw(0x121b0080, 0x5)
	/home/boger/golang/go1.12/go/src/runtime/panic.go:617 +0x5c fp=0xc000596100 sp=0xc0005960c0 pc=0x1003f44c
runtime: unexpected return pc for runtime.sigpanic called from 0x3fffb7da84fc
stack: frame={sp:0xc000596100, fp:0xc000596140} stack=[0xc000578000,0xc000598000)
000000c000596000:  00000000121ae2b3  0000000000000001 
000000c000596010:  0000000000000001  0000000000000000 
000000c000596020:  0000000010040820 <runtime.printstring+112>  00000000146d6520 
000000c000596030:  0000000000000002  000000c0005960f6 
000000c000596040:  0000000000000002  00000000121ae2b3 
000000c000596050:  0000000000000001  000000001003f608 <runtime.fatalthrow+72> 
000000c000596060:  0000000010057f7c <runtime.sigpanic+1036>  0000000000000001 
000000c000596070:  0000000010040128 <runtime.printnl+56>  000000001003f44c <runtime.throw+92> 
000000c000596080:  000000c0005960f6  0000000000000006 
000000c000596090:  00000000121ae2b3  000000c0005960a0 
000000c0005960a0:  000000001006e000 <runtime.fatalthrow.func1+0>  000000c000000180 
000000c0005960b0:  000000001003f44c <runtime.throw+92>  000000c0005960c0 
000000c0005960c0:  0000000010057f9c <runtime.sigpanic+1068>  0000000000000001 
000000c0005960d0:  0000000010057f80 <runtime.sigpanic+1040>  0000000010057f84 <runtime.sigpanic+1044> 
000000c0005960e0:  000000c0005960e8  000000001006df80 <runtime.throw.func1+0> 
000000c0005960f0:  00000000121b0080  0000000000000005 
000000c000596100: <00003fffb7da84fc  0000000012671a80 
000000c000596110:  0000000011ef39a0  000000001226d068 
000000c000596120:  00000000121b0080  0000000000000005 
000000c000596130:  0000000010467ba4 <encoding/json.typeFields+6132>  000000000000fe1e 
000000c000596140: >00003fffb7db2c54  0000000000000000 
000000c000596150:  0000000010467cfc <encoding/json.cachedTypeFields+220>  000000001056a264 <text/template/parse.(*Tree).operand+52> 
000000c000596160:  000000c0005967d0  0000000011ef9c40 
000000c000596170:  000000c0001df558  0000000011ef39a0 
000000c000596180:  000000001226d068  0000000000000002 
000000c000596190:  0000000000000002  0000000012671a80 
000000c0005961a0:  0000000011ef39a0  000000c000378280 
000000c0005961b0:  000000000000000a  0000000000000018 
000000c0005961c0:  0000000000000028  000000c000378208 
000000c0005961d0:  0000000000000001  0000000000000001 
000000c0005961e0:  0000000000000000  0000000010166c00 <regexp/syntax.(*compiler).compile+6640> 
000000c0005961f0:  0000000010165730 <regexp/syntax.(*compiler).compile+1312>  0000000012671a80 
000000c000596200:  0000000000000025  0000000000000043 
000000c000596210:  0000000000000009  0000000000000002 
000000c000596220:  0000000000000001  0000000000000003 
000000c000596230:  0000000000000007  0000000000000002 
runtime.sigpanic()
	/home/boger/golang/go1.12/go/src/runtime/signal_unix.go:397 +0x42c fp=0xc000596140 sp=0xc000596100 pc=0x10057f9c

goroutine 19 [chan receive]:
github.com/openshift/origin/vendor/k8s.io/klog.(*loggingT).flushDaemon(0x13d2bb60)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/k8s.io/klog/klog.go:1018 +0x90
created by github.com/openshift/origin/vendor/k8s.io/klog.init.0
	/home/boger/gocode/src/github.com/openshift/origin/vendor/k8s.io/klog/klog.go:404 +0x84

goroutine 93 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000150920)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8

goroutine 128 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000288fa0)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8

goroutine 126 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000288e20)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8
FAIL	github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage	0.106s

I have a fix for this. After debugging I found that the problem is in runtime/type.go function textOff where it looks up the text offset from an offset. If the 'off' happens to be the last value in the text section, the wrong value is returned.

closed time in 3 months

laboger

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

Yes, resolved on tip.

laboger

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

Can I get gomote access so I can try to understand this problem a bit more. It is curious as to why some race tests work fine (I think they must all have to do the personality syscall) but this one does not. Also I am not able to reproduce it.

randall77

comment created time in 3 months

issue commentgolang/go

runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet

I don't think we've seen this since the move to Docker with a more recent kernel.

bcmills

comment created time in 3 months

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present [1.12 backport]

The applications which require multiple text sections are Openshift and Kubernetes because of the unusually large text sections they generate. When the error occurs, it is difficult to debug and there is no workaround. Also, these applications require a backlevel Go version for their builds, for example Openshift is using Go 1.12 at this time, so I doubt telling them to move up to the latest version is acceptable.

The fix is in this case is extremely simple and safe.

gopherbot

comment created time in 3 months

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present [1.13 backport]

The applications which require multiple text sections are Openshift and Kubernetes because of the unusually large text sections they generate. When the error occurs, it is difficult to debug and there is no workaround. Also, these applications require a backlevel Go version for their builds, for example Openshift is using Go 1.12 at this time, so I doubt telling them to move up to the latest version is acceptable.

The fix is in this case is extremely simple and safe.

gopherbot

comment created time in 3 months

issue commentgolang/go

cmd/dist: "unexpected stale targets" on linux-ppc64le-power9osu builder

I think that was the problem. Now that the old buildlet isn't running, I am not seeing the error. When it did happen, it was failing every 5 or 6 runs which would make sense since that was the 6th one in the pool.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/dist: "unexpected stale targets" on linux-ppc64le-power9osu builder

I found that the old power9 builder was still active out in the farm (not running Docker). Not sure but maybe these errors were happening if that buildlet was being used, since the error happened intermittently. Carlos has shut down that buildlet and we will see if that makes a difference.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/dist: "unexpected stale targets" on linux-ppc64le-power9osu builder

The errlogs look strange, almost like the build hasn't even started yet. It doesn't display the line that says it is building go_bootstrap or even the one that provides the detail about the test run.

bcmills

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

OK I think I found out the issue. When a Docker container is set up, there is a default seccomp security profile with a list of syscalls that are not allowed. The personality syscall is on that list. There is a way to define the container so it allows this syscall.

randall77

comment created time in 3 months

issue commentgolang/go

proposal: add gnu assembler output as comments alongside Go assembler in Go objdump output

An option would be great. I wasn't sure on the policy of adding new options to Go's objdump tool.

laboger

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

Look up the documentation for the Linux personality syscall (you can google it). In this case the value of ADDR_NO_RANDOMIZE is not a setting on the binary but a setting for the personality of the process. If the syscall returns -1 (EINVAL) that means the kernel could not change the personality.

To me it looks like even though the syscall fails it continues to try to ReExec regardless of the syscall result but the comments say the race detector doesn't work in ASLR mode (due to unexpected address ranges) and in this test it is supposed to detect a race condition but does not so fails.

I don't know why it would fail to change the personality in this case -- it must work in some cases because this code is executed whenever using race on ppc64le and distros have had ASLR enabled for a while. Maybe if we had the errno that would help.

randall77

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

If I look at the code from LLVM from the error output I see this:

#elif SANITIZER_PPC64V2
  // Disable ASLR for Linux PPC64LE.
  int old_personality = personality(0xffffffff);
  if (old_personality != -1 && (old_personality & ADDR_NO_RANDOMIZE) == 0) {
    VReport(1, "WARNING: Program is being run with address space layout "
               "randomization (ASLR) enabled which prevents the thread and "
               "memory sanitizers from working on powerpc64le.\n"
               "ASLR will be disabled and the program re-executed.\n");
    CHECK_NE(personality(old_personality | ADDR_NO_RANDOMIZE), -1);
    ReExec();
  }

So I believe that error message is saying the test system has ASLR enabled but should be rerun without it? So the message is not really an error?

randall77

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

I ran all the race tests I know about in golang. They all passed on my power8 and power9.

in runtime/race: go test -race


Passed 348 of 348 tests (100.00%, 0+, 0-)
0 expected failures (0 has not fail)
--- PASS: TestRace (6.42s)
=== RUN   TestIssue8102
--- PASS: TestIssue8102 (0.00s)
=== RUN   TestIssue9137
--- PASS: TestIssue9137 (0.00s)
=== RUN   TestNonGoMemory
--- PASS: TestNonGoMemory (0.00s)
=== RUN   TestRandomScheduling
--- PASS: TestRandomScheduling (0.01s)
PASS
ok  	runtime/race	15.214s

In golang.org/x/net at the commit from the failure:

:~/gocode/src/golang.org/x/net/internal/socket$ go test -test.v
=== RUN   TestSocket
=== RUN   TestSocket/Option
--- PASS: TestSocket (0.01s)
    --- PASS: TestSocket/Option (0.01s)
=== RUN   TestControlMessage
--- PASS: TestControlMessage (0.00s)
=== RUN   TestUDP
=== RUN   TestUDP/Message
=== RUN   TestUDP/Messages
--- PASS: TestUDP (0.00s)
    --- PASS: TestUDP/Message (0.00s)
    --- PASS: TestUDP/Messages (0.00s)
=== RUN   TestRace
=== RUN   TestRace/test_0
=== RUN   TestRace/test_1
--- PASS: TestRace (1.98s)
    --- PASS: TestRace/test_0 (0.98s)
    --- PASS: TestRace/test_1 (0.99s)
PASS
ok  	golang.org/x/net/internal/socket	1.997s
boger@yanny6:~/gocode/src/golang.org/x/net/internal/socket$ uname -a
Linux yanny6 4.19.0-5-powerpc64le #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) ppc64le GNU/Linux
go tool dist test race

##### Testing race detector
ok  	runtime/race	7.897s
ok  	flag	0.025s
ok  	net	0.104s
ok  	os	0.115s
ok  	os/exec	0.083s
ok  	encoding/gob	0.036s
ok  	flag	0.028s
ok  	os/exec	0.077s

ALL TESTS PASSED (some were excluded)

I do not have gomote access. Isn't the error message about personality related to some kind of system or kernel setting?

randall77

comment created time in 3 months

issue commentgolang/go

runtime: thread sanitizer failing on ppc64le

Once again, I am not able to reproduce this failure. Maybe I'm not building and running this like is done with the buildlet.

I checked out the latest golang.org/x/net and rebuilt it with upstream Go. The tests all passed on my debian buster power9 machine.

I see the test says it is testing in module mode. Not exactly sure what that means. Is there documentation on how to run all the golang.org/x repos? I did copy the old go.mod file it was using and set up GOMOD to point to it and it still passed.

randall77

comment created time in 3 months

issue commentgolang/go

runtime: TestArenaCollision has many "out of memory" failures on linux-ppc64le-power9osu

I noticed this the other day and I am not able to reproduce the problem either on any of our systems.

bcmills

comment created time in 3 months

issue commentgolang/go

runtime: fatal error: unaligned sysUnused on Linux/PPC64LE

I'm sure this is because of CLs 201765 and 195700 because we never saw this error before that. I believe CL 206277 fixes it.

cherrymui

comment created time in 4 months

issue commentgolang/go

net,net/http,crypto/tls: some tests fail if network addresses have been translated

I thought if there was a way to determine if the network mappings were not the usual default, then just skip the test. I could test it with some suggestions on how to check for that.

laboger

comment created time in 4 months

issue commentgolang/go

cmd/compile: make rulegen produce less verbose code

I think we can open a new issue if we find a way to make the idea work. Unless @mundaym wants to keep this one open.

mvdan

comment created time in 4 months

issue openedgolang/go

net,net/http,crypto/tls: some tests fail if network addresses have been translated

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version go version devel +14a133f Tue Nov 5 21:16:50 2019 +0000 linux/ppc64le go version go1.13 gccgo (GCC) 10.0.0 20191105 (experimental) linux/ppc64le </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> linux/ppc64le power8

</pre></details>

What did you do?

Trying to run the golang and gccgo tests for net, net/http, and crypto/tls on a system where someone had done network address translation. See below for example of how it could be reproduced.

What did you expect to see?

PASS

What did you see instead?

~/golang/plain/go/src/net$ ./net.test 
--- FAIL: TestConnAndPacketConn (0.50s)
    packetconn_test.go:152: read udp 127.0.0.1:37440->127.0.0.1:38376: i/o timeout
--- FAIL: TestUDPServer (110.09s)
    server_test.go:320: #0: read udp 127.0.0.1:39312: i/o timeout
    server_test.go:320: #1: read udp 127.0.0.1:34202: i/o timeout
    server_test.go:320: #2: read udp 127.0.0.1:44195: i/o timeout
    server_test.go:320: #7: read udp 127.0.0.1:51421: i/o timeout
    server_test.go:320: #8: read udp4 127.0.0.1:53997: i/o timeout
    server_test.go:320: #9: read udp4 127.0.0.1:58202: i/o timeout
    server_test.go:320: #10: read udp4 127.0.0.1:55888: i/o timeout
    server_test.go:320: #15: read udp4 127.0.0.1:36888: i/o timeout
    server_test.go:320: #19: read udp4 127.0.0.1:37530: i/o timeout
    server_test.go:320: #20: read udp4 127.0.0.1:50267: i/o timeout
    server_test.go:320: #21: read udp4 127.0.0.1:57797: i/o timeout
FAIL
~/golang/plain/go/src/net/http$ ./http.test
--- FAIL: TestSetsRemoteAddr_h1 (0.00s)
    serve_test.go:1248: Expected local addr; got "9.40.192.157:50248"
--- FAIL: TestSetsRemoteAddr_h2 (0.01s)
    serve_test.go:1248: Expected local addr; got "9.40.192.157:42918"
FAIL
~/golang/plain/go/src/crypto/tls$ ./tls.test
--- FAIL: TestDynamicRecordSizingWithStreamCipher (5.00s)
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38236 != 127.0.0.1:38236
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38236
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38238 != 127.0.0.1:38238
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38238
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38240 != 127.0.0.1:38240
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38240
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38242 != 127.0.0.1:38242
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38242
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38244 != 127.0.0.1:38244
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38244
    handshake_test.go:293: localPipe: failed to connect: <nil>
..... lots more

We found that doing something like this

sudo iptables -t nat -A POSTROUTING -j MASQUERADE

Will result in these failures and then this

sudo iptables -t nat -F POSTROUTING

makes it work again.

Fails on this system in the same way in gccgo and golang. Doesn't fail on systems with normal network address settings.

created time in 4 months

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

This fix for this is already upstream in CL 203817. Backports are pending.

laboger

comment created time in 4 months

issue commentgolang/go

x/build: misc/reboot.TestRepeatBootstrap flaky during toolchain3 on linux-ppc64le-*

I thought there would be more information about the failure than just "exit status 2".

This test appears to be rebuilding the toolchain using the toolchain it just built as its bootstrap compiler. Doesn't that mean it will be changing/updating components of the toolchain as it is using those components for the new build?

go build cmd/compile/internal/ssa: /workdir/tmp/reboot-goroot202913779/pkg/tool/linux_ppc64le/compile: exit status 1
go tool dist: FAILED: /workdir/tmp/reboot-goroot202913779/pkg/tool/linux_ppc64le/go_bootstrap install -gcflags=all= -ldflags=all= -a -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 1
--- FAIL: TestRepeatBootstrap (100.86s)
    reboot_test.go:50: exit status 2

Here it is using /workdir/tmp/reboot-goroot202913779/pkg/tool/linux_ppc64le/compile to compile with but the result is an install of cmd/compile.

bcmills

comment created time in 4 months

issue commentgolang/go

cmd/compile: ppc64le broken by encourage inlining of functions with single-call bodies

I haven't seen this problem in a while on ppc64x. I think it was left open due to similar issues on other platforms. I think it can be closed.

bradfitz

comment created time in 4 months

issue commentgolang/go

x/build: misc/reboot.TestRepeatBootstrap flaky during toolchain3 on linux-ppc64le-*

Can the test be modified to print out more information about the failure? Maybe stderr has more information. Exit status 2 is not enough. Who could be sending a kill signal, could that due to timing out? I'll see if I can reproduce the problem.

On Tue, Oct 29, 2019 at 8:04 AM Bryan C. Mills notifications@github.com wrote:

The linux-ppc64le builders are frequently failing in TestRepeatBootstrap.

The failure mode seems to always be a compile error when building cmd/compile/internal/ssa during the Building Go toolchain3 step.

Sometimes the compile command fails with exit status 1 ( https://build.golang.org/log/91e2d3f5fd454609faf1f004a756382ad5aa6e20). Sometimes it instead fails with signal: killed ( https://build.golang.org/log/00d4e0a84ece047eaa53251c7c4fc0955bba8eea).

Is it possible that this step is running out of RAM?

CC @randall77 https://github.com/randall77 @bradfitz https://github.com/bradfitz @dmitshur https://github.com/dmitshur @laboger https://github.com/laboger

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35233?email_source=notifications&email_token=ACH7BDCNG3XLAHJ4ZKOGZBDQRAYFJA5CNFSM4JGIGKRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HVBQLYA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH7BDF47DCPW2AZH5XRCWTQRAYFJANCNFSM4JGIGKRA .

bcmills

comment created time in 4 months

issue commentgolang/go

x/sys/unix: TestSchedSetaffinity failing on linux-ppc64le-buildlet

Can you check if the test on that system has the change from this patch? Maybe for some reason the x/sys/unix version is not correct.

On Sat, Oct 26, 2019 at 7:59 AM Bryan C. Mills notifications@github.com wrote:

From linux-ppc64le-buildlet ( https://build.golang.org/log/1e46452b18adf5f3b2ec28dfcee7bc28bf55be10):

--- FAIL: TestSchedSetaffinity (0.00s) syscall_linux_test.go:366: SchedSetaffinity: invalid argument FAIL FAIL golang.org/x/sys/unix 0.568s

See previously #27875 https://github.com/golang/go/issues/27875.

CC @tklauser https://github.com/tklauser @laboger https://github.com/laboger

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35184?email_source=notifications&email_token=ACH7BDDFWPGBIKTD7B4JSWTQQQ5MJA5CNFSM4JFNF27KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HURGSXQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH7BDGOGSRYVQBOJKVU6DLQQQ5MJANCNFSM4JFNF27A .

bcmills

comment created time in 4 months

issue commentgolang/go

runtime/debug: SIGSEGV in dumpgoroutine

The Goexit failure is discussed here https://github.com/golang/go/issues/34575

On Sat, Oct 26, 2019 at 3:05 AM Cuong Manh Le notifications@github.com wrote:

Seems a flaky for me, another fail https://build.golang.org/log/ac9672a53d4ece77dcb8acca1cf4a468c719cceb

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35172?email_source=notifications&email_token=ACH7BDFBHYMN4RAQ44MD6DDQQP24BA5CNFSM4JFLKWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKCSSY#issuecomment-546580811, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH7BDCMRBKB7VJLG2U6SATQQP24BANCNFSM4JFLKWLA .

bcmills

comment created time in 4 months

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

@gopherbot Please backport to go 1.13 and go 1.12.

laboger

comment created time in 4 months

issue commentgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

The segv occurs in encoding/json/decode.go function literalStore when trying to invoke the UnmarshalJSON function. The address of that function is incorrect because in the function indirect this code:

if u, ok := v.Interface().(Unmarshaler); ok {
                                return u, nil, reflect.Value{}
}
``
depends on the tab lookup using textOff and gets an invalid value.
laboger

comment created time in 4 months

issue openedgolang/go

runtime: function textOff returns incorrect value if multiple text sections are present

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version go version go1.12.12 linux/ppc64le </pre>

Does this issue reproduce with the latest release?

The incorrect code exists in the latest release. The failure will only happen when trying to look up the textOff for an off that is at the end of a text section if there are multiple text sections. Multiple text sections are not common but do happen in Kubernetes and Openshift.

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env linux/ppc64le RHEL 7.5 </pre></details>

What did you do?

Built and ran the tests for Openshift. By default -race is used for testing.

mkdir -p ~/gocode/src/github.com/openshift
cd ~/gocode/src/github.com/openshift
git clone https://github.com/openshift/origin
cd ~/gocode/src/github.com/openshift/origin
export GOCODE=~/gocode

To run all the tests:

GOTEST_FLAGS='-p 8' TIMEOUT=360s TEST_KUBE=true KUBERNETES_SERVICE_HOST= hack/test-go.sh

To run the test that just fails:

go test -p 8 -race -cover -covermode atomic -timeout 360s github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage

What did you expect to see?

No failures.

What did you see instead?

[boger@moose1 origin]$ go test -p 8 -race -cover -covermode atomic -timeout 360s github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage
unexpected fault address 0xfe1e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xfe1e pc=0x3fffb7da84fc]

goroutine 1 [running, locked to thread]:
runtime.throw(0x121b0080, 0x5)
	/home/boger/golang/go1.12/go/src/runtime/panic.go:617 +0x5c fp=0xc000596100 sp=0xc0005960c0 pc=0x1003f44c
runtime: unexpected return pc for runtime.sigpanic called from 0x3fffb7da84fc
stack: frame={sp:0xc000596100, fp:0xc000596140} stack=[0xc000578000,0xc000598000)
000000c000596000:  00000000121ae2b3  0000000000000001 
000000c000596010:  0000000000000001  0000000000000000 
000000c000596020:  0000000010040820 <runtime.printstring+112>  00000000146d6520 
000000c000596030:  0000000000000002  000000c0005960f6 
000000c000596040:  0000000000000002  00000000121ae2b3 
000000c000596050:  0000000000000001  000000001003f608 <runtime.fatalthrow+72> 
000000c000596060:  0000000010057f7c <runtime.sigpanic+1036>  0000000000000001 
000000c000596070:  0000000010040128 <runtime.printnl+56>  000000001003f44c <runtime.throw+92> 
000000c000596080:  000000c0005960f6  0000000000000006 
000000c000596090:  00000000121ae2b3  000000c0005960a0 
000000c0005960a0:  000000001006e000 <runtime.fatalthrow.func1+0>  000000c000000180 
000000c0005960b0:  000000001003f44c <runtime.throw+92>  000000c0005960c0 
000000c0005960c0:  0000000010057f9c <runtime.sigpanic+1068>  0000000000000001 
000000c0005960d0:  0000000010057f80 <runtime.sigpanic+1040>  0000000010057f84 <runtime.sigpanic+1044> 
000000c0005960e0:  000000c0005960e8  000000001006df80 <runtime.throw.func1+0> 
000000c0005960f0:  00000000121b0080  0000000000000005 
000000c000596100: <00003fffb7da84fc  0000000012671a80 
000000c000596110:  0000000011ef39a0  000000001226d068 
000000c000596120:  00000000121b0080  0000000000000005 
000000c000596130:  0000000010467ba4 <encoding/json.typeFields+6132>  000000000000fe1e 
000000c000596140: >00003fffb7db2c54  0000000000000000 
000000c000596150:  0000000010467cfc <encoding/json.cachedTypeFields+220>  000000001056a264 <text/template/parse.(*Tree).operand+52> 
000000c000596160:  000000c0005967d0  0000000011ef9c40 
000000c000596170:  000000c0001df558  0000000011ef39a0 
000000c000596180:  000000001226d068  0000000000000002 
000000c000596190:  0000000000000002  0000000012671a80 
000000c0005961a0:  0000000011ef39a0  000000c000378280 
000000c0005961b0:  000000000000000a  0000000000000018 
000000c0005961c0:  0000000000000028  000000c000378208 
000000c0005961d0:  0000000000000001  0000000000000001 
000000c0005961e0:  0000000000000000  0000000010166c00 <regexp/syntax.(*compiler).compile+6640> 
000000c0005961f0:  0000000010165730 <regexp/syntax.(*compiler).compile+1312>  0000000012671a80 
000000c000596200:  0000000000000025  0000000000000043 
000000c000596210:  0000000000000009  0000000000000002 
000000c000596220:  0000000000000001  0000000000000003 
000000c000596230:  0000000000000007  0000000000000002 
runtime.sigpanic()
	/home/boger/golang/go1.12/go/src/runtime/signal_unix.go:397 +0x42c fp=0xc000596140 sp=0xc000596100 pc=0x10057f9c

goroutine 19 [chan receive]:
github.com/openshift/origin/vendor/k8s.io/klog.(*loggingT).flushDaemon(0x13d2bb60)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/k8s.io/klog/klog.go:1018 +0x90
created by github.com/openshift/origin/vendor/k8s.io/klog.init.0
	/home/boger/gocode/src/github.com/openshift/origin/vendor/k8s.io/klog/klog.go:404 +0x84

goroutine 93 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000150920)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8

goroutine 128 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000288fa0)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8

goroutine 126 [chan receive]:
github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.(*MergeLogger).outputLoop(0xc000288e20)
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:174 +0x39c
created by github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil.NewMergeLogger
	/home/boger/gocode/src/github.com/openshift/origin/vendor/github.com/coreos/etcd/pkg/logutil/merge_logger.go:92 +0xf8
FAIL	github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/registry/core/node/storage	0.106s

I have a fix for this. After debugging I found that the problem is in runtime/type.go function textOff where it looks up the text offset from an offset. If the 'off' happens to be the last value in the text section, the wrong value is returned.

created time in 4 months

issue commentgolang/go

os/signal: TestAtomicStop failing on Illumos

FWIW, we see this failure intermittently on gccgo for both ppc64le & ppc64. The limit was put at 2s to hopefully fix that problem but it still happens. We don't see the error in golang.

bradfitz

comment created time in 4 months

issue commentgolang/go

cmd/dist: "unexpected stale targets" during toolchain3 bootstrapping on darwin builders

I see the same type of failure with the stale targets when I try to force -pie to be the default build mode for ppc64le (due to a request). It is noted in https://github.com/golang/go/issues/28531. Maybe something wrong with the way that internal/cpu is hashed so that it doesn't get consistent results?

bcmills

comment created time in 4 months

issue commentgolang/go

cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le

After I do a normal build, I can do this to make these binaries built as pie:

go install -buildmode=pie cmd/go go install -buildmode=pie cmd/trace go install -buildmode=pie cmd/pprof

Does this help?

laboger

comment created time in 4 months

issue commentgolang/go

cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le

@laboger I don't know why setting GOFLAGS didn't work when building the toolchain. Does it work when using the toolchain? That is, does GOFLAGS=-buildmode=pie go build hello.go build a PIE?

Yes, if I use -x I can see it uses -buildmode=pie on the final link of the executable for hello.

laboger

comment created time in 4 months

issue commentgolang/go

cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le

I'm very sorry. I didn't notice that an earlier comment was made regarding this topic related to SUSE. @ianlancetaylor I tried a build setting GOFLAGS=-buildmode=pie, and the build finished but that didn't seem to build all the toolchain binaries as PIE.

If I change the default in init.go, I still get the errors that some files are stale.

I cannot reproduce the problem identified earlier on SUSE using go 1.10.5. Were there any env variables used during the build? What distro was it.

laboger

comment created time in 4 months

issue commentgolang/go

cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le

If you have an example of a failure when using -buildmode=pie on ppc64le please provide it. I'm not sure what libraries you are referring to, my understanding is that if it is Go code built using -buildmode=pie it will be built as position independent, and C or C++ code built for ppc64le should be position independent by default.

On Thu, Oct 17, 2019 at 11:07 AM Michal Suchánek notifications@github.com wrote:

So now you have to add 'me too' to bugs? It his some web 2.0 thing?

Anyway, the code is just broken.

How do you suppose the code is position independent if the libraries included in the interpreter are not?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/28531?email_source=notifications&email_token=ACH7BDCEUEUQKTT56QRZISTQPCEV5A5CNFSM4GA2TLN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQULNY#issuecomment-543245751, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH7BDGW7BMX7JJBJW54FBDQPCEV5ANCNFSM4GA2TLNQ .

laboger

comment created time in 4 months

issue commentgolang/go

cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le

I believe the title is is misleading. -buildmode=pie works fine for most things on ppc64le. The problem happens when trying to build a toolchain that will generate all binaries as pie by default, including those that are part of the toolchain. This came about because of a request from a single user.

No one has asked about this again, so if we want to close it that is fine with me.

I retried the same experiment as I did back in November and got the same result.

laboger

comment created time in 4 months

issue commentgolang/go

cmd/compile: intrinsify math/bits.RotateLeft{32,64} on all architectures

CL 163760 handles both ppc64le and ppc64. When ppc64x is specified, that means both.

On Thu, Oct 17, 2019 at 9:07 AM cherrymui notifications@github.com wrote:

CL 163760 should cover both ppc64 and ppc64le, right?

On MIPS, the rotate instruction is rather new. We still support older machines. I guess we could do something based on GOMIPS(64) value, but we need to introduce the values first. Two shifts + an OR doesn't sounds too bad.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/31265?email_source=notifications&email_token=ACH7BDATPMDS3OGUPJ25KW3QPBWS3A5CNFSM4HDWR4J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQGSYY#issuecomment-543189347, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH7BDCQYEPWOO4KKTS3ZF3QPBWS3ANCNFSM4HDWR4JQ .

mundaym

comment created time in 4 months

issue commentgolang/go

runtime: infinite loop in lockextra on linux/arm

@randall77 I see you reopened #22047. We have seen similar hangs recently and I suspect it could be related to the issue with signals described here. I was unable to add any comments to issue #22047 because it was locked. I have been able to reproduce some hangs on my systems by using GOMAXPROCS=2 like is done with builder testing, and in those cases I see the stack that I provided above in the signal handling code. (Maybe there should be a different issue for the ppc64{le} hangs? I don't like to put comments in multiple issues but in this case the headline is misleading.)

nyuichi

comment created time in 4 months

issue commentgolang/go

proposal: remove linux/ppc64 (big endian) port

If the point of keeping linux/ppc64 was to root out endianness assumptions, doesn't linux/s390x get that for us? The s390x folk are doing an amazing job maintaining that port.

There's also aix/ppc64 which uses ppc64 big endian. Since that was just added, I'm assuming it will be around for a while. So we will have that to root out the endianness problems in ppc64 codegen.

Using an older distro on linux/ppc64 and one as new as possible on linux/ppc64le sounds fine to me. As @ianlancetaylor mentioned, when ppc64 went to power8 minimum we had complaints so there were users out there who wanted to keep using ppc64. I haven't heard much lately though.

bradfitz

comment created time in 5 months

issue commentgolang/go

runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet

I have not been able to reproduce this one with GOMAXPROCS=2. It would help to know what is on the stack that is unavailable, is there any way to get that information?

bcmills

comment created time in 5 months

issue commentgolang/go

runtime: 'failed to trigger concurrent GC' in TestSelectStackAdjust

There's a discussion in #34391 that might be related to this failure. Some intermittent failures on ppc64 and ppc64le appear to be happening due to a problem with signals, and also affects linux/arm.

bcmills

comment created time in 5 months

issue commentgolang/go

net/http: TestClientTimeoutCancel flake on linux-ppc64le-power9osu builder

@ceseo I think you need to try and reproduce using GOMAXPROCS=2 since that is the number of processors on the build systems.

bcmills

comment created time in 5 months

issue commentgolang/go

cmd/link: linker should fail quickly when external link mode is not supported

External linking is supported on ppc64le, but not on ppc64. If we try to link externally we see this:

go build -ldflags '-linkmode=external' hello.go

command-line-arguments

/home/boger/golang/base/go/pkg/tool/linux_ppc64/link: external linking not supported for linux/ppc64

jeremyfaller

comment created time in 5 months

issue commentgolang/go

cmd/compile: program that requires zerorange of >=32 bytes fails to compile on aix/ppc64

We do not have rules in PPC64.rules to generate DUFFCOPY or DUFFZERO for ppc64 or ppc64le because it is too inefficient. That is why you've never hit this before.

On Mon, Sep 30, 2019 at 3:52 AM Clément Chigot notifications@github.com wrote:

I've somehow missed the part with ADUFFZERO when I've adapted rewriteToUseGot into rewriteToUseTOC. I'll send a CL in order to fix it. Note that it only appears now (almost a year after the implementation) that the ADUFFZERO instruction wasn't correctly handled. It seems that there is no tests at all, generating at least one ADUFFZERO. Is this the case or they are somehow disabled on aix/ppc64 ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/34604?email_source=notifications&email_token=ACH7BDHSLSYOJBL72U5AU5LQMG46NA5CNFSM4I3U5QP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD745KIQ#issuecomment-536466722, or mute the thread https://github.com/notifications/unsubscribe-auth/ACH7BDGJ3WKRDUOKIUIIMP3QMG46NANCNFSM4I3U5QPQ .

danscales

comment created time in 5 months

issue commentgolang/go

runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet

I was not aware the builder machines only had 2 processors each. I will try and see if that helps to reproduce the problem (ours have at least 16, some many more).

So that means the default value for the test parallelism should be 2, but I've seen failure logs where there are many more than 2 goroutine stacks running tests. I guess that should be OK but I did not expect that.

bcmills

comment created time in 5 months

issue commentgolang/go

runtime: apparent test deadlock on ppc64le

Recently we seem to have had a lot of hangs like this where one of the goroutines is in an IO wait while trying to do a read. Just wondering if some kind of file system issue might cause that?

bcmills

comment created time in 5 months

issue openedgolang/go

build: hang in ppc64 buildlet not handled

The ppc64 builders were seeing hangs freqently and while investigating I noticed this on farmer.golang.org:

go-be-1 (140.211.168.40:49707) version 23, host-linux-ppc64-osu: connected 113h15m55.9s, working for 113h11m26.9s

This particular hang was resolved by @bcmills I was asked to open an issue on the fact that this was not handled by the build system.

I believe the problem with hangs during the buildlets has been resolved by CL 196658.

created time in 5 months

issue commentgolang/go

runtime: infinite loop in lockextra on linux/arm

I just hit a compile time hang when doing a golang build on one of our power8 ppc64le machines. Here is what the trace looks like:

(gdb) bt
#0  0x000000000006b5d0 in runtime.usleep () at /home/boger/golang/fresh/go/src/runtime/sys_linux_ppc64x.s:117
#1  0x00000000000432b0 in runtime.lockextra (~r1=<optimized out>, nilokay=false) at /home/boger/golang/fresh/go/src/runtime/proc.go:1794
#2  0x0000000000042c80 in runtime.needm (x=<optimized out>) at /home/boger/golang/fresh/go/src/runtime/proc.go:1595
#3  0x0000000000054500 in runtime.badsignal (sig=17, c=0xc000008ee0) at /home/boger/golang/fresh/go/src/runtime/signal_unix.go:610
#4  0x0000000000053cbc in runtime.sigtrampgo (sig=<optimized out>, info=0xc000009d78, ctx=0xc000009000)
    at /home/boger/golang/fresh/go/src/runtime/signal_unix.go:315
#5  0x000000000006b8ec in runtime.sigtramp () at /home/boger/golang/fresh/go/src/runtime/sys_linux_ppc64x.s:317
#6  <signal handler called>
#7  __do_get_tspec () at /build/linux-B4VGWU/linux-4.15.0/arch/powerpc/kernel/vdso64/gettimeofday.S:208
#8  0x00007b3791c2057c in __kernel_clock_gettime () at /build/linux-B4VGWU/linux-4.15.0/arch/powerpc/kernel/vdso64/gettimeofday.S:75
PC not saved

This must be the reason for all the 20 minute hangs we have been seeing since the original sigFetchG change went in. I think sig 17 is SIGCHLD which seems like a signal that should be ignored.

nyuichi

comment created time in 5 months

issue commentgolang/go

runtime: infinite loop in lockextra on linux/arm

When TestStress in os/signal hangs on ppc64, I can attach with gdb and see this stack:

#0  0x000000000006dde0 in runtime.usleep () at /home/boger/golang/test/go/src/runtime/sys_linux_ppc64x.s:117
#1  0x0000000000042cb0 in runtime.lockextra (~r1=<optimized out>, nilokay=false) at /home/boger/golang/test/go/src/runtime/proc.go:1794
#2  0x0000000000042680 in runtime.needm (x=<optimized out>) at /home/boger/golang/test/go/src/runtime/proc.go:1595
#3  0x0000000000054550 in runtime.badsignal (sig=10, c=0xc000008ee0) at /home/boger/golang/test/go/src/runtime/signal_unix.go:611
#4  0x0000000000053bcc in runtime.sigtrampgo (sig=<optimized out>, info=0xc000009d78, ctx=0xc000009000)
    at /home/boger/golang/test/go/src/runtime/signal_unix.go:316
#5  0x000000000006e11c in sigtramp () at /home/boger/golang/test/go/src/runtime/sys_linux_ppc64x.s:317
#6  <signal handler called>
#7  __kernel_clock_gettime () at arch/powerpc/kernel/vdso64/gettimeofday.S:95
#8  0x000000000006dfc8 in runtime.nanotime1 () at /home/boger/golang/test/go/src/runtime/sys_linux_ppc64x.s:233
#9  0x0000000001d304bb in ?? ()

It didn't go down this path before because I don't think 'g' could be nil.

nyuichi

comment created time in 5 months

issue commentgolang/go

runtime: infinite loop in lockextra on linux/arm

The commit mentioned above is incorrect for ppc64/ppc64le. R30 is used for G in Go and will never be clobbered by the vdso code since R30 is considered nonvolatile in the non-Go world. Removing ppc64, ppc64le from the case in sigFetchG resolves the issues I was seeing.

nyuichi

comment created time in 5 months

issue commentgolang/go

runtime: infinite loop in lockextra on linux/arm

We have been seeing some strange failures on the linux/ppc64 builder. The problems are not consistently reproducible but I was able to find that the test TestStress in os/signal hangs consistently on my ppc64 system. It does not always hang when running all.bash but does consistently hang if I run that test by itself. I am still trying to see if I can make the same thing happen on ppc64le.

This starts to happen with commit 904f046 which was the fix for the issue mentioned above #34030. I'm guessing it is the same problem identified in this issue but if not I can open a new issue. There are many failures on the ppc64 build dashboard since this commit mostly appearing as 20m timeouts. In one case I was able to make it happen just like the builder log and found that it was hung during a compile. If you look through the ppc64 failures the hang is not always on the same test but usually a 20m timeout.

nyuichi

comment created time in 5 months

issue openedgolang/go

proposal: add gnu assembler output as comments alongside Go assembler in Go objdump output

I have had a patch to do this for quite a while on ppc64 which I've provided to internal and external developers who want to write Go assembler to optimize their code. I tried to sneak it in a while back for ppc64 but Cherry suggested I make it a proposal.

The initial goal was to make it easier for Go developers who write Go assembler to verify they are getting the native assembler they expect. Many are experts in their native assembler but not in Go assembler. With this change, the Go objdump will show both side by side. This is also helpful for any code compiled with Golang. The gnu objdump can be used to disassemble Go binaries but not all objects created by Go are accepted.

This could be controlled by option but that is probably too much bother, unless there are concerns about doing this all the time.

It can be added easily for ppc64 and others assuming GNUSyntax works well. I tried it for x86 but since I'm not fluent there I can't verify if the output looks like it should.

Here is an example of the output:

TEXT main.main(SB) /home/boger/gotests/hello.go
func main() {
  0x98e50               e87e0010                MOVD 16(R30),R3                      // ld r3,16(r30)
  0x98e54               7c230840                CMPU R3,R1                           // cmpld r3,r1
  0x98e58               41800010                BLT 0x98e68                          // blt 0x98e68
  0x98e5c               7ca802a6                MOVD LR,R5                           // mflr r5
  0x98e60               4bfc8d81                CALL runtime.morestack_noctxt(SB)    // bl 0x61be0
  0x98e64               4bffffec                BR main.main(SB)                     // b 0x98e50
  0x98e68               7fe802a6                MOVD LR,R31                          // mflr r31
  0x98e6c               fbe1ff91                MOVDU R31,-112(R1)                   // stdu r31,-112(r1)
    fmt.Printf("Hello\n")
  0x98e70               3fe00017                ADDIS $0,$23,R31                     // lis r31,23
  0x98e74               e87f4018                MOVD 16408(R31),R3                   // ld r3,16408(r31)
        return Fprintf(os.Stdout, format, a...)
  0x98e78               3fe0000f                ADDIS $0,$15,R31                     // lis r31,15
  0x98e7c               389fd580                ADD R31,$-10880,R4                   // addi r4,r31,-10880
  0x98e80               f8810020                MOVD R4,32(R1)                       // std r4,32(r1)
  0x98e84               f8610028                MOVD R3,40(R1)                       // std r3,40(r1)
  0x98e88               3fe0000d                ADDIS $0,$13,R31                     // lis r31,13
  0x98e8c               387f2e5a                ADD R31,$11866,R3                    // addi r3,r31,11866
  0x98e90               f8610030                MOVD R3,48(R1)                       // std r3,48(r1)
  0x98e94               38600006                MOVD $6,R3                           // li r3,6
  0x98e98               f8610038                MOVD R3,56(R1)                       // std r3,56(r1)
  0x98e9c               f8010040                MOVD R0,64(R1)                       // std r0,64(r1)
  0x98ea0               f8010048                MOVD R0,72(R1)                       // std r0,72(r1)
  0x98ea4               f8010050                MOVD R0,80(R1)                       // std r0,80(r1)
  0x98ea8               4bff8849                CALL fmt.Fprintf(SB)                 // bl 0x916f0
  0x98eac               ebe10000                MOVD 0(R1),R31                       // ld r31,0(r1)
  0x98eb0               7fe803a6                MOVD R31,LR                          // mtlr r31
  0x98eb4               38210070                ADD R1,$112,R1                       // addi r1,r1,112
  0x98eb8               4e800020                RET                                  // bclr 20,lt,0

created time in 5 months

issue commentgolang/go

runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet

I don't think the distro is at fault here anymore. I found that these are using Debian 8 based on some comments I found. My concern was if it was Debian 7.

Can we bump up the timeout value for ppc64 to 10m or so just to rule out a deadlock vs. something making it take a long time?

bcmills

comment created time in 5 months

issue commentgolang/go

runtime: TestGdbPython flaky on linux

The failure here happens because at the time the gdb script tries to display information about goroutine 2, that goroutine no longer exists.

Is that a bug because the goroutine has ended, or just normal behavior? Someone who knows more about what causes goroutines to come and go would have to answer that.

It seems like the testcase should have a goroutine that won't go away soon and reference that in the gdb script.

bradfitz

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

Here is the merge commit that includes the fixes:

Merge: 3483534 b1e8156
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Sep 3 17:20:39 2019 +0100
    Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20190829' into staging
    
    ppc patch queue 2018-08-29
    
    Another pull request for ppc-for-4.2.  Includes
    
      * Several powernv patches which were pulled last minute from the
        last PULL, now that some problems with them have been sorted out
      * A fix for -no-reboot which has been broken since the
        pseries-rhel4.1.0 machine type
      * Add some host threads information which AIX guests will need to
        properly scale the PURR and SPURR
      * Change behaviour to match x86 when unplugging function 0 of a
        multifunction PCI device
      * A number of TCG fixes in FPU emulation
    
    And a handful of other assorted fixes and cleanups.
SuperQ

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

I've received information that there were some recent fixes to QEMU for ppc64le related to float conversions that will be in QEMU 4.2. The person who gave me this information was able to do a build of node_exporter successfully using QEMU built from upstream.

SuperQ

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

Yes, I know now but based on what was written earlier I didn't think it was known to be QEMU only for sure.

Is this a new failure in Go 1.12?

SuperQ

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

I am not using QEMU. I only tried it on ppc64le hardware.

SuperQ

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

node_exporter built successfully on all variations I tried: Debian 9 power8 and SLES power9. On the power8 I compiled using go from Go 1.13 and upstream.

This must have built successfully in Go 1.12?

SuperQ

comment created time in 6 months

issue commentgolang/go

cmd/compile: "truncation is not exact" ICE while compiling on ppc64le on QEMU

If you had a short reproducer program or better directions on how to get to the failure I could try it on ppc64le.

SuperQ

comment created time in 6 months

more