Could not start app for debugging in beta2 with clang++/lldb

[rowbearto]

Use attached clanghello.tar.gz
I am using beta2 on Linux x64, CentOS 7.2
I have clang 6.0.1 compiler installed in a special directory that I built from source, but maybe you can repro with other clang?

Launch SE with clean config
Load workspace "clanghello.vpw"
Build it (launches the bldhello script)
In a bash prompt, check that the executable "clanghello" is there and that you can execute it and it prints hello message
Press F5 to start debugging
Get error message "Could not start app for debugging"
In build window, can see that it tried to do: <sepath>/bin/vsdebugio -port 8001  -prog  "<clanghellopath>/clanghello/clanghello"

So it is using the correct path to the executable.

Another related question. For gdb, it is possible to tell SE where to find an alternative gdb debugger.
But what about for an alternative "lldb" debugger?
As I built my clang from source, it has its own compatiable "lldb" executable, and I would rather use that one instead of the one bundled with SE. In Tools->Options->Debugging->Configuration, there is only a way to specify a custom gdb, but no way to specify a custom lldb.

[Dennis]

lldb integration works differently than gdb integration.  With GDB, we are launching the gdb executable, and communicating through their awful GDB/MI interface.  That makes specifying an alternate gdb executable relatively easy.  With LLDB, we link with liblldb (which we supply), and call into their APIs, so specifying an alternate version is out of the question.  Our latest update to LLDB was based on LLVM 4.0, but I doubt they changed the ABI enough to make things incompatible.

Does "Build > Execute" work?  If that works, then you know the project is set up correctly with respect to the location of the executable.

Have you tried factoring the project setup out of things and launching the debugger using Debug > Attach Debugger > Debug Executable (lldb) ?

Is the program you are trying to build built 64-bit ?  LLDB on Linux can't handle 32-bit apps last I checked.

There is debug tracing you can turn on to help narrow down on the problem. 
  * Macro > Set Macro Variable... > def_debug_logging = 1
  * Try to start a debugging session
  * Stop the session
  * Macro > Set Macro Variable... > def_debug_logging = 0
  * The log will be in <config>/logs/debug.log

[rowbearto]

I've modified the project a little bit to properly enter in the executable to execute/debug, but still doesn't work with lldb (same error). See attached.

Build->Execute does work with attached project.

Debug with lldb yields error "Could not start app for debugging".

However if I change debugger to gdb, debugging does start. However when I do that (with other projects), it doesn't display std::string properly (same issue occurs with eclipse debugging with gdb) so I was thinking lldb may be better and wanted to try it.

[Dennis]

I was able to step through your executable with our integrated LLDB on my Linux box, but it has an older version of clang (3.5) installed, so I didn't have any debug information for std::string.

GDB can limp along debugging clang generated code, but it does a poor job with variables.  Because of the differences between the Clang std library and GCC's std library, you should expect things like std::string to just fail to be evaluated.

[rowbearto]

Hmmm. Any ideas about how we can get you to repro the issue that I'm seeing on my end with the "Could not start app for debugging" message?

I'd much rather debug with lldb instead of gdb.

Maybe a repro requires the clang version 6.0.1 that I have? I don't have the old clang 3.5 installed, it would be time consuming for me to do so.

[Dennis]

See above w.r.t debug logging.  The version of clang you have installed has little to do with whether you can debug or not, because we use a version of liblldb that is shipped with SlickEdit.  The only difference in principal is whether or not you'll be able to debug symbols from the std library.

[rowbearto]

My apologies for not fully reading your earlier post about the logging and other questions.

Attached is the debug.log.

To answer the questions from that post:

Have you tried factoring the project setup out of things and launching the debugger using Debug > Attach Debugger > Debug Executable (lldb) ?

I will try that now and update you.

Is the program you are trying to build built 64-bit ?  LLDB on Linux can't handle 32-bit apps last I checked.

It is 64 bit.

[rowbearto]

Have you tried factoring the project setup out of things and launching the debugger using Debug > Attach Debugger > Debug Executable (lldb)

I'm getting the same error.

Attached is the debug log with this attempt appended to it.

[rowbearto]

Still having this problem in beta3.

Let me know if there is anything else I can do to help debug it.

If you really need, I could try replicating it in a bare bones Virtualbox virtual machine that I've shared in the past before.

[Dennis]

Patrick tracked this down to vslldbserver crashing.  vslldbserver is an LLVM/LLDB tool we just renamed to prevent conflicts.  My guess the problem is with our LLVM 4.0 based LLDB trying to read symbols from your LLVM 6.0.1 based code.  Either way, it's not our code.  You could try putting your lldbserver executable in its place, but I'm quite certain that would just be an exercise in futility.

We plan to address this for 23.0.1 by updating our LLDB support to LLVM 6.0.1 (or whatever the latest is at that point).

[rowbearto]

Hi Dennis:

I'm not sure if it has anything to do with clang 6.0.1. The other day I built clang 3.5.2 from source, built my sample with clang 3.5.2 and ended up with the same problem. I didn't mention this because you had already said the clang version did not matter. But now that you do suspect clang version, I think it is important that you know the results of this experiment of mine.

Rob

[rowbearto]

Still having this problem in beta4

[rowbearto]

I created a virtual machine where you can check if the problem you are fixing is the same as mine.

Look for "lldb_vm_location.txt" on support for the link to download the VM.

I used Virtualbox 5.2.18 for the VM, also you need the "Virtualbox extensions pack" in order to run the VM properly, otherwise you may get USB errors, which I think you may have gotten with VMs I shared last year.

Here are the instructions to reproduce:

1) Install VirtualBox 5.2.18
2) IMPORTANT: Install Virtualbox extension pack 5.2.18 (it is a separate download)
3) Download centos7-1511-lldb-issue.7z from the link provided in "lldb_vm_location.txt" on support
4) Unzip it to get a file named centos7-1511-lldb-issue.ova
5) In Virtualbox, do File->Import Appliance to import the ova file
6) Start the virtual machine
7) Maximize VirtualBox, the linux guest OS will fill the screen
At login screen, click on "setest" to login
9) Enter password "setest" and sign in
10) Right click on desktop and select "Konsole"
11) Type "vsl" at the prompt to Launch SE
12) Wait about 10 seconds for SE to come up
13) Project->Open Workspace, choose /home/setest/clanghello/clanghello.vpw
14) Debug->Start

Observe issue: "Error continuing: Could not start app for debugging"

[Dennis]

I will take a look at this, but it might have to wait until the first point release.