- This topic has 11 replies, 2 voices, and was last updated 7 years, 2 months ago by
.
-
Posts
-
I’ve noted issues before with the VisualGDB debugger on Raspberry Pi and am finding the issues becoming much much more problematic, both for me personally and a great many of my students, working on a Raspberry Pi project. I have 50 students, all using laptops. We’re using VS2013 on a few systems, and VS2015 of the majority, GNU make, building on target. (We need to maintain that build chain to demonstrate on target building)
The Units are connected with direct networking cables, laptops-> Pi, though I also use a switch at home and a direct net cable at the office. The connection is fast and shows no problems.
But the Debugger has become uselss.
Put simply even stopping at a simple breakpoint VisualGDB locks 90% of the time often even before input, the whole of Visual studio becomes unresponsive, a dialogue box is not always available to quit debugging (which in itself defeats the purpose of trying to debug), Removing the net cable to force the box does allow a break. but clearly no change to debug is given.It might occasionally return control after a wait, but every attempt to single step is a gamble, whether its going to lock up again.
I really need some serious insight into why this is happening, it reduces the effectiveness of the debugger to zero and needs to be resolved.
Hi,
VisualGDB actually provides a special timing analysis mode that helps diagnose exactly this type of issues. Please try pressing the button with the timer icon in the GDB Session window and switching it to the “All GDB interaction” mode. It will show all gdb commands that VisualGDB sends to GDB and will display the exact time each command took to get processed. This should explain what causes the delays. If not, let us know your findings and we will suggest how to speed up your debugging experience.
Ok I did that and it comes up with a list of timings but at the point of the GDB Timeout window the Session window reports and arroe at grame.c:472: internal-error: get_frame….. (I can’t scroll the window to see the rest)
A Problem internal to GDB has been detected, further debugging may prove unreliable, Quit this debugging session (y or n)
I managed to widen the window,
/home/pi/dev/gdb-7.7.1+dsf/dsb/frame.c:472: internal-error get_frame_id: Assertion ‘fi->this_id.p’ failed
A little digging found this
it would appear to be an issue with the target GDB, but I have no idea how to resolve, is there any work around or is there a way to revert to a known working version of GDB?
Hi,
The easiest workaround would be to build gdb from source directly on the Raspberry Pi and replace the original binary with the built one. Normally it should be as easy as unpacking the source package and running “./configure && make && sudo make install”.
Hi,
Sorry, troubleshooting issues specific to the open-source GNU tools unfortunately goes beyond the bounds of our product support. There are plenty of tutorials online though (e.g. this one) or we could guide you step-by-step as a part of our paid consulting services if you don’t want to spend time figuring it out yourself.
I’ve managed to work out what to do, posting here for the benefit of others who like me may not be very comfortable with linux and are having debugging hangs. The Rasbian version of GDB seems to be faulty, its also a little old at version 7.8.xxx with a specific Rasbian build.
Downloading the newer generic GDB (7.12.1) and unzipping it to a working folder was fine… then I tried to use
./configure –prefix=/usr –with-system-readline && make
however it seems the readline libs were missing so this failed.. so I installed them with, you should avoid my error, and install it before attempting the GDB build.
sudo apt-get install libreadline-dev
I repeated the configure/make process this time for a successful result (note it takes quite some time)
This does not actually seem to replace the rasbian GDB, which still reported itsself as 7.8 Rasbian, but by then copying the new built version to a more accessable directory with
sudo cp gdb/gdb /usr/local/bin/gdbAfter a reset, GDB now reports a new 7.12.1 version, not specific to Rasbian.
I don’t really know the final copy step was needed, or if a reset was all that was needed, but regardless I now have a later generic GDB in place and it seems on initial tests on a piece of code that hanged every time, to be much more stable in fact I’ve single stepped through a very complex piece of code with no problems.
Of course this may not be an ideal fix, if you need the specific Rasbian GDB, I do not know what functions it provides and may now be lost, but for the moment at least I am very happy not to be hanging the instant I trigger a breakpoint.
I will report back if I find any issues with this fix.one of my students who is better with linux, suggested a cleaner faster approach, open a terminal and try this. It compiles much faster.
wget https://ftp.gnu.org/gnu/gdb/gdb-7.12.tar.gz -P ~/Downloads/
tar vxzf ~/Downloads/gdb-7.12.tar.gz -C ~/Downloads/
sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get install libreadline-dev -y
sudo apt-get autoclean
cd ~/Downloads/gdb-7.12
./configure –prefix=/usr –with-system-readline && make -j4
sudo make -j4 -C gdb/ install
sudo shutdown -r 0
gdb –version
- You must be logged in to reply to this topic.