Wiretap crashing on invalid memory address

[fullstackmaverick]

I am getting the following error for hitting my endpoint via http://localhost:9090

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x68 pc=0x102e1e97c]

goroutine 1289 [running]:
github.com/santhosh-tekuri/jsonschema/v5.(*Schema).validateValue.func1()
        /home/runner/go/pkg/mod/github.com/santhosh-tekuri/jsonschema/v5@v5.3.1/schema.go:178 +0x120
panic({0x1038282a0?, 0x1040efad0?})
        /opt/hostedtoolcache/go/1.22.5/x64/src/runtime/panic.go:770 +0x124
github.com/santhosh-tekuri/jsonschema/v5.(*Schema).validate(0x0, {0x0, 0x0, 0x0}, 0x0, {0x0, 0x0}, {0x103818a00, 0x140004202a0}, {0x0, ...})
        /home/runner/go/pkg/mod/github.com/santhosh-tekuri/jsonschema/v5@v5.3.1/schema.go:253 +0x43c
github.com/santhosh-tekuri/jsonschema/v5.(*Schema).validateValue(0x0, {0x103818a00?, 0x140004202a0?}, {0x0, 0x0})
        /home/runner/go/pkg/mod/github.com/santhosh-tekuri/jsonschema/v5@v5.3.1/schema.go:182 +0x94
github.com/santhosh-tekuri/jsonschema/v5.(*Schema).Validate(...)
        /home/runner/go/pkg/mod/github.com/santhosh-tekuri/jsonschema/v5@v5.3.1/schema.go:168
github.com/pb33f/libopenapi-validator/responses.ValidateResponseSchema(0x140004d1680, 0x140000d6480, 0x140000f9b88, {0x14000958000, 0x1020, 0x1500}, {0x1400096a000, 0x8d4, 0x1400026c1d1?})
        /home/runner/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.56/responses/validate_response.go:132 +0x99c
github.com/pb33f/libopenapi-validator/responses.(*responseBodyValidator).checkResponseSchema(0x140005da440, 0x140004d1680, 0x140000d6480, {0x1400026c1c0?, 0x1039b44a0?}, 0x1400026b740)
        /home/runner/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.56/responses/validate_body.go:152 +0x20c
github.com/pb33f/libopenapi-validator/responses.(*responseBodyValidator).ValidateResponseBody(0x140005da440, 0x140004d1680, 0x140000d6480)
        /home/runner/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.56/responses/validate_body.go:66 +0x4bc
github.com/pb33f/libopenapi-validator.(*validator).ValidateHttpResponse(0x1400083a380, 0x140004d1680, 0x140000d6480)
        /home/runner/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.56/validator.go:120 +0xbc
github.com/pb33f/wiretap/daemon.(*WiretapService).ValidateResponse(0x140007b2a90, 0x14000090300, 0x140000d6480)
        /home/runner/work/wiretap/wiretap/daemon/validate.go:19 +0x6c
created by github.com/pb33f/wiretap/daemon.(*WiretapService).handleHttpRequest in goroutine 1281
        /home/runner/work/wiretap/wiretap/daemon/handle_request.go:176 +0xad8

Due to compliance issues I'm not able to share the API file but would love to provide more information as required.

This seems to have come after #132

[daveshanley]

This issue is coming from another library we depend on for validating schemas:

https://github.com/santhosh-tekuri/jsonschema

The top four elements of the stack trace, are all from this library getting upset about trying to validate a schema against an object coming into wiretap.

I do not know what is causing the issue, there is no way to tell what did what. I would need to see an example request/response and the schema for that request/response as defined in the OpenAPI spec.

There is a way for wiretap to short circuit things if we know what schema element is breaking the underlying library. There is a nil pointer somewhere, but it could be anything.

Please send the details to support [at] pb33f.io if you do not wish to share publicly.

[savvyintegrations]

Hey @daveshanley. I'm getting the same error with this request, using the OAS doc I sent you yesterday:

curl http://localhost:9090/jobs -H "x-auth-context:eyJ0ZWFtSWQiOiI5NGJlZTE3MC0xN2IzLTQxN2ItOTQxMS05ZDUzMDI0YzBlMzUiLCJpc05vcmRpY2FuVGVhbSI6ZmFsc2UsInNvdXJjZUFwaVR5cGUiOiJyZXN0IiwicGxhblR5cGUiOiJQcm8iLCJjcmVhdGVkQXQiOiIyMDI0LTA2LTIxVDAzOjI2OjQ5LjI0MloiLCJhdXRoZW50aWNhdGlvblRva2VuVHlwZSI6ImFwaV9rZXkiLCJjb3JyZWxhdGlvbklkIjoiNDdiOWFjY2ItMzQ4Ni00NzQ2LWEzODItZmZlZTUwNThlNWU3IiwicmVxdWVzdGVySWQiOiI2MWM3MWNjOS1hZGY4LTQ1MzAtOWU4ZC01YjU4NWYxMTE0NWEiLCJyZXF1ZXN0ZXJUeXBlIjoiVGVhbU1lbWJlciIsInVzZXJBY2NvdW50SWQiOiI4Y2I1NDY1NC1iMWNiLTQ0ZTAtYTc1My01YzYyMzc0OGQ3NjUiLCJyb2xlIjoiQWRtaW4iLCJkZXZpY2VHcm91cHMiOltdfQ=="

You can probably disregard the custom header. We use it to run the API locally, bypassing an AWS Lambda authorizer. The base64-encoded string is an authorizer event instance.

[daveshanley]

Can you re-try this with v0.2.0 A lot of dependencies have been upgraded.