[wilstark]

I have a related issue where I see the same failure, but the reproduction is different.  I installed 5.5.7.3685 (still VS2017), and enabled the diagnostics console.

The reproduction is to load the .sln with the .vgdbcmake project. Then run the shortcut that copies files.  SysprogsSync is set up.  It works. Then, reboot the target machine. Once it comes back up. Re-run the shortcut. It fails. See attached log vgdb_dump1.txt.   I then try testing the SSH connection to my target, which works, and re-run the shortcut.  It fails in the same way.  I then unload/reload the .vgdbcmake project in my .sln, and re-run the shortcut. It works (log in vgdb_dump2.txt). That log shows some similar failures, but the shortcut reports success in the GUI and it does work

Hopefully this can help identify why rebooting the target breaks the copying shortcut until one reloads the visual gdb project.

Attachments:

You must be logged in to view attached files.

[wilstark]

sshd is pretty recent.

root@ff:/tmp# sshd –version
OpenSSH_7.9p1, OpenSSL 1.1.1g 21 Apr 2020

I was able to run:

$ ssh root@ff “ln -s /usr/lib/mytargetname.so.1.2 /tmp/mylinkname.so”

successfully from a MINGW64 bash shell against the target machine.  So… sshd seems OK with ssh command mode. Not sure why VisualGDB’s ssh client cannot do the same?

I can verify that an executable shell script /tmp/test can be run with a shortcut

Command: /tmp/test

Directory: /tmp

and it successfully runs the script that creates the link.

Thanks.

[wilstark]

I went through the manual SysprogsSync setup process since I was getting prompted about that – apparently with the directory deploys. After setting that up, so far no issues. Fingers crossed.  Not sure why *not* setting that up was causing this issue, though.

[wilstark]

Yep. Thanks. Bad source path for the .so copy.

[wilstark]

Build 3009 works better, but now the deploy of my managed exe doesn’t seem to work, failing with a LIBSSH2_ERROR_SCP_PROTOCOL error.

The output window shows:

VisualGDB: Executing predebug actions
VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1
VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1
VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so
VisualGDB: Executing postdebug actions
VisualGDB: Executing predebug actions
VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1
VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1
VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so
VisualGDB: Executing postdebug actions
VisualGDB: Executing predebug actions
VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1
VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1
VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so
VisualGDB: Executing postdebug actionse output window shows:

Not sure why SSH would not work for these pre-debug copy actions.  I can delete the directory on the Linux VM, and VGDB will automatically replace the files for the synchronized directory, so it clearly has SSH access.

Any suggestions?

[wilstark]

Also, with your updated build, if I do try to debug by right-clicking the mono target -> Debug -> Start new instance, I get an error (attachment) that references the “Visual GDB Launcher output” window, but that window is not there (attachment).  I have seen this type of error previously, and there was a window with actual output before.  Some somehow it is not hooked up in this build for for this particular error.  (this is using the 3006 and 3008 builds)

• This reply was modified 5 years, 1 month ago by wilstark.
• This reply was modified 5 years, 1 month ago by wilstark.

Attachments:

You must be logged in to view attached files.

[wilstark]

I installed your updated version, and then followed steps 1 and 2.  At step 3, the VS project properties for my /usr/bin/mono solution tree node that was added in step 1 (under the .vgdbcmake project node) does not have any properties in it (attached).

I think this is the properties box you mean… I don’t see anyplace else to put in command line arguments…

• This reply was modified 5 years, 1 month ago by wilstark.

Attachments:

You must be logged in to view attached files.

[wilstark]

A bit more detail… My “test” setup has a single VisualGDB (.vgdbcmake) “project” that has a native EXE and native .so being built by VisualGDB.  The solution has a managed C# EXE project as well that I want to use as the test-harness for the .so.  The native EXE is just there as a test to be sure I can do all-native debugging of my .so (this works great).

I did finally get this to work by doing the following:

• using custom debug steps (before launching debugger) to
  • copy my managed EXE to my Linux Target
  • copy my native .so to the same directory
• Set the debug settings to:
  • Use mono as the debugged executable.
  • Sets the managed EXE as the argument (at the location I copied it to)

Then I have to right-click on the .so node in the .vgdbcmake project and choose Debug-> Start New Instance. Then I get a message that says “The project debug settings are not configured to debug the startup or selected target.  Do you want to fix the debug settings? (Yes/No)” If you say ‘yes’ here, my settings above are overwritten .  So “No”.  Then I see: “The project debug settings are not configured to inherit the per-target working directory/program arguments specified via VS Properties.  Do you want to fix the debug settings? (Yes/No).  Again, “No” for the same reason.

Then it does start up and hit my breakpoint in the .so.

But… this is a bit of a painful startup procedure!

If I remove the native EXE (as VisualGDB seems to really want to use that as the startup EXE), then when I do the Debug->Start New Instance on the .so, I see: “No startup target defined for CMake project. Please define a startup target by right-clicking on it. (“OK”). And then nothing.

[wilstark]

Well, your system did not permit the .vgdbcmake file attachment, so I’ll try again.

Attachments:

You must be logged in to view attached files.

[wilstark]

OK, it appears that you don’t need Visual Assist to cause the problem.  I uninstalled and it still crashes.

Turning off ‘Start Hook Debugging’ had no effect.

Changing to local source (Windows and not Linux) appears to NOT show the problem. So perhaps it is related to ssh paths then?

Attached is the callstack and debugger output when I reproduce (CMake project with sources stored on Linux).  I can reproduce the issue by creating a new project (as described above), or adding an existing .vgdbcmake project to the solution with my C# project.

I’ll also attach my .vgdbcmake file.  Let me know if I can provide more information.

 

Attachments:

You must be logged in to view attached files.

[wilstark]

Another update.  This crash does occur even when VisualAssist is disabled.   (Make sure the C# project’s properties actually gets opened the 2nd time.  After creating the VisualGDB project, close the C# project’s properties if it was already open, then re-open it to show the crash.)  I note that when the VisualGDB project is created, a debugger attached to the Visual Studio instance prints out a lot of information that might indicate an issue.  Not sure.

'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\WINDOWS\assembly\GAC\EnvDTE90\9.0.0.0__b03f5f7f11d50a3a\EnvDTE90.dll'. Module was built without symbols.
'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'Microsoft.GeneratedCode'.
'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'Microsoft.GeneratedCode'.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00EF8274.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00EF5694.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

• This reply was modified 5 years, 1 month ago by wilstark.

[wilstark]

I’m pursuing your solution #2. Ultimately, this has a VS solution that houses my C# projects and a VisualGDB project. It looks like there might be a bug in VisualGDB that crashes VS in this setup.

Here’s one way I can reproduce:

Using VS2017 (15.8.6) and VisualGDB (5.4R2 build 2753)
File -> New -> Project -> … -> Visual C# -> Windows Desktop -> Windows Forms App.

… finish the wizard… choose project properties. See the properties. No crash. All good.

Right-click the solution -> Add -> New Project -> VisualGDB -> Linux Project Wizard
Application
CMake
GNU Make
Advanced CMake Project Subsystem checked.
“Next”
Build project over network (uses my configured Linux box, all good here)
“Next”
Store files on the remote machine (default, recommended)
“Finish”

Right-click the C# project, choose properties (as before). Crash VS.

**** UPDATE ****

Crash information in debug session implicates VisualAssist (it is further down in the call stack), and disabling VisualAssist resolves the issue.

• This reply was modified 5 years, 1 month ago by wilstark. Reason: Updated information

[wilstark]

Thanks for the detailed description!

Re: suggestion #2, step #2: Is it possible to script the CMake project import / .vgdbcmake project?

(Ideally, I could automatically/programmatically generate a complete functioning Visual Studio solution with C# and the .vgdbcmake projects from a source code workspace that has only my CMake files.)

[Author]

Posts