Stack overflow on GET request after updating to 1.2.0

[JustASquid]

The error occurs when a request is made. Let me know if I can provide any other info.

error.log swagger.json.txt

[zxchris]

Thanks for reporting, we are investigating.

Did you build from source, or download the prebuilt release? What platform/OS are you using?

Thanks.

[zxchris]

We can reproduce with the specification you sent... but we get the stack overflow even when we wind DapperDox back to Feb 8th 2017, which was the first public release (1.0.0).

[zxchris]

Found the issue: The lower level OpenAPI parser (go-openapi) that DapperDox uses is causing the stack overflow. We have wound the version of go-openapi back, and now DapperDox is working fine.

We will need to open an issue with go-openapi, and reference this issue.

We will release an intermediate release built with the old go-openapi. (See release v1.2.2 - hopefully that works for you. We have opened an issue with go-openapi too).

[ax-nathan]

I can confirm that this happens with a smaller (727 lines) swagger as well. I can't post it here, but maybe I can create a minimal reproduction.

[ax-nathan]

I found my issue...was caused by a (perfectly legal in Go) recursive type definition.

type FooBar struct {
	// Foo time
	//
	// required: true
	// swagger:strfmt time
	Foo string `json:"foo"`

	// Bar time
	//
	// required: true
	// swagger:strfmt time
	Bar []FooBar `json:"bar"`
}

...resulting in a recursive reference...

    "FooBar": {
      "type": "object",
      "required": [
        "foo",
        "bar"
      ],
      "properties": {
        "bar": {
          "description": "Bar time",
          "type": "array",
          "items": {
            "$ref": "#/definitions/FooBar"
          },
          "x-go-name": "Bar"
        },
        "foo": {
          "description": "Foo time",
          "type": "string",
          "format": "time",
          "x-go-name": "Foo"
        }
      }
    },

BOOM!

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0x156162a, 0xe)
        /usr/local/Cellar/go/1.9.2/libexec/src/runtime/panic.go:605 +0x95
runtime.newstack(0x0)
        /usr/local/Cellar/go/1.9.2/libexec/src/runtime/stack.go:1050 +0x6e1
runtime.morestack()
        /usr/local/Cellar/go/1.9.2/libexec/src/runtime/asm_amd64.s:415 +0x86

goroutine 1 [running]:
github.com/go-openapi/spec.Schema.MarshalJSON(0x0, 0x0, 0x0, 0xc420303100, 0xc4203a7200, 0x2, 0x2, 0x10000, 0x0, 0x0, ...)
        /Users/nathan/go/src/github.com/go-openapi/spec/schema.go:555 +0x87a fp=0xc441b08338 sp=0xc441b08330 pc=0x13c3caa
github.com/go-openapi/spec.(*Schema).MarshalJSON(0xc420203440, 0x154f760, 0xc420203440, 0x1dc1aa0, 0xc420203440, 0xc441b08501)
        <autogenerated>:1 +0x67 fp=0xc441b08580 sp=0xc441b08338 pc=0x13c7ce7
encoding/json.marshalerEncoder(0xc441267e40, 0x154f760, 0xc420203440, 0x16, 0xc420200100)
        /usr/local/Cellar/go/1.9.2/libexec/src/encoding/json/encode.go:443 +0x9f fp=0xc441b085f0 sp=0xc441b08580 pc=0x12ee7ef
encoding/json.(*encodeState).reflectValue(0xc441267e40, 0x154f760, 0xc420203440, 0x16, 0x100)
        /usr/local/Cellar/go/1.9.2/libexec/src/encoding/json/encode.go:323 +0x82 fp=0xc441b08628 sp=0xc441b085f0 pc=0x12edeb2
encoding/json.(*encodeState).marshal(0xc441267e40, 0x154f760, 0xc420203440, 0x100, 0x0, 0x0)
        /usr/local/Cellar/go/1.9.2/libexec/src/encoding/json/encode.go:296 +0xaf fp=0xc441b08660 sp=0xc441b08628 pc=0x12edb9f
encoding/json.Marshal(0x154f760, 0xc420203440, 0xc4302d3b80, 0x96, 0x14f6580, 0xc4203a7180, 0xc441267db8)
        /usr/local/Cellar/go/1.9.2/libexec/src/encoding/json/encode.go:161 +0x5f fp=0xc441b086a8 sp=0xc441b08660 pc=0x12ed56f
github.com/go-openapi/spec.SchemaOrArray.MarshalJSON(0xc420203440, 0x0, 0x0, 0x0, 0x10109e3, 0x14d8bc0, 0x14f6580, 0x14f6501, 0x1dc1a78)
        /Users/nathan/go/src/github.com/go-openapi/spec/swagger.go:291 +0xb9 fp=0xc441b086f0 sp=0xc441b086a8 pc=0x13c61e9
github.com/go-openapi/spec.(*SchemaOrArray).MarshalJSON(0xc4203a7180, 0x14f6580, 0xc4203a7180, 0x1dc1a78, 0xc4203a7180, 0x1)
        <autogenerated>:1 +0x5f fp=0xc441b08748 sp=0xc441b086f0 pc=0x13c7f2f

[zxchris]

Despite the recursive issue, which version of DapperDox was that failure? Built from source or a binary release?

Cheers

[Kerzman]

There is a known bug in OpenApi 2.0 https://github.com/swagger-api/swagger-editor/issues/1005#issuecomment-307304119

It seems like they fixed it in OpenApi 3.0

@zxchris are there any plans to update to OpenApi 3.0 (fully or optionally)?

Great job BTW!