Apparent bug in VisualGDB

[swineone]

Hello,

Today I have fixed a few bugs in our FreeRTOS embedded threads plugin, including a rather critical one which misreported the stack pointer value, leading to incorrect thread backtraces.

In the process of debugging the plugin to fix this bug, I have uncovered what appears to be a bug in VisualGDB. When double-clicking on different levels of the stack backtrace of a given thread, inside the Threads window, I noticed the value of the stack pointer never changed, which is of course impossible (at least if functions are not inline, which is not the case here). Looking at the raw gdb output screen, I noticed that when VisualGDB runs the command “stack-select-frame” in gdb, it always passes 0 as the argument, regardless of whether I’m in the leaf frame or in a higher level frame. Obviously, if I select a different frame, a different argument should be passed to it. This happens even if I disable my plugin and go with the single-threaded default threads view.

Hence I’m writing to request a fix for this issue.

Thanks in advance.

[support]

Hi,

We tried reproducing it on a basic Windows project, but could not get VisualGDB to issue wrong frame commands. Can you reproduce it with a basic MinGW-based application? Does it also happen with GDB 7.0+ (VisualGDB should use the –frame argument instead of -stack-select-frame)?

[Author]

Posts