Debugging Raspberry Pi, almost impossible now

Sysprogs forums Forums VisualGDB Debugging Raspberry Pi, almost impossible now

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #10567
    Brian Beuken
    Participant

    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.

     

    • This topic was modified 7 years, 9 months ago by Brian Beuken.
    #10569
    support
    Keymaster

    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.

    #10570
    Brian Beuken
    Participant

     

    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)

    #10571
    Brian Beuken
    Participant

    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

     

     

    #10572
    Brian Beuken
    Participant

    A little digging found this

    http://gdb-prs.sourceware.narkive.com/a6QecxfF/bug-gdb-20143-new-arm-rpi2-debugging-top-fails-build-gdb-nrlhe3-gdb-7-7-1-dfsg-gdb-frame-c-472

     

    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?

    #10573
    support
    Keymaster

    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”.

    #10575
    Brian Beuken
    Participant

    ok, I know nothing at all about linux, can you provide an idiots guide to let me do that?

     

    #10577
    support
    Keymaster

    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.

    #10578
    Brian Beuken
    Participant

    Thank you for the link.

    I will try to follow the methods used.

     

    #10579
    Brian Beuken
    Participant

    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/gdb

    After 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.

     

     

    • This reply was modified 7 years, 9 months ago by Brian Beuken.
    #10582
    Brian Beuken
    Participant

    Sorry I meant GDB 7.7.1

     

    #10584
    Brian Beuken
    Participant

    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

     

Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.