search

rohanrhu / gdb-frontend

☕ GDBFrontend is an easy, flexible and extensible gui debugger.
GNU General Public License v3.0
2.86k stars 100 forks source link

Alert!: Unable to connect to remote host. #43

Closed radszy closed 2 years ago

radszy commented 2 years ago

Using HEAD of master - 09831e2a83f0337724fd27ce60c4d7ae07fc4b4f Python 3.9 Ubuntu 18.04 Tmux 2.6-3

I'm trying to run gdb-frontend on my remote machine and open browser window on my local computer.

$ ./gdb-frontend -l 0.0.0.0
Error loading http://127.0.0.1:5550/terminal/:
Connection refused

And when I open the link (with the actual IP of remote server) I get this message with an OK button, which just pops up the same message each time I click it.

Connection is closed to GDBFrontend server!

For comparison, I tried the same thing with gdbgui and that works fine for me.

$ gdbgui -r
View gdbgui at http://127.0.1.1:5000
View gdbgui dashboard at http://127.0.1.1:5000/dashboard
exit gdbgui by pressing CTRL+C

I tried several older tagged versions of gdb-frontend, but none of them works for me. Even without passing the -l param I get the same error.

There's also this Alert! message from the issue's title, when the gdb-frontend tries to render the page on my remote machine using lynx.

rohanrhu commented 2 years ago

Hi, thank you for feedback!

If you are connecting to a remote host, you must use -l 0.0.0.0 parameter.

Can you try like this?

gdbfrontend -l 0.0.0.0
rohanrhu commented 2 years ago

I tried several older tagged versions of gdb-frontend, but none of them works for me. Even without passing the -l param I get the same error.

Oh.. you already tried that.. Let me look at the problem.

rohanrhu commented 2 years ago

Oh... I tried it on my server and looks like Debian Jessie's current GDB version is using Python 2.7 as embedded-Python. I think you have the same problem.

I think I should add this as soon as possible :)

image

Sooo, you can build GDB from source with embedded-Python 3.

How to build GDB 11 with embedded-Python3?

Follow these steps to build GDB 11 with embedded-Python3

cd ~
wget https://ftp.gnu.org/gnu/gdb/gdb-11.1.tar.xz
tar zxvf gdb-11.1.tar.gz
mkdir gdb-11.1-build
cd gdb-11.1-build
../gdb-11.1/configure --with-python=/usr/bin/python3 --enable-interwork --enable-multilib
make

Then you can start GDBFrontend like this

gdbfrontend -g $(realpath ~/gdb-11.1-build/gdb/gdb) -G --data-directory=$(realpath ~/gdb-11.1-build/gdb/data-directory/) -l 0.0.0.0

Troubleshooting about build dependencies

I had to install libgmp-dev package for Debian. If you have some missing build dependencies, configure script will say the missing library, just find it in your package management system and install.

I hope it will work :)

rohanrhu commented 2 years ago

Hewwoo.. have you tried it yet? I believe it will work 😊

You can look for tmux a -t gdb-frontend output for seeing the error. You will probably see an ImportError for socketserver module because your GDB has embedded Python 2.7.

radszy commented 2 years ago

Huh, you are quick to respond... Anyway, it turned out that it indeed has something to do with the Python version.

I did build gdb with Python 3.6 (wouldn't compile with Python 3.9, and I didn't feel like figuring out why), but that didn't do any trick. And then realized that gdb-frontend was using 3.9 and that mismatch could cause some issues.

As I had on my system set Python 3.9 as a default one (using update-alternatives), after changing it back to Python 3.6 (default Ubuntu installation) and installing gdb-frontend again using pip, now it just works :)

As a side note, the default gdb installation on Ubuntu seems to be already using the default Python 3.6. Realized that after building my own gdb.

(gdb) python import sys; print(sys.version_info)
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)
rohanrhu commented 2 years ago

As a side note, the default gdb installation on Ubuntu seems to be already using the default Python 3.6. Realized that after building my own gdb.

(gdb) python import sys; print(sys.version_info)
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)

Umm... maybe we have a problem with Python 3.6 too? I will look for that.

As I had on my system set Python 3.9 as a default one (using update-alternatives), after changing it back to Python 3.6 (default Ubuntu installation) and installing gdb-frontend again using pip, now it just works :)

Oh it is very nice soo you don't have any issues now right?

radszy commented 2 years ago

Well, I got to the point where I can load, start executing binary and see source code in gdb-frontend. But the overall experience seems super slow compared to gdbgui and vscode debugger, it's like in slow motion.

Also for some reason this issue didn't go away completely. I can start gdb-frontend on my remote machine only from vscode terminal, but when I do it from iTerm it keeps showing "Connection refused" error and the webpage says that the connection got closed. However, even with this error, the tmux gdb-frontend session doesn't show any error.

Starting the server from vscode terminal allows me to load gdb-frontend webpage, but again everything is slow. I was able to load binary only through gdb command, gdb-frontend navigates through files, but doesn't do anything once I select file.

It all sounds super weird and unfortunately I don't have time to play with it. I'll come back to this some other day.

Edit: After changing port I got this error message on startup:

(gdb) 10.171.79.12 - - [17/Jan/2022 22:12:38] code 400, message Bad HTTP/0.9 request type ('\x16\x03\x01\x02\x00\x01\x00\x01ü\x03\x033£\x8crv©mÁ²ªÈ±·p˾ð`#\x97Ô2?\x03Ùõ\x8e\x1a±Z\x9eg')
rohanrhu commented 2 years ago

