Open aabes opened 7 years ago
Could you provide a sample project to reproduce the problem? It would help us to investigate.
@avokin - will do, but it's pretty obvious from the code and the docker compose file. You can host any app inside the docker container "web", and it will fail in similar way.
If you look here: https://github.com/ruby-debug/ruby-debug-ide/blob/master/lib/ruby-debug-ide.rb#L120 and assuming I'm reading this right - it will use the address of the peer. In the scenario here, that will be the gateway address of the docker bridge, instead of the address of host on which IJ is running.
The possible solutions I can think off are around the theme of passing in the host-ip address of the host running IJ... either via CLI or inline via protocol.
I'll create a public repo with this project & instructions re: repro, but it will take a little while.
@avokin - see: https://youtrack.jetbrains.com/issue/RUBY-19748#comment=27-2309778 with details about a demo project and instructions on how to repro.
Setup: Host: OSX. Docker 17.06 mac. Rails environment built into docker-compose (which means, it's setup with private network). see below.
Issue: When connecting a InelliJU debug session to a waiting debug session inside the container, breakpoints hit on the master process (of zeus) but not on child processes.
Using Strace, it seems that the forked child is attempting to connect to the gateway address as seen from the container, rather than the host address. Looking at code a bit around here seems DEBUGGER_HOST is set based on the network info. This results in the child not connecting to the IDE, and no breakpoints being configured.
Seems that if there was a way to pass an override environment variable as to where the IDE is (the host computer, then the child could connect and apply breakpoints?
Debugger invocation: ./bin/rdebug-ide -d --host 0.0.0.0 --port 1234 --dispatcher-port 26162 -- /cht/app/bin/zeus start --log zeus.log