Quick Debug Fail w/ 5.4 Beta 2

[MikeGranby]

I have a VC 2017 Linux project built with Microsoft’s remote build option, rather than with VisualGDB’s own build engine. I could, under Version 5.3, debug it using Quick Debug. Since I upgraded to 5.4 Beta 2, this no longer works. Attached are a couple of screenshots and the quick debug preset that it is using. I reverted to 5.3 and debugging worked again, but that broke Intellisense and auto formatting, so that’s not a useful solution. Right now, I have to choose between debugging and editing! Help! (For what it’s worth, the 5.4 Preview Build 2632 exhibits the same debug problem.)

Attachments:

You must be logged in to view attached files.

[MikeGranby]

Since it wouldn’t let me upload the preset…

<?xml version=”1.0″?>
<QuickDebugPreset xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:xsd=”http://www.w3.org/2001/XMLSchema”&gt;
<InitialBreakpoint>main</InitialBreakpoint>
<InteractiveStartup>false</InteractiveStartup>
<Name>mCore</Name>
<Timestamp>2019-01-06T12:22:34.9732384-05:00</Timestamp>
<Settings xsi:type=”com.visualgdb.quickdebug.program”>
<RemoteHost>
<HostName>mcore-local</HostName>
<Transport>SSH</Transport>
<UserName>root</UserName>
</RemoteHost>
<ToolchainID>
<ID>linaro-gcc-7.3.1</ID>
<Version>
<GCC>7.3.1</GCC>
<GDB>(Linaro_GDB-2018.05)</GDB>
<Revision>0</Revision>
</Version>
</ToolchainID>
<DebuggedProgram>
<SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
<Command>/tmp/bin/LED_Server</Command>
<Arguments />
<WorkingDirectory />
<Environment>
<Records />
</Environment>
<BackgroundMode xsi:nil=”true” />
</DebuggedProgram>
<GenerateCtrlBreakInsteadOfCtrlC>false</GenerateCtrlBreakInsteadOfCtrlC>
<RunGDBUnderSudo>false</RunGDBUnderSudo>
<CrossSettings>
<LocalProgramCopy>J:\Monico\GcLab\Unify\bin\ARM\Debug\bin\LED_Server</LocalProgramCopy>
</CrossSettings>
</Settings>
<IsShared>false</IsShared>
</QuickDebugPreset>

• This reply was modified 5 years, 4 months ago by MikeGranby.

[support]

Hi,

Thanks for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.12.2672.msi

[MikeGranby]

That seems to fix the debug issue, but the SSH Connection Manager now won’t let me open a console. (See attached.)

Also, I don’t seem to be getting proper source code display, but let me confirm that…

 

Attachments:

You must be logged in to view attached files.

[MikeGranby]

Yep, with the build you posted, when I do debug, I get the unknown source file page every time. Under 5.3, it would correctly go to my application’s main, and then show the various breakpoints I’d set. With the posted build, the breakpoints would be hit and I could show the mixer assembly, but the pure source was never displays.

[support]

Hi,

Sorry for the delay. We have fixed the SSH console problem (and many other stability issues) in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2728.msi

Regarding the source files, please try closing the disassembly window and double-click in the call stack. Is the source shown correctly? If not, could you please attach a gdb log so that we could see what is going on?

[MikeGranby]

I tried the new release, and…

1. The SSH issue is now resolved.
2. The Intellisense issue from 5.3r8 is still resolved.
3. The original failure to debug is still resolved.
4. The source code still does not display correctly.

I tried the stack trace approach, and that did not work. Double-clicking on the “main” entry did nothing. Selecting Show Source produced the Frame Not In Module window. Selecting Show Disassembly worked, and shows the assembly with the correct interspersed source lines. Attached is the GDB log from the failing case with the latest release, and the working case with 5.3r8. A quick diff shows very little difference between the files, except a change in the order of a few commands.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for confirming this. The issue might be caused by a recent change in the VisualGDB’s behavior when it cannot compute the full path to a source file on the windows side.

In version 5.3, VisualGDB would report the original path as shown by gdb and Visual Studio would show a prompt allowing you to locate the file manually. In one of the recent VS2017 updates, Microsoft changed their logic to display an error message instead, so we updated VisualGDB to simply ignore the frames referencing non-existing files.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2733.msi

It will show the details about the frames with missing source files via View->Other Windows->VisualGDB Diagnostics Console. If you could share the output from the diagnostics console, we should be able to see what is going on and fix it.

You can also disable the new behavior via Tools->Options->VisualGDB->Common->Debug->Hide Missing Source Files.

[MikeGranby]

Turning off the ‘Hide Missing Source Files’ option does indeed fix the problem, so it looks like it’s thinking that a file is missing when in fact it is available. If I install the build you provided and have this option checked, the same failure occurs. The resulting diagnostic log is attached. It looks like it’s seeing the Linux-style path from the build machine, and not converting it to the Windows equivalent. Disabling the option still fixes the problem.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the log file. Normally, VisualGDB should have automatically downloaded the remote file to a temporary folder if it could not map the path using the regular rules.

We have added more internal logging to this logic in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2736.msi

Please try reproducing the problem and share the updated diagnostic log.

[MikeGranby]

Just to clarify: The project is a Visual Studio Cross-Platform Linux project set to build on a remote Linux machine. I’m then running it on a different machine, an embedded Linux device. So the source code won’t exist on the debug target. It’ll just be on the Windows host machine and on the Linux build machine, the latter of which won’t be visible to the debug target. Do you still want me to proceed?

[support]

Thanks for the clarification. Indeed, in this case the sources won’t be auto-downloaded as they won’t be present on the gdb machine.

As a better alternative to disabling the new behavior, please consider adding a path mapping rule via the path mappings button in the GDB Session window to link the source path reported by gdb with the actual location of the source files on the Windows machine.

[MikeGranby]

Sounds good. I guess the question is why it used to work and then stopped with 5.4?

[support]

The behavior changed because v5.3 relied on Visual Studio to ask for the path for the missing files. However a recent VS2017 update changed this to just displaying an error message. As a result, stopping the debugger in a system library that didn’t have sources available resulted in a confusing and annoying error message. Hence we updated VisualGDB to silently ignore the source paths that could not be resolved instead of reporting them “as is”. This eliminated the annoying message during regular debugging scenarios, but broke the rare scenario when the sources are not physically present on the Linux machine and not covered by the path mapping rules, but are still available and can be located manually.

We will consider adding a VisualGDB-level dialog for locating the missing sources and creating a path mapping automatically in one of the next releases. As a workaround, please add a path mapping, or use the global setting to revert to the old behavior.

[MikeGranby]

Makes sense. Thank you again for the attentive and rapid support, and for a great product!

[Author]

Posts