Exception <class 'ImportError'> raised while loading Voltron: No module named 'plugin'

[mobiphil]

Hi,

just spent last 2-3 days in implementing a python server inside gdb, with some external views that can be started in different terminals (register, stack etc.). And accidentally bumped into this project! Briliant!!!!

just that... did not manage to make it working... got the error above.

default python is the same version for gdb and the one found in path (both are 3.4)

thanks in advance for your help

[mobiphil]

in the file /usr/local/lib/python3.4/dist-packages/voltron-0.1-py3.4.egg/dbgentry.py I also noticed that there is a syntax error? except Exception, e: msg = "Exception {} raised while loading Voltron: {}".format(type(e), str(e)) if blessed: msg = blessed.Terminal().bold_red(msg) print(msg)

which I corrected to except Exception as e: msg = "Exception {} raised while loading Voltron: {}".format(type(e), str(e)) if blessed: msg = blessed.Terminal().bold_red(msg) print(msg)

[mobiphil]

maybe this helps:

->python Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.

import voltron Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.4/dist-packages/voltron-0.1-py3.4.egg/voltron/init.py", line 8, in import plugin ImportError: No module named 'plugin'

[snare]

Edit: deleted terrible previous suggestion...

Oh wait that's not going to work.

Maybe just try changing the:

import plugin

To:

from . import plugin

[snare]

Scratch that, try fbd5e6a0b6a2057fb3e9939ec50c226060e8d81a

[mobiphil]

thanks for the quick answer. Does not work, see below

Hint: ubuntu seems to come with gdb linked with python 3.4. Lot of people use that I assume, so not bad idea to keep 3.4 working. Happy to test and use... I am looking for such a tool for ages... Don't be upset if I come with proposals ;)

have new error

Exception <class 'ImportError'> raised while loading Voltron: No module named 'pygments'

[snare]

I actually just fixed that in the setup.py in the previous commit. Just pip install pygments.

[snare]

Yeah I've had some issues with Ubuntu's "oh we're gonna keep python 2 as the default but we're gonna install python 3 as well and link GDB against it because REASONS" thing before.

https://github.com/snare/voltron/wiki/Voltron-on-Ubuntu-14.04-with-GDB

[mobiphil]

ahh ok.. ... now python 3.4 problems are comming out...

raised while loading Voltron: No module named 'StringIO'

[snare]

I definitely welcome suggestions and PRs! I wrote a blog post recently about writing new view plugins, that might be useful for you :)

[snare]

Ahh ok, if you feel like fixing the other Python 3 issues just send me a PR. Otherwise I'll spin up a VM later and give it a go.

[mobiphil]

Do you think this issue on StringIO is difficult to fix?

[mobiphil]

PR: here? never did that

[snare]

BTW I intend to write another blog post soon (I kinda started it) on writing backend plugins as well which might be helpful

[snare]

StringIO has been renamed in Python 3 IIRC

[snare]

https://docs.python.org/3.0/whatsnew/3.0.html

Search for StringIO.

[snare]

Oh you know what? Looks like that import is redundant, just remove the whole import StringIO

[mobiphil]

I know.. that is why I am asking you... does not make too much sense for me to hunt for ways for this mini-refactoring, if it is easy for you to fix.

[snare]

Yeah, I removed it and will push it out in a sec (just running tests)

[mobiphil]

great!

[snare]

OK, try 6cb4168e335ad243a6f78f159a1750f798e1f06d

[mobiphil]

Exception <class 'AttributeError'> raised while loading Voltron: 'NoneType' object has no attribute 'adaptor_class'

[snare]

OK, I'm gonna spin up a VM and see if I can repro it

[mobiphil]

BTW: you say another thing: I tried to install lib64readline6-dev, but it seems that it messed up a bit the apt db as the version you suggest is needed for multilib environment. I think you better suggest libreadline6-dev

but do not think you

[mobiphil]

BTW: the radare2 mention your frontend, that is how I arrived there... I was checking their status on the affairs

http://rada.re/gsoc/

[snare]

Ah cool :) I've talked to pancake before about it hehe.

OK, thanks for the suggestion. I'll add that to the wiki entry.

[snare]

