jpillora / jpillora/chisel

Error after a long run (> 2months)

Open
#121 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
16.6k
Forks
1.6k
PR merge metrics
No merged PRs in 30d

Description

Hi,
I have this error after 2 months of constant running:

2019/09/24 02:37:40 http: panic serving 10.39.0.0:41388: runtime error: invalid memory address or nil pointer dereference
goroutine 906693 [running]:
net/http.(*conn).serve.func1(0xc0002281e0)
/usr/local/go/src/net/http/server.go:1746 +0xd0
panic(0x7d38e0, 0xb52480)
/usr/local/go/src/runtime/panic.go:513 +0x1b9
github.com/jpillora/chisel/server.(*Server).handleWebsocket(0xc0000b4600, 0x8b1fe0, 0xc0001a80e0, 0xc000862200)
/src/server/handler.go:87 +0x47e
github.com/jpillora/chisel/server.(*Server).handleClientHandler(0xc0000b4600, 0x8b1fe0, 0xc0001a80e0, 0xc000862200)
/src/server/handler.go:23 +0x40f
github.com/jpillora/chisel/server.(*Server).handleClientHandler-fm(0x8b1fe0, 0xc0001a80e0, 0xc000862200)
/src/server/server.go:146 +0x48
net/http.HandlerFunc.ServeHTTP(0xc00009d450, 0x8b1fe0, 0xc0001a80e0, 0xc000862200)
/usr/local/go/src/net/http/server.go:1964 +0x44
net/http.serverHandler.ServeHTTP(0xc0000a3110, 0x8b1fe0, 0xc0001a80e0, 0xc000862200)
/usr/local/go/src/net/http/server.go:2741 +0xab
net/http.(*conn).serve(0xc0002281e0, 0x8b2360, 0xc0004fc480)
/usr/local/go/src/net/http/server.go:1847 +0x646
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2851 +0x2f5

It seems to be coming from the internals of go...

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting server/handler.go at line 87, where the stack trace reports the nil-pointer panic, and trace how handleClientHandler reaches handleWebsocket. Try to reproduce the failure during a long-running server session and identify the missing state or error path. Done means the server no longer panics in this scenario and the relevant behavior is covered by a regression test.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.