Ichiji001
commented
6 years ago I have this exact same issue. I'm using Ubuntu 18.04 gdb compiled with python3
Open Flowm opened 7 years ago
Ichiji001
commented
6 years ago I have this exact same issue. I'm using Ubuntu 18.04 gdb compiled with python3
snare
commented
6 years ago I'll investigate. Using post_event was actually to avoid issues related to multiple threads doing concurrent API calls, which was causing crashes in previous versions.
vitapluvia
commented
5 years ago Also having issues with Voltron a lot -- I'd love to use it, there are so many nice features and it improves the experience of gdb a ton, but it's been unusable with how many crashes come up. The main reproduction I've been seeing is when rerunning a binary, ex.:
b main, runrun => abort (core dumped)This has been on multiple gdb versions & Ubuntu versions as well.
Mithi83
commented
4 years ago I've run into this problem as well on
Reverting commit 8691b44c5977d2d3e48231c7a7274c7dfaef367e (with some educated guesses on how to fix merge conflicts) seems to work better, though I have only tried a very small executable for a short time.
@snare: Did you find any clues during your investigation?
the-exodus
commented
4 years ago Pulling the branch from @Flowm s fork everything works as long as I don't attempt to follow children on forks. I will start poking at this (I assume it's a synchronization issue), but would be good to know if @snare has found any clues first, as I'm not familiar with either GDB internals or the Voltron code base.
Mithi83
commented
4 years ago I tried fiddling around with the original code a bit and I think I found a synchronization issue there.
The decorator @post_event is supposed to synchronize access to gdb and probably does a decent job at that. It is however not properly used in all instances of access to gdb from what I can see. The API of GDBAdaptor lists many functions with multiple decorators, most in this particular order (@validate_busy, @validate_target, @post_event). Thus, the actions within the outer decorators @validate_busy and @validate_target are not synchronized. These functions come from dbg.py and internally call target_is_busy resp. target_is_valid, which in turn call self._target. The _target function comes from dbg_gdb.py and directly accesses gdb without the synchronization of the @post_event decorator, creating a potential race condition within any GDBAdaptor API function that has @validate_busy or @validate_target decorators.
For a quick test I changed all occurrences of self._target within dbg.py to self.target, which is a wrapper around the internal self._target plus the synchronization of the @post_event decorator. It seems to work at least a lot better. I'm not sure if this is a proper fix though, since I can't foresee the impact of this change on other debugger plugins. Maybe someone with more insight into the code can take it from here.
When using gdb with voltron (cd11d2f) on Debian 8, gdb will segfault (or crash with other reasons) after the first few step commands when a voltron view is attached.
Stacktrace and overall problem seems similar to #81.
Issue seems to be independent of debugged program. Basic steps:
Issue also occurs with minimal .gdbinit (only containing
source /home/vagrant/.local/lib/python2.7/site-packages/voltron/entry.py)Gdb version Debian 8:
Identical behavior can be observed with gdb + voltron on Ubuntu 16.04:
After going back to the the latest released voltron version (v1.7) everything seems to be working fine.
A git bisect of the commits after v1.7 returned the following commit introducing the issue:
As a workaround reverting the changes to voltron/plugins/debugger/dbg_gdb.py since v1.7 seems to work fine. (https://github.com/Flowm/voltron/commits/gdb-no-segv)