gen.PtrOf sometimes causes a panic

[Jean-Paul Calderone]

A test I wrote using PtrOf sometimes results in a panic like this:

Parent ids not equal
! fields round-trip: Error on property evaluation after 0 passed tests:
   Check paniced: reflect: Call using zero Value argument goroutine 14
   [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
        /usr/lib/go/src/runtime/debug/stack.go:24 +0x80
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.SaveProp.
  func1.1(0xc8202a9ba8)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop.go:19 +0x53
panic(0x79ffc0, 0xc8203daaf0)
        /usr/lib/go/src/runtime/panic.go:426 +0x4e9
reflect.Value.call(0x8311a0, 0xc8203da2d0, 0x13, 0x8e40c8, 0x4,
   0xc820395f90, 0x3, 0x3, 0x0, 0x0, ...)
        /usr/lib/go/src/reflect/value.go:367 +0x48b
reflect.Value.Call(0x8311a0, 0xc8203da2d0, 0x13, 0xc820395f90, 0x3, 0x3,
   0x0, 0x0, 0x0)
        /usr/lib/go/src/reflect/value.go:303 +0xb1
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter/prop.chec
  kConditionFunc.func2(0xc8203b2900, 0x3, 0x3, 0x3)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop/check_condition_func.go:45 +0x1db
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter/prop.ForA
  ll.func1.1(0x0, 0x0, 0x86a401)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop/forall.go:51 +0x112
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter/prop.firs
  tFailure(0xc8203cea80, 0xc8202a9b40, 0xc8203cea80, 0x0, 0x0)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop/forall.go:104 +0x5f
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter/prop.shri
  nkValue(0x3e8, 0xc820395e00, 0x778480, 0xc8203da7e0, 0xc820395f40,
   0xc8202a9b40, 0xc820395f40, 0x0, 0x0)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop/forall.go:88 +0xb5
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter/prop.ForA
  ll.func1(0xc8203edc00, 0x9b53c8)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop/forall.go:52 +0x53d
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.SaveProp.
  func1(0xc8203edc00, 0x0)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop.go:24 +0x68
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.Prop.Chec
  k.func1(0x0, 0xc8203da360, 0xd44b20)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop.go:51 +0x19e
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.(*runner)
  .runWorkers(0xc8203b25a0, 0x0)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/runner.go:45 +0x102
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.Prop.Chec
  k(0xc8203da340, 0xc8201f4140, 0x938f20)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/prop.go:106 +0x1c2
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.(*Propert
  ies).Run(0xc8203b2480, 0x7ff522cf6968, 0xc8203ed860, 0x45085e)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/properties.go:35 +0xe7
github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gopter.(*Propert
  ies).TestingRun(0xc8203b2480, 0xc8200845a0)
        /golang/src/github.com/ClusterHQ/dataplane/vendor/github.com/leanovate/gop
  ter/properties.go:46 +0x119
github.com/ClusterHQ/dataplane/dataset.TestAddSnapshot(0xc8200845a0)
        /golang/src/github.com/ClusterHQ/dataplane/dataset/dataset_test.go:409
   +0x295
testing.tRunner(0xc8200845a0, 0xd2da98)

I think I minimized the test case that provokes this behavior. You can see it at master...ClusterHQ:call-using-zero-value-argument

I wasn't quite sure where to put this test or even if it's a real problem I've found or just a mis-use of PtrOf. Finishing up for today, will probably look more tomorrow, thought I'd see if you had any thoughts on the issue.

[Bodo Junglas]

Created a temporary fix for that one.
Problem is neither in the generator nor in the shrinker, but in the invocation of the check-function. PtrOf actually generates "nil" values and reflect.ValueOf(nil) just creates the wrong type.

The current fix is a not very elegant workaround. Will try to come up with a better solution.

Please verify if this actually resolves the cause of the problem (provided example works for me now)

[Bodo Junglas]

I'm still not very happy how the sieve works at the moment.
Maybe I should add a default sieve (i.e. prevent GenResult.Sieve from being nil), but that would be a bigger refactoring.
So for now I will leave it like this.

[Jean-Paul Calderone]

Thanks! This working for me now.