Interesting.. I will look for the issue.

rohanrhu commented 2 years ago

@radszy can you provide more information about what you are doing exatly?

I think there is a problem about links browser. I have links on my server and GDBFrontend is opening the UI on default browser on startup. It is weird; I will fix it soon.

We are testing the debugger with big projects and recently I solved performance issues.. I wonder about why do you have performance issues.

Maybe about network speed? Because you are using GDBFrontend on remote. But also you are saying that other softwares are working fast. It is really interesting.

Also for some reason this issue didn't go away completely. I can start gdb-frontend on my remote machine only from vscode terminal, but when I do it from iTerm it keeps showing "Connection refused" error and the webpage says that the connection got closed. However, even with this error, the tmux gdb-frontend session doesn't show any error.

I have no idea for this terminal issue yet. I will investigate the problem.

Sooo can you provide more information about your platforms and what you are doing exactly?

rohanrhu commented 2 years ago

@radszy Oh I forget that asking for your browser.. Sooo what is your browser?

radszy commented 2 years ago

I'm using Firefox 96.0.2 on MacOS 12.1.

I have pulled latest changes from master, and things seem to have improved by quite a lot. I still have this weird issue when I try to run it from iTerm, but works reasonably fine from VSCode terminal (as in, it's fast enough now).

rohanrhu commented 2 years ago

Can you start the debugger with verbose: gdbfrontend --verbose on iTerm and send tmux a -t gdb-frontend output?

radszy commented 2 years ago

In that tmux session there's just a standard gdb loaded up with no errors or anything suspicious.

I think the problem is that with iTerm, I'm essentially on my remote machine and it tries to open a website in the browser, but for some reason it chooses lynx (well, opening firefox on my remote machine wouldn't make sense, as all I have is just the terminal).

Whereas when I do it from VSCode, I'm rather on my local machine, but with the connection to the remote, and thus VSCode opens links on my local machine, and the default browser is Firefox and that just works.

Could it be that gdb-frontend requires some special browser functionality and thus it fails with lynx?

Is there an option in gdb-frontend, so that it doesn't automatically open webpage when it starts up? Gdbgui doesn't do that for me, and so I copy paste it into my browser on local machine.

rohanrhu commented 2 years ago

I added an option to avoid opening UI on default browser on startup: --dontopenuionstartup, -D.

Can you download the latest revision and try it like this?

gdbfrontend --dontopenuionstartup
radszy commented 2 years ago

Yup, that solves my problem, thanks :)

rohanrhu commented 2 years ago

Yay! Sooooo can we close this issue now?

radszy commented 2 years ago

Yes, you can close it.

rohanrhu commented 2 years ago

Yes, you can close it.

Well.. Sooo do you have another issue?

jaypuncher commented 2 years ago

So, in the end, what was the solution? I am running into the same issue.

$ ./gdbfrontend --gdb-executable=.../bin/gdb --verbose -D GDBFrontend v0.10.3-beta Listening on 127.0.0.1: http://127.0.0.1:5550/ Open this address in web browser: http://127.0.0.1:5550/terminal/

Python 3.9 OL 7.9 Tmux 1.8

Opening in Firefox (91.4) results in the same error message (Connection is closed to GDBFrontend server!). However, I can connect to the frontend via tmux start on terminal window.

Thanks,

rohanrhu commented 2 years ago

Hiiii @jaypuncher thank you for feedback.

What is the output for?

tmux a -t gdb-frontend

Can you try it also on Chrome?

What do you mean with this?

I can connect to the frontend via tmux start on terminal window.

jaypuncher commented 2 years ago

Hiiii @jaypuncher thank you for feedback.

What is the output for?

tmux a -t gdb-frontend

Can you try it also on Chrome?

What do you mean with this?

I can connect to the frontend via tmux start on terminal window.

Ok. As it turns out the issue was with the version of TMUX. I've tested with TMUX 3.2 and things are working.
Looking forward to trying this tool out.

Thanks,

rohanrhu commented 2 years ago

Thank you too 😊 We need a warning for old tmux versions. 😱

BuckAMayzing commented 2 weeks ago

@rohanrhu - I hate to necro this thread, but I think I may have found an edge case. I doubt it's the same underlying cause, so I can open up a new issue if you'd like.

My use case is connecting to a remote UEFI app running through qemu. Commands and such work fine from within gdb itself. I ran verbose, and saw the error below show up. Let me know if there's any other diagnostics you want me to do.

image

rohanrhu commented 2 weeks ago

@rohanrhu - I hate to necro this thread, but I think I may have found an edge case. I doubt it's the same underlying cause, so I can open up a new issue if you'd like.

My use case is connecting to a remote UEFI app running through qemu. Commands and such work fine from within gdb itself. I ran verbose, and saw the error below show up. Let me know if there's any other diagnostics you want me to do.

image

Hi @BuckAMayzing, thank you for your feedback.

Unfortunately, I don't have energy to look for issues recently, I think we need a new maintainer for now; I'll look for all recent issues and release a new version soon but I'm not sure how much "soon".

Can you please open a new issue with all diagnostics and results that you can do? Not all the GDB functionalities work same when you use a remote debug target so could you tell about what things are unexpectedly not working with a remote target?