I've reproduced the problem you're seeing and am investigating now.

[mobiphil]

Well, was impatient and built gdb with 2.7. Already discovered two bugs, maybe you are aware:

-> once the debugged process terminates, the view processes will not reconnect until you restart the debugger. -> colors do not work? what do I miss? I have TERM=xterm on xterm

Further about the tool: I have the impression of a deja-vu. As mentioned, started to develop almost the same thing 2 days ago, after fighting with failed approaches with the mi interface. Did not look at the source code, what I did implemented a simple tcp server loop inside gdb python which was executing commands comming from the socket, returning the result to the socket + sending udp messages to different local ports one containing the result of "info stack" next "bt" and so one.. Was opening then a netcat udp listener on each port.

Will have a look at the source code. While I was implementing my versions following ideas were coming into my mind, will list them in the increasing level of complexity. I work with C++ builds that contain heavy symbols. One of the problems with gdb is that things like "info functions" is terribly slow (often takes several minutes on a fast workstation). So what I need (or C++ programmers need) a way to replace things like symbol list, and why not dwarf info extraction/caching...

1. symbol extraction from executable and shared libraries for faster function name completion
2. create automatic symbol alieses for C++ demangled names for better visibility, like:

MyClass< blahbla < balh> >::MyClass() . Such names often became 5 line long, this could be reduce to MyClass< @alias1 > or MyClass< blahblah< @alias2 > >

with other words reduction of nested templates at different level.

1. this is already next generation thing ;) ... crete a simple web server that will display in a more fancy way data using html/json/jscript

[mobiphil]

registers view does not work

Failed getting registers: Exception getting registers from debugger: Couldn't get extended state status: No such process.

[snare]

Great idea on the C++ stuff. Voltron actually already has an embedded web server and you can make the same API requests via the web. See the examples dir.

Re: the view not reconnecting, that's definitely a bug. It works fine on OS X.

Re: colours, I'm not sure why this isn't working :\

I've found the problem with Python 3 and I'm trying to sort out a suitable fix at the moment.

[snare]

I haven't documented the web view shiz yet, but if you ln -s /path/to/voltron/examples/angularview ~/.voltron/plugins/ and enable the HTTP service in your config (see default.cfg) that's probably a good starting point.

[mobiphil]

colors: the only view that has colors is stack... (voltron view stack)

[mobiphil]

changed the default.cfg to

"server": {
    "listen": {
        "domain":   true,
        "tcp":      ["127.0.0.1", 4444],
        "http":     ["127.0.0.1", 5555]
    }
},

Internal Server Error

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

[snare]

You can override config in ~/.voltron/config.

Just add:

{
    "server": {
        "listen": {
            "tcp":      ["127.0.0.1", 4445],
            "http":     ["127.0.0.1", 5557]
        }
    }
}

Or whatever.

Also, if you enable debug logging:

    "general": {
        "debug_logging": true
    },

You'll get some log files in ~/.voltron/ - voltron_main.log for the views and voltron_debugger.log for the debugger implant. The latter will probably have errors indicating what's going on with the webserver.

[snare]

Fixing Python 3 is going to be a bigger project I think. I've fixed a few things but more are popping up. I'll take a look at it over the weekend.

[mobiphil]

Don't worry... well.. had a look at your blog and your architecture, please allow me to make some comments:

1. your views seem to contain logic, my approach was to keep the views as dumb terminals that receive ASCII text and display it (including control caracters). None one is necessarily better, the difference is when you want to switch the views without wanting to quit the command terminal. Such instructions could be very comfortable:

set view1="bt" set view2="register" set view3="info locals"

where all what we would know about view1 is that is is either a tcp/udp port or a "/dev/pts/12". Working with tty id is the simplest to implement, but difficult to move arround.

1. putting too much logic on the gdb python may compromise the gdb session. I managed to crash few times gdb while starting different views.
2. implementing things like caching symbols (the stuff was proposing earlier) etc, I think the best is to have a standalone process that would also feed the views, will communicate with gdb and eventually have some other tasks.
3. don't know if you are using vim but viewing the source code in vim and issuing commands from vim would be the greatest thing to close the loop. There are some plugins for debugging for vim, but they are lacking what we exactly want to do here.

