iCepa/Tor.framework

TorController.disconnect does not unbind socksport

Closed this issue · 7 comments

If you start, stop, and then start tor again, the second startup fails and crashes the app because it tries to bind to a port that is unavailable. This looks like it is because the disconnect function does not actually successfully unbind the port.

Which version are you using? Please note #62

0.400.6.3 it looks like? although I'm not sure how to tell.

Well, your package manager should tell you...

Besides, if that happens, that means Tor didn't stop. Check, if a Tor thread is still running or check the memory analysis, if a TorThread class is still hanging around.

In that case, I'm pretty confident, that you're using 402.7.1 instead of 400.6.3 which has that known bug I mentioned.

The Info.plist in the Tor.framework folder definitely says 400.6.3. I did not use a package manager. We put the Tor.framework directly in the Pods folder. I'll try the threads / memory analysis and report back.

OK so I just looked into the XCode debugging and Here is what I've found. When I call the TorController.disconnect, it kills all of the network connections (expected), but it does not actually clean up the thread named "Tor". Furthermore, subsequent startups attempt to bind the socksport twice. The second one fails, crashing the whole application.

I did not use a package manager. We put the Tor.framework directly in the Pods folder.

This sounds like you‘re missusing Cocoapods. Don‘t do that. Either use Cocoapods or Carthage as intended to integrate this dependency and positively use 400.6.3.

Everything later currently has an issue with shutting down Tor.

All problems you report are exactly like that issue #62 with 402.7.1.

I cannot "use cocoapods correctly" because there is no "Tor" pod that is visible and I don't know what pod repo to add to find it.

I have also definitively tested with 400.6.3 and it still exhibits behavior above. It is worth noting though that this is probably a bug in the tor_api