Invalid channel after first breakpoint about lldb.nvim

[fedeDev]

I think I found what I was doing wrong. I'm using a project that uses a lot of gflags, and that relies on a bunch of environment variables to be set.

My thought was to initially have none of the environment varialbles set and no flags passed as arguments to the executable, and just watch the debugger handle my program breaking gracefully. Instead, it seems that the (expected) particular crash of the program was causing the debugger to "disconnect" from vim, or something like that. (I guess that is not expected behavior?)

Anyway, to solve this I had to pass all proper arguments to the executable and set all environment variables prior to launching nvim. For the flags, I edited the .json files and copy-pasted the flags there. If someone else has to debug an executable with a ton of flags, I recommend something like this:

{
    "variables": {
        "target": "/home/fede/path/to/binary",
        "cmdargs" : "--a=very --long=list --of=arguments"
    },
    "modes": {
        "code": {},
        "debug": {
            "setup": [
                "target create {target}",
                [ "bp", "set" ],
                "process launch -s -- {cmdargs}"
            ],
            "teardown": [
                [ "bp", "save" ],
                "target delete"
            ]
        }
    },
    "breakpoints": {
        "@ll": [
            "breakpoint set -n SomeFunctionSomewhere"
        ]
    }
}

I guess this is a fine way of doing this, but is there a way to not launch the process as soon as the debug mode is triggered (while of course having the cmdargs variable for later)? Is there a way to set environment variables from the .json file? I have a bash script that sets all the environment variables, can I execute that via the "setup" process of the .json file?

[critiqjo]

(I guess that is not expected behavior?)

Right, it's not! Either it's a bug in plugin, or a bug in lldb itself.

Can you set this environment variable while launching neovim:

NVIM_PYTHON_LOG_FILE=/tmp/nvlog nvim

then reproduce the error and report what's getting logged

Is there a way to set environment variables from the .json file?

I guess that's an easy feature to add...

I have a bash script that sets all the environment variables, can I execute that via the "setup" process of the .json file?

I was planning to add feature which will enable execution of arbitrary shell scripts. But then I found this:

(lldb) platform shell <arbitrary script>

[critiqjo]

Btw, you cannot set environment variables using platform shell command.
You've to do env <var>=<value>. You can just list all such commands in a separate file and do:

(lldb) command source <file-name>

[fedeDev]

I tried to reproduce the error, and apparently it happens regardless of the environment variables or the flags that get set. It can be reliably reproduced with the binary I'm debugging if I tell the .json file to break at main (breakpoint -n main). If I remove that or if I set the breakpoint in another file, everything works. Here is the log

2016-04-04 01:08:00,846 [INFO @ controller.py:run:274] 3317 - Calling handle with ['load', 'lldb-nvim.json']
2016-04-04 01:08:10,682 [INFO @ controller.py:run:274] 3317 - Calling handle with ['load', '/home/fede/redwood_ws/RedwoodInternal/lldb-nvim-desktop-vio.json']
2016-04-04 01:08:13,411 [INFO @ controller.py:run:274] 3317 - Calling mode_setup with ['debug']
2016-04-04 01:08:19,515 [INFO @ vim_buffers.py:update_pc:64] 3317 - Got pc loc: (1, '/home/fede/redwood_ws/RedwoodInternal/Redwood/applications/desktop/desktop-vio/main.cc', 25)
2016-04-04 01:08:19,550 [INFO @ vim_buffers.py:update_pc:64] 3317 - Got pc loc: (1, '/home/fede/redwood_ws/RedwoodInternal/Redwood/applications/desktop/desktop-vio/main.cc', 25)

[critiqjo]

I'm not sure what's happening, but it looks like the debugger process is segfaulting. You can check 2 things:

1. Try this in standalone lldb and see if it segfaults.
2. If not, then check whether a new core dump file is created when it is reproduced from the plugin. If yes, then there was a segfault and it's an lldb bug.

[fedeDev]

I tried both. Standalone lldb doesn't segfault, however when running from the plugin and I inspect /var/log/apport.log I see:

ERROR: apport (pid 3830) Mon Apr  4 17:13:32 2016: called for pid 3366, signal 11, core limit 0
ERROR: apport (pid 3830) Mon Apr  4 17:13:32 2016: executable: /usr/bin/python2.7 (command line "python2 -c import\ sys;\ sys.path.remove("");\ import\ neovim;\ neovim.start_host() /home/fede/.config/nvim/plugged/lldb.nvim/rplugin/python/lldb_nvim")
ERROR: apport (pid 3830) Mon Apr  4 17:13:32 2016: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 3830) Mon Apr  4 17:13:32 2016: this executable already crashed 2 times, ignoring

This is probably why I get the E475: Invalid argument: Channel doesn't exist errors whenever I try to use the plugin again.

[critiqjo]

So, it is segfaulting... I have faced similar issues -- appearing only when using the python API. Even though LLDB development is very active, the python API is not given much heed IMO. You could try filing a bug report, I'm not so hopeful of getting it fixed. 😞

If you're filing a bug-report, include the core file as well as steps to reproduce from a python console. You can find all the commands executed from the log buffer. To execute arbitrary commands from python console, follow these steps:

import lldb
dbg = lldb.SBDebugger.Create()
ci = dbg.GetCommandInterpreter()
res = lldb.SBCommandReturnObject()
ci.HandleCommand("target create /bin/ls", res)
#res.GetOutput() if res.Succeeded() else res.GetError()

I'm not sure if you can disclose your source file or not, there might be some information about the source file in the generated core file. If you can find a short example where the segfault can be reproduced, then great -- include that file as well.

[fedeDev]

I see...thanks a lot for the support.

I cannot disclose the source nor any dump files that it might produce ... can I simply "backup" your Bug report to LLVM so that it might get more attention?

[critiqjo]

can I simply "backup" your Bug report to LLVM so that it might get more attention?

No, I don't think there's such an option! 😄 Besides, it's a different issue from this one.

[fedeDev]

OK. It seems that this is not an issue with lldb.nvim so I'm closing this. Thanks again!