[snare]

1. I prefer the way I've implemented it as it means clients (views) can do a lot more than just display the output of a debugger command. I can think of a reasonably easy way to implement being able to change views from the debugger end without changing the architecture, might be worth looking at at some point.
2. I've had a few problems recently with GDB crashing, but it's always with GDB Python API functions at fault, and there's not really a way around that. I primarily use this with LLDB, and honestly I consider GDB support "legacy" for my own use, so I haven't been too concerned about it.
3. That's basically how the views work now. They send API requests to retrieve data and then Do Stuff with them. Would be easy to add symbol methods to the API via user plugins.
4. I'm not, but it would be pretty easy to add support to VIM assuming it's easy to integrate python code. Basically what's described in the blog post is all you'd have to do. You could use the command API request to do most things.

[mobiphil]

I prefer the way I've implemented it as it means clients (views) can do a lot more than just display the output of a debugger command. I can think of a reasonably easy way to implement being able to change views from the debugger end without changing the architecture, might be worth looking at at some point.

fair enough, the control process could send a command to the view process to change the view

I've had a few problems recently with GDB crashing, but it's always with GDB Python API functions at fault, and there's not really a way around that. I primarily use this with LLDB, and honest consider GDB support "legacy" for my own use, so I haven't been too concerned about it.

could be there is a problem with the development branch I built. I wish I could use LLDB, but recently I am debugging some boost.coroutine and boost.asio. LLDB does not seem to cope with coroutines. Are you sure that your gdb api <-> json api is not causing any crash?

That's basically how the views work now. They send API requests to retrieve data and then Do Stuff with them. Would be easy to add symbol methods to the API via user plugins.

I spent some time today, to find the best python elf api. Do you have any experience with any of them?

I'm not, but it would be pretty easy to add support to VIM assuming it's easy to integrate python code. Basically what's described in the blog post is all you'd have to do. You could use the command API request to do most things.

which part of the api would you use to extract source code information from different stack frames?

[snare]

I've never had the API stuff cause issues on LLDB and it's the same code. There's no way it should ever cause the debugger host to crash without something going horribly wrong in the debugger host itself.

No idea about Python ELF stuff.

The stack frame stuff isn't done yet, but I did start looking at it for LLDB the other day so GDB will follow when I have more time.

[mobiphil]

I observed another problem: once I start the inferior, the original gdb start other like 15 gdb child process. Is that really necessary?

[snare]

That's either not Voltron, or a bug.

[mobiphil]

bug where? I remove voltron from ".gdbinit" and it behaves normally. BTW. tried my simple plugin that just open a socket and https://github.com/longld/peda , they both go along with a single process.

What is also strange that ctrl-d does not leave gdb, it stays with terminal frozen

[snare]

A bug in Voltron I mean. Again, it's fine on OS X, so I don't know. I'll look into it later.

[snare]

It certainly does not intentionally spin off additional processes.

[snare]

Nor does that happen on Ubuntu 14.04 with the default GDB.

[mobiphil]

I am sure you don't start it intentionally. But do not understand: how can you run it under ubuntu 14.04 default debugger when it comes with python 3.0 and voltron does just not work under python 3.0?

[snare]

Because I've fixed the one problem that stops it from loading inside GDB under Python 3. There are still other problems with the client side, but the debugger implant loads.

[snare]

I've not pushed it out yet because there's not much point yet.

[mobiphil]

well, that clarifies that we were not talking about the same thing. I cannot judge something that is not in my hand. When I was mentioning the same debugger was the custom I built from latest git, one that does not create problems (well. multiple gdb children) with other scripts though. Let me know once you are ready, I will be happy to test.

[snare]

Fixed most of the stuff with Python 3 last night. I'll push out an updated version soon, just got a few more things to address.

[mobiphil]

how is it going? Another observation: did not really understand the difference between the reason for distinction between tcp and http communication. If you use json in context of sockets, would be IMHO much better to go for a simplified API simple json over http (only) something like defined under http://jsonrpc.org/historical/json-rpc-over-http.html#http-header. This should work also over *IX domain sockets.