Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: TestMemmoveOverflow: memmove_linux_amd64_test.go:43: could not map a page at requested 0xa00be00000: cannot allocate memory #16731

Closed
jean-christophe-manciot opened this issue Aug 16, 2016 · 18 comments

Comments

Projects
None yet
6 participants
@jean-christophe-manciot
Copy link

commented Aug 16, 2016

  1. What version of Go are you using (go version)?
    Building 1.7 with 1.4.3
  2. What operating system and processor architecture are you using (go env)?
    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOOS="linux"
    GOPATH="/home/actionmystique/Program-Files/Ubuntu/GO-Packages"
    GORACE=""
    GOROOT="/usr/lib/go"
    GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
    CC="gcc"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build592966653=/tmp/go-build -gno-record-gcc-switches"
    CXX="g++"
    CGO_ENABLED="1"
  3. What did you do?
    With $release_number=1.7:
        echo --------
        echo Cleaning
        echo --------
        cd /usr/lib/go
        git reset --hard
        git clean -fxd :/
        git checkout release-branch.go1.7
        git pull -v --progress --rebase
        git checkout go${release_number}

        echo -------------------------------------------------------
        echo Installing ${release_number} using pre-downloaded 1.4.3
        echo -------------------------------------------------------
        export GOROOT_BOOTSTRAP=/usr/lib/go1.4.3
        cd src
        ./all.bash
  1. What did you expect to see?
    Correct compilation
  2. What did you see instead?
...
##### Testing packages.
...
ok      regexp/syntax   0.475s
--- FAIL: TestMemmoveOverflow (0.00s)
    memmove_linux_amd64_test.go:43: could not map a page at requested 0xa00be00000: cannot allocate memory
FAIL
FAIL    runtime 16.262s
ok      runtime/debug   0.008s
...
@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Aug 16, 2016

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

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2016

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
.

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Aug 16, 2016

Ubuntu server 16.04 4.4.0-34. default settings.

@josharian josharian changed the title TestMemmoveOverflow: memmove_linux_amd64_test.go:43: could not map a page at requested 0xa00be00000: cannot allocate memory runtime: TestMemmoveOverflow: memmove_linux_amd64_test.go:43: could not map a page at requested 0xa00be00000: cannot allocate memory Aug 16, 2016

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2016

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

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Aug 26, 2016

No

@randall77

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2016

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

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Aug 26, 2016

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
@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Sep 8, 2016

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
@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 8, 2016

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

@bradfitz bradfitz added this to the Go1.8 milestone Sep 8, 2016

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Sep 9, 2016

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 9, 2016

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.

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Sep 10, 2016

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

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2016

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
.

@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Sep 10, 2016

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.

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2016

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.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 10, 2016

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")
    }
@jean-christophe-manciot

This comment has been minimized.

Copy link
Author

commented Sep 10, 2016

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.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 27, 2016

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

@gopherbot gopherbot closed this in 54f691d Oct 28, 2016

@golang golang locked and limited conversation to collaborators Oct 28, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.