Golang CircleCI 2.0测试失败，并发出信号：已终止

Question

I am migrating to circleci2.0 and after successful build when tests are executed they are randomly failing with following error messages

/usr/local/go/pkg/tool/linux_amd64/link: signal: killed
/usr/local/go/pkg/tool/linux_amd64/link: flushing $WORK/b462/payment_step_svc.test: write $WORK/b462/svc.test: cannot allocate memory

I used the following config

jobs:
  build:
    docker:
      - image: circleci/golang:latest
      - image: rabbitmq:3.5.4
      - image: redis

    working_directory: /go/src/github.com/soniabhishek/taskrunner

    environment:
      GOOS: linux
      GOARCH: amd64
      GOPATH: /go

    steps:
      - checkout
      - run:
          name: Get dependencies
          command: go get -t -d -v ./...
      - run:
          name: Build all
          command: go build ./...
      - run:
          name: Test all
          command: go test -v ./...

I have tried for many golang versions other than latest like (1.10.3).

Although I found the hack for this but I am not sure why is this happening, all my tests run when I use CGO_ENABLED=0

Would like to know why is this issue occurring and permanent solution for this

Answer 1

There are two clues here that suggest you are consuming too much memory, and the OS is forcibly killing your "rogue" process. They are:

killed

cannot allocate memory

You can confirm this by getting an SSH session at the end of a failed build, and examining the kill history using dmesg. If it gives you a "sacrifice child" message, then you hit a memory limit so severe that the OS was forced to remove a process from memory.

You have several options. I put them here in the order I would suggest you prefer them:

• Reduce your memory consumption by making changes to your Go program
• Ask CircleCI to set you up with a larger Docker container (this will be a chargeable option). The default is 4G, I believe 8G and 16G are available
• Swap to a Machine executor (presently free of charge, subject to change). This gives you 8G of RAM, but you lose some of the flexibility of the Docker approach (e.g. you have to use one of a few preset base images).