SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: slin on April 07, 2021, 07:49:51 pm

Title: Help on Error Start Debugger
Post by: slin on April 07, 2021, 07:49:51 pm
I was trying to run gdb in slickedit but go the following errors in a pop-up window: "Error starting debugger: connection closed". In the output window, it shows:
[SE vagrant@0d328535f5bd ucpp]$ /vagrant/opt/slickedit-pro2020/bin/vsdebugio -port 8001  -prog  "/vagrant/temp/testcode/ucpp/Debug/ucpp"
Exiting with error: -103370

This is a new machine and I just installed Pro
The project I was testing is the SampleProject/ucpp.

What could be the problem here?
Title: Re: Help on Error Start Debugger
Post by: Dennis on April 07, 2021, 09:45:55 pm
First thing to try is to switch which GDB you are using:

1) Debug > Debugger Options > GDB Configurations...   
    Look at the one in bold.
    Is that /usr/bin/gdb or the one distributed with SlickEdit?
    Either way, they should both be in the list, click on the other, then check
    [ x ] Default native debugging configuration

2) If switching debuggers does not work, we have some logging to help narrow down
    what is going on.  Macro > Set Macro Variable... > def_debug_logging=1
    Then try to start debugging.
    Set def_debug_logging back to 0.
    The log file will be in your configuration directory under logs/debug.log

3) What Unix platform/distro are you on?

4) From a terminal window, try to run the GDB distributed with SlickEdit?
    /vagrant/opt/slickedit-pro2020/bin/gdb --version

5) Do the same for /usr/bin/gdb
    /usr/bin/gdb --version
Title: Re: Help on Error Start Debugger
Post by: slin on April 07, 2021, 10:55:59 pm
Thanks Dennis.
Here are what I got following your instructions:
1. changing the default native debugger between /usr/bin/gdb and slickedit-pro2020/bin/gdb does not make difference.
2. The debug log only had one line for each try "debug[2021-04-07T22:13:55Z]stopping 'vsdebugio' process"
3. I am using SE in a docker which essentially runs centos7, the host is centos8.
4. The version check returns as follows
[vagrant@0d328535f5bd logs]$ /vagrant/opt/slickedit-pro2020/bin/gdb --version
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site
[vagrant@0d328535f5bd logs]$ /usr/bin/gdb --version
GNU gdb (GDB) 8.2.1

More information. I also have an old platform that runs the same docker with 2019 SlickEdit. That one has not ever had issue using gdb.
Title: Re: Help on Error Start Debugger
Post by: Dennis on April 08, 2021, 05:21:14 pm
When you tried step (4), did you do that in a terminal in the same environment you are launching SlickEdit in.

What happens if you try the same "gdb --version" commands from the SlickEdit build window?

Try the logging again.  Just to be certain nothing is getting in the way, I would recommend closing SlickEdit and restarting it before hand.  There should be a lot more output than just the information about vsdebugio.

Final check, verify that you had not accidently modified the project to try to use a debugger other than GDB (Project > Project Properties... > Run/Debug)
Title: Re: Help on Error Start Debugger
Post by: slin on April 09, 2021, 08:46:08 pm
Hi Dennis,
The problem was resolved after I restarted the machine. The logging becomes normal after that too. Thanks for you help!

I hit another other issues after that, which does not show in my old machine either.

1. When I press F5 (or F7), a window/tab with the name "Build(.process)" jumps out into the editor window. It shows the same content as Build tool window at the bottom.  How can I disable it?
2. The above one is a minor issue.  What really bother me is when I press F5, the gdb did not go to the breakpoints that I set. In stead, it seems running until I hit the pause button and then it goes to the breakpoint.
3. I also observed some stack_log complains, after which the tool windows at the left side was forced off.
I attached the logs and screen captures for the above issues.
Update: I installed 2019 version 2400, which has been used in my old machine.  I tried several times on the same workspace. I haven't seen any of the above problems yet. I will keep using 2400 right now.