Cant quit sometimes #121
Comments
|
Yikes again. That's bad. Please could you add the following to [main]
debug = trueNow when you start termshark, it will run a Go debugging server on localhost:6060. When termshark is stuck and won't terminate, it would be very useful to see the contents of http://localhost:6060/debug/pprof/goroutine?debug=1 Thanks! |
|
I've assumed you're on Linux - let me know if not and you need help finding the config file. |
|
Sounds good. |
|
Here's a trace: |
|
Thanks! That helps me understand where the problem lies. I'm trying now to come up with a theory for what gets termshark into this state. Is there anything notable about your use of the program when this happens e.g. are you reading from an interface? Or do you load up more than one pcap in the same termshark session? Would you mind attaching the log file too? It should be |
|
I have a theory - I see a hole in my process handling. I'll try to get a binary to you to try, as a replacement. |
This is an attempt to solve issue #121. I think my mistake is as follows: - I start the goroutine that runs the pcap process - after starting the process, I send its pid via a channel to another goroutine that controls process life-cycles - however that goroutine has closed down because the user issued a cancel The process lifetime goroutine should not shut down if it is guaranteed the pcap running goroutine is going to send its pid, because then nothing will listen for it. I've adjusted the logic so now that goroutine will definitely wait for the pid - unless it receives a pid==0 which indicates there was a problem starting the process.
|
Hi @deliciouslytyped - I pushed a commit with an experimental fix. Would you be willing to try it? It would just mean replacing one binary - or just put this one in your PATH ahead of the one you're using now. The binary will still advertise itself as v2.2.0, but it's really v2.2.0 with one extra commit. Here are the download links: |
|
I would strongly prefer a source patch on a branch. (the thing is, running random binaries on nixos is more of a pain anyway) |
|
I don't know about architecting this stuff, but I think stuff like handling (forced) exit shouldn't fail "stuck". Cleanup code should be reliable "by default" - i.e. even if it fails for unforseen reasons it should still more or less work in some intended way. - but I realize I'm being very handwavy. |
|
Understood - if you have the source code, the commit to build from is 43216e2; or I take your point about failing stuck. I block at shutdown deliberately, but maybe it's the wrong choice for official releases. It gives me a better shot of being alerted to program flows that expose bugs, but I'm not sure if it's fair to users. |
|
That doesn't seem unreasonable, maybe there's a better way to get the best of both worlds. If you can get what you want but keep it responsive that's probably fine for me. |
|
I think this is fixed as of bfea053. Please re-open if you see it come back! |
I'm on 2.2.0 .
Sometimes I can't quit. The confirmation dialog comes up but nothing happens when I click or hit enter on the ok button.
The cancel button works fine.
ps aux | grep tsharklists no tshark processes but the "waiting for packets" animation thing is still going.I don't know how to repro this.
https://www.youtube.com/watch?v=7cbjlV1l28U
The text was updated successfully, but these errors were encountered: