Quick Debug Fail w/ 5.4 Beta 2

Sysprogs forums Forums VisualGDB Quick Debug Fail w/ 5.4 Beta 2

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #23283
    MikeGranby
    Participant

    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.
    #23286
    MikeGranby
    Participant

    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, 10 months ago by MikeGranby.
    #23289
    support
    Keymaster

    Hi,

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

    #23300
    MikeGranby
    Participant

    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.
    #23302
    MikeGranby
    Participant

    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.

    #23374
    support
    Keymaster

    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?

    #23386
    MikeGranby
    Participant

    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.
    #23410
    support
    Keymaster

    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.

    #23415
    MikeGranby
    Participant

    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.
    #23419
    support
    Keymaster

    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.

    #23420
    MikeGranby
    Participant

    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?

    #23421
    support
    Keymaster

    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.

    #23422
    MikeGranby
    Participant

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

    #23423
    support
    Keymaster

    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.

    #23424
    MikeGranby
    Participant

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

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