SIGSEGV: segmentation violation on compose run

[tkhduracell]

Summary

Trying to run a simple task causes crash without error message.

Description

• ecs-cli version 1.7.0 (*UNKNOWN)
• aws-cli/1.16.20 Python/3.7.0 Darwin/16.7.0 botocore/1.12.10

Config files

• docker-compose.yml

version: '3'
services:
  app:
    build: .
    environment:
      - MY_GCP_PRIVATE_KEY
      - PROJECT_CONFIGURATION_LOCATION
      - PROJECT_ID
    env_file: .env
    ports:
      - "4200:4200"

docker-compose.yml exists
.env exists

• ecs-params.yml
  (none)

• ~/.ecs/config
  (none)

Expected Behavior

ecs-cli compose run app "bash -c ping -n 4 8.8.8.8" to run app or fail with a error message.

Observed Behavior

WARN[0000] Skipping unsupported YAML option for service...  option name=build service name=app
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x168ee67]

goroutine 1 [running]:
github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project.convertToContainerConfig(0xc4202a6470, 0x3, 0xc4202a6480, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project/project_parseV3.go:136 +0x5b7
github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project.(*ecsProject).parseV3(0xc4202aed40, 0x1, 0x1b3cc98, 0x1)
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project/project_parseV3.go:39 +0x217
github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project.(*ecsProject).parseCompose(0xc4202aed40, 0x0, 0x0)
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project/project.go:148 +0x247
github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project.(*ecsProject).Parse(0xc4202aed40, 0x1c60b40, 0xc4202cc2a0)
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/project/project.go:118 +0x7e
github.com/aws/amazon-ecs-cli/ecs-cli/modules/cli/compose/factory.projectFactory.loadProject(0x1c600a0, 0xc4202aed40, 0xc4202aed40, 0x0)
	...
    /private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/vendor/github.com/urfave/cli/command.go:93 +0x1301
github.com/aws/amazon-ecs-cli/ecs-cli/vendor/github.com/urfave/cli.(*App).Run(0xc42016f380, 0xc4200a60f0, 0x5, 0x5, 0x0, 0x0)
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/vendor/github.com/urfave/cli/app.go:250 +0x700
main.main()
	/private/tmp/amazon-ecs-cli-20180719-16899-jb6c0b/amazon-ecs-cli-1.7.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/main.go:68 +0x79c

[allisaurus]

Hi @tkhduracell - thank you for reporting this. Would you mind adding the (sanitized) content of your .env file so we can see the full picture re: what env vars are being passed in? Thanks!

[tkhduracell]

I think the .env content was:

MY_GCP_PRIVATE_KEY=foobar
PROJECT_CONFIGURATION_LOCATION=foobar
PROJECT_ID=foobar

But since you have "fixed" the bug, maybe this file was located somewhere else. I'll try to update and reopen if I encounter this again. Thanks!

[allisaurus]

@tkhduracell Thanks for providing! Yes, we were able to reproduce the error with the provided environment, but knowing the whole story re: env vars just helps us test and ensure we've actually solved the problem :)

[allisaurus]

This fix was released with 1.9.0. Resolving.