[Bug go/83794] misc/cgo/test uses gigabytes of memory

2018-01-12 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Looks all fine now.

[Bug go/83794] misc/cgo/test uses gigabytes of memory

2018-01-11 Thread ian at airs dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Ian Lance Taylor  ---
Thanks for investigating.  I fixed the problem you found in TestBuildID.  The
logs generated by t.Logf are saved until the test is complete, because tests
can run in parallel and interleaved logs are hard to read.  So 1) that explains
why you didn't see any of the logs; 2) it explains why the program allocated
memory very quickly and without bound.

Let me know if you still see a problem with `make check-gotools` after that
patch.  I don't know if there is anything else going on.

[Bug go/83794] misc/cgo/test uses gigabytes of memory

2018-01-11 Thread ian at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Jan 11 19:58:55 2018
New Revision: 256553

URL: https://gcc.gnu.org/viewcvs?rev=256553=gcc=rev
Log:
PR go/83794
misc/cgo/test: avoid endless loop when we can't parse notes

Reviewed-on: https://go-review.googlesource.com/87416

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/misc/cgo/test/buildid_linux.go

[Bug go/83794] misc/cgo/test uses gigabytes of memory

2018-01-11 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
There's other similar fails, like

*** Test killed with Quit: ran too long (10m0s).
exit status 2
FAILcmd/go  600.478s
--- FAIL: go test cmd/go (0.00s)

10 minutes looks excessive to me as well.  Eventually because the machine was
swapping like hell.

For the original issue there's an awful lot of threads (when attaching with
gdb).
One thread is in

#0  sync.Get.pN9_sync.Pool (p=p@entry=0x7ff62c4e63d0 )
at /space/rguenther/src/svn/trunk/libgo/go/sync/pool.go:130
#1  0x7ff62b68e818 in fmt.newPrinter ()
at /space/rguenther/src/svn/trunk/libgo/go/fmt/print.go:133
#2  0x7ff62b696c5e in fmt.Sprintf (format=..., a=...)
at /space/rguenther/src/svn/trunk/libgo/go/fmt/print.go:202
#3  0x7ff62ba0baaa in testing.Logf.pN14_testing.common (c=, 
format=..., args=...)
at /space/rguenther/src/svn/trunk/libgo/go/testing/testing.go:571
#4  0x7ff62ba0baf9 in testing.Logf$stub.pN9_testing.T (
$this20=, $p21=..., $p22=...)
at /space/rguenther/src/svn/trunk/libgo/go/testing/testing.go:476
#5  0x004d6d11 in cgotest.testBuildID (t=)
at
/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test/buildid_linux.go:61
#6  0x004d6fd4 in
__abuild_rguenther_obj_gotools_cgo_test_dir_misc_cgo_test.TestBuildID
(t=)
at
/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test/cgo_linux_test.go:11

thus logging diagnostics somewhere, eventually gobbling up memory.

I suspect that

namesz := f.ByteOrder.Uint32(d)
descsz := f.ByteOrder.Uint32(d[4:])
typ := f.ByteOrder.Uint32(d[8:])

an := (namesz + 3) &^ 3
ad := (descsz + 3) &^ 3

if int(12+an+ad) > len(d) {
t.Logf("note section %d too short for header
(%d < 12 + align(%d,4) + align(%d,4))", i, len(d), namesz, descsz)
continue
}

is somehow "broken".  Doesn't seem to log to disk anywhere btw?

Ah, and of course after 'continue' this just continues with 'd' unchanged and
thus endlessly loops and logs.  Similar for the earlier error.  I suspect
it wants to continue the outer loop instead?  Or maybe for len (d) > 0 isn't
a loop...

As said, please fix!

[Bug go/83794] misc/cgo/test uses gigabytes of memory

2018-01-11 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794

--- Comment #1 from Richard Biener  ---
Looks like no useful logs are there btw, I killed the process and all I got (in
gotools/cgo-testlog!?) is

cd cgo-test-dir/misc/cgo/test &&
PATH=/abuild/rguenther/obj/gotools:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
GCCGO='/abuild/rguenther/obj/gotools/check-gccgo'
CC='/abuild/rguenther/obj/gotools/check-gcc'
GCCGOTOOLDIR='/abuild/rguenther/obj/gotools' GO_TESTING_GOTOOLS=yes
LD_LIBRARY_PATH=/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgo/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libsanitizer/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libmpx/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libvtv/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libssp/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgomp/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libitm/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libatomic/.libs:/abuild/rguenther/obj/./gcc:/abuild/rguenther/obj/./prev-gcc
GOROOT=/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgo GOTRACEBACK=2
/abuild/rguenther/obj/gotools/go test -test.short -test.v
=== RUN   TestSetgid
--- PASS: TestSetgid (0.00s)
=== RUN   Test6997
--- PASS: Test6997 (0.50s)
=== RUN   TestBuildID
signal: Terminated
FAIL_/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test  
293.646s
--- FAIL: go test misc/cgo/test (0.00s)

so draw conclusions from that.  The cgo/test/buildid_linux.go test somewhat
matches?