gauge: invalid memory address or nil pointer when running with --tags

Expected behavior

Should be able to run specs with tags

Actual behavior

Cannot run specs with --tags argument

Steps to reproduce

1.On an OSX 10.13 machine try gauge run --tags TT-Group1 specs/ we also tried gauge run --tags=TT-Group1 specs/ and "gauge run --tags=“TT-Group1” specs/ 2. If the command is “gauge run specs/somespec.spec” it works fine

Error ---------------------------------- Panicing : runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: runtime/debug.Stack(0xc0005ab6c0, 0x166e760, 0x1cabc40) /usr/local/opt/go/libexec/src/runtime/debug/stack.go:24 +0xa7 main.recoverPanic() src/github.com/getgauge/gauge/gauge.go:36 +0x57 panic(0x166e760, 0x1cabc40) /usr/local/opt/go/libexec/src/runtime/panic.go:513 +0x1b9 github.com/getgauge/gauge/filter.filterSpecsByTags(0xc000486800, 0x8b7, 0x8b7, 0x7ffeefbffab9, 0x9, 0xc0004a8000, 0x1, 0x1e89000) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/filter/specItemFilter.go:214 +0xcd github.com/getgauge/gauge/filter.(*tagsFilter).filter(0xc00fb2ea10, 0xc000486800, 0x8b7, 0x8b7, 0x100dc78, 0x20, 0x1687fe0) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/filter/specsFilter.go:45 +0xa3 github.com/getgauge/gauge/filter.applyFilters(0xc000486800, 0x8b7, 0x8b7, 0xc0005ab9c0, 0x3, 0x3, 0x900, 0x10000c00019da00, 0x314) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/filter/filter.go:31 +0x89 github.com/getgauge/gauge/filter.FilterSpecs(0xc000486800, 0x8b7, 0x8b7, 0x3, 0xc0005730a0, 0xc000486800) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/filter/filter.go:15 +0x19c github.com/getgauge/gauge/parser.ParseSpecs(0xc000187110, 0x1, 0x3, 0xc0003e0060, 0xc0005730a0, 0xc0000effa0, 0x1c, 0x1740f9a, 0xb) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/parser/parse.go:87 +0x85 github.com/getgauge/gauge/validation.ValidateSpecs(0xc000187110, 0x1, 0x3, 0x0, 0x0) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/validation/validate.go:175 +0x120 github.com/getgauge/gauge/execution.glob…func1(0xc000187110, 0x1, 0x3, 0x0) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/execution/execute.go:131 +0xb2 github.com/getgauge/gauge/cmd.execute(0x1cb5ca0, 0xc000187110, 0x1, 0x3) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/cmd/run.go:205 +0x102 github.com/getgauge/gauge/cmd.glob…func14(0x1cb5ca0, 0xc000187110, 0x1, 0x3) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/cmd/run.go:93 +0xfb github.com/getgauge/gauge/vendor/github.com/spf13/cobra.(*Command).execute(0x1cb5ca0, 0xc000187080, 0x3, 0x3, 0x1cb5ca0, 0xc000187080) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/vendor/github.com/spf13/cobra/command.go:651 +0x24a github.com/getgauge/gauge/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x1cb6fc0, 0xf, 0xc000192180, 0xc0001424b0) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/vendor/github.com/spf13/cobra/command.go:726 +0x2cc github.com/getgauge/gauge/vendor/github.com/spf13/cobra.(*Command).Execute(0x1cb6fc0, 0x0, 0xc00019df78) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/vendor/github.com/spf13/cobra/command.go:685 +0x2b github.com/getgauge/gauge/cmd.Parse(0x0, 0x176c960) /private/tmp/gauge-20190125-2013-18yzinh/gauge-1.0.4/src/github.com/getgauge/gauge/cmd/cmd.go:154 +0x3d main.main() src/github.com/getgauge/gauge/gauge.go:29 +0x3e

Gauge version

darwin, 1.0.4
	html-report (4.0.6), java (0.7.1), screenshot (0.0.1), xml-report (0.2.1)

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (8 by maintainers)

Commits related to this issue

Lazy parallelization of specification parsing. #1364 — committed to getgauge/gauge by deleted user 5 years ago
Lazy parallelization of specification parsing. #1364 — committed to getgauge/gauge by deleted user 5 years ago
Lazy parallelization of specification parsing. #1364 — committed to getgauge/gauge by deleted user 5 years ago
Lazy parallelization of specification parsing. #1364 — committed to getgauge/gauge by deleted user 5 years ago
Lazy parallelization of specification parsing. #1364 — committed to getgauge/gauge by deleted user 5 years ago
Lazy parallelisation of specification parsing. #1364 * Lazy parallelization of specification parsing. #1364 * Adding os specifc files. * Added license headers. * Unexporting specFileCollecti... — committed to getgauge/gauge by deleted user 5 years ago

Most upvoted comments

It turns out this has (likely) nothing to do with tags. The key to getting the error is a small value for number of open files as reported by ulimit -n. Below are details on versions used, getting Gauge to error and getting specs to run as expected. Changing the ulimit -n value has been seen to get Gauge working/breaking on multiple different OS X machines.

Gauge version details

Gauge version: 1.0.4

Plugins
-------
html-report (4.0.8)
java (0.7.2)
screenshot (0.0.1)
xml-report (0.2.1)

Machine used for these reproduction steps

MacBook Pro - Mojave. 16GB memory

Repro instructions

all of this is a standard terminal window

Initial setup and getting specs to error

running ulimit -n gives output 256 . <<— This value being small is important

Create a new java project with many specs. 1500 is used here.

Create a new directory
Run gauge init java in the new directory
In the specs directory, run for i in {1..1500}; do cp example.spec "example$i.spec"; done
In the main project directory created in the first step, run gauge run specs/
Observe errors: [ParseError] /…path…/example[number].spec: 0 Failed to read the file /…path…example[number].spec. => ‘’ and Panicing : runtime error: invalid memory address or nil pointer dereference

Getting specs to run as expected

This assumes all of the above steps in Initial setup… above have been completed

Run ulimit -n 4096 <-- this can be any large number. IntelliJ terminal uses 10240
Run ulimit -n to very the output is the large number from the above step
Run gauge run specs/
Observe specs run as expected.

Reference

Terminal -ulimit -a output

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) [256 | 4096]       < -----    **This is the value that gets changed**
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1418
virtual memory          (kbytes, -v) unlimited

ocary on Apr 24, 2019

Progress! All signs point to this being a open files limit problem.

By default ulimit -Sn shows 256 <-- Running specs here gives the error.

Changing that to 4096 via ulimit -Sn 4096, then running specs works as expected.

Interesting side note: The terminal inside IntelliJ 2018.3.3 CE, has on open files value of 12544. All other values shown in ulimit -a are the same between IntelliJ terminal and a “normal” terminal window.

ocary on Apr 18, 2019