I have to add that I experienced no such issue while building go 1.6.2 or 1.7beta1.

Which os and kernel are you using ? Does you kernel lean towards the more
paranoid end of the configuration spectrum?

On Tue, Aug 16, 2016 at 8:46 PM, Jean-Christophe Manciot <
notifications@github.com> wrote:

I have to add that I experienced no such issue while building go 1.6.2 or
1.7beta1.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16731 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA5ID5h89sTETrfRAFOYDetU-VLsDks5qgZUBgaJpZM4JlQeN
.

Ubuntu server 16.04 4.4.0-34. default settings.

Do you perhaps have a ulimit set? (Add a "ulimit -a" into the script just before calling all.bash to print the current values)

No

This doesn't look like a bug in Go per se. It looks like a limitation of your kernel. It gets to about 3000 mappings and then dies creating another one.

That said, I'm not sure what this test is intended to test, exactly. It seems like an awful lot of resources for a test. Maybe it is just trying to simulate large Go heaps?

@remyoudompheng

OK.
How about limiting the test(s) to the maximum current values configured on the local host through a call to "ulimit -a"?
For instance, on mine:

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63547
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63547
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Almost exactly the same issue with commit 1.7.1 (slightly different RAM address):

ok      regexp/syntax   0.411s
--- FAIL: TestMemmoveOverflow (0.00s)
    memmove_linux_amd64_test.go:43: could not map a page at requested 0xa00bde0000: cannot allocate memory
FAIL
FAIL    runtime 18.605s

The test was added by @remyoudompheng for #4981, "runtime: fix integer overflow in amd64 memmove" (fix+test: 1b8f51c)

In the meantime, is it possible to remove the test to let the build complete and what would be the alleged consequences?

Yeah, we could skip it in short mode. Or only run it in short mode on the builders (build.golang.org machines).

No consequences for disabling it.

And how do you enable "short mode" for the build? I don't see anything about that in the doc.

https://godoc.org/testing#Short

See the example at the top of the page for how to use it.

On Sat, Sep 10, 2016 at 4:22 PM, Jean-Christophe Manciot <
notifications@github.com> wrote:

And how do you enable "short mode" for the build? I don't see anything
about that in the doc https://golang.org/doc/install/source#environment.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16731 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAxoy8nivQypJgtuVou__gOStSSeKks5qokyWgaJpZM4JlQeN
.

You seem to misunderstand my request: I call the build with a simple script which automates everything including the tests:

        export GOROOT_BOOTSTRAP=/usr/lib/go1.4.3
        cd src
        ./all.bash

There should be an option that we can pass to "all.bash", such as --skip-tests, or --skip-test=, or an environment variable that can be set the same way in order to specify which test we can skip.

If you don't want to run the tests, you can use ./make.bash

On 10 Sep 2016, at 20:24, Jean-Christophe Manciot notifications@github.com wrote:

You seem to misunderstand my request: I call the build with a simple script which automates everything including the tests:

    export GOROOT_BOOTSTRAP=/usr/lib/go1.4.3
    cd src
    ./all.bash

There should be an option that we can pass to "all.bash", such as --skip-tests, or --skip-test=, or an environment variable that can be set the same way in order to specify which test we can skip.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I meant we could do something like https://go-review.googlesource.com/#/c/28782/1/src/net/http/transport_test.go which makes that test skipped for most users casually running ./all.bash (which runs tests in short mode), but keeps running it on our builders:

func TestTransportEventTraceRealDNS(t *testing.T) {
    if testing.Short() && testenv.Builder() == "" {
        // Skip this test in short mode (the default for
        // all.bash), in case the user is using a shady/ISP
        // DNS server hijacking queries.
        // See issues 16732, 16716.
        // Our builders use 8.8.8.8, though, which correctly
        // returns NXDOMAIN, so still run this test there.
        t.Skip("skipping in short mode")
    }

I'm finally able to build 1.7.1 with ./make.bash; I'd like to run the tests when they are all operational for Ubuntu.

CL https://golang.org/cl/32104 mentions this issue.