VisualGDB Build Window can't open file

[Ancaritha]

I’ve recently created a new STM32 VisualGDB project and I’m having a weird issue with the VisualGDB.  If an error occurs and I click on it in the window to bring me to it, it throws an error (see attached: Error1).  One thing I noticed is, that there are only 3 sets of “../”.  When you look at the actual error text, you’ll see that there are 4 “../”  (see attached: Error2) to get to the actual file (which is correct).  It there a limitation to how many of those VisualGDB can handle?

I do not get this on any of my other projects, but all of those were created using VisualGDB 5.4 or earlier, and later updated to 5.5, where as this is the first 5.5 project I’ve made.  Additionally, this is the first time I’ve had a project have 4 deep “../” so it could be that too (or none of the above!).

I’m running Visual Studios 2012 still.  Any thoughts?

Thanks!

 

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This would happen if the project contained manually defined path mappings that would map correct paths into incorrect ones.

Please try resetting mappings via VisualGDB Project Properties -> Path Mapping.

If it doesn’t help, please try reproducing the problem on a project created from scratch. You can simulate the build output by overriding the build command with “cmd /c type $(ProjectDir)\log.txt” where log.txt is a text file containing the previously captured log.

[Ancaritha]

So this was a new project that I started from scratch.  My VisualGDB Path mappings are empty, so not really sure what I’m supposed to be resetting.  I’ve never used them before.

While writing out this email and running various tests I have concluded that the depth of “../” doesn’t matter.  I have also concluded that this is happening on our legacy projects, I just didn’t notice it because the most likely way to trigger it is to forget to include a file and trigger an undefined reference error.  Since all the legacy projects are already set up, I wasn’t seeing the issue, but as I was loading our various framework files into the new solutions I would inevitable miss one and trigger this error.

When opening a fresh instance of Visual Studios and hitting this error for the first time, Visual Studios pops up with an error saying “An exception has been encountered.  This may be caused by an extension.”.  It then directs me to the activity log, which I have included.

In the log file I’ve included, you can see at the very end that it’s trying to find “FirestormBootTask.cpp” but it’s looking under C:\Program Files rather than the project root…?

[Ancaritha]

OK well, it didn’t upload because XML files aren’t allowed, so here’s what I believe to be the relevant entry:

 

<entry>
<record>387</record>
<time>2021/08/17 22:07:25.568</time>
<type>Error</type>
<source>Editor or Editor Extension</source>
<description>System.IO.DirectoryNotFoundException: Could not find a part of the path &apos;C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Code\FirestormBootTask.cpp&apos;.
 
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
 at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
 at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
 at System.IO.File.InternalReadAllBytes(String path, Boolean checkHost)
 at k02.o2(String a)
 at cf1.f6(String a)
 at cf1.p4(hp1 a)
 at pp2..ctor(IVsTextLines a, al1 d, g13 c, g b)
 at al1.w(IVsTextLines a, Boolean b)
 at al1.GetColorizer(IVsTextLines a)
 at Microsoft.VisualStudio.Package.LanguageService.GetColorizer(IVsTextLines buffer, IVsColorizer&amp; result)
 at Microsoft.VisualStudio.Editor.Implementation.LanguageServiceClassificationTagger.TryCreateTagger(ITextBuffer textBuffer, IVsFontsAndColorsInformationService fontAndColorInformation, Int32 longBufferLineThreshold, LanguageServiceClassificationTagger&amp; classifier)
 at Microsoft.VisualStudio.Editor.Implementation.LanguageServiceClassificationTaggerProvider.CreateTagger[T](ITextBuffer buffer)
 at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.GatherTaggers(ITextBuffer textBuffer)</description>
</entry>

[support]

No problem. If the problem can be reliably reproduced on a cleanly created project, please try packing it into a .zip file and attaching it here so that we could try to reproduce it on our side.

[Ancaritha]

Ok, figure out how to break it.  Note, I am using VS 2012 and VisualGDB 5.5R5.

I have two copies of the same start up code I generated above.  In one of them, the solution and Visual Studios project are in the main folder, and /code and /BSP is underneath it.  In the other one, the top level folder has a /BSP, /Code and /Solution folder.  That one breaks.

The max upload size is 512KB and the entire folder is about 3MB zipped.  If you want I can upload everything except the BSP folder, that should fit.

To reproduce yourself:

Visual Studios -> New Embedded Project
GNU Make -> Advanced settings
STM32H743II
Execute from: Flash
Floating Point: Hardware
Newlib-Nano
Minimal (no semihosting)
LEDBlink (HAL)
GDB path style: Use toolchain default

After project is created:
VisualGDB Properties-> Convert to stand-alone project
– Choose “Copy all BSP files to project directory”
– Remove all “Additional Sources”

Apply Changes.  Save All and Close Visual Studios.
Go to Windows Explorer.
Browse to project folder and create a new ‘Solution’ folder alongside the BSP folder.
Move VS project and VisualGDB files into new solutions folder.
Create another folder called Code.  Move the Test.cpp file there (or whatever you named your project that contains the int main)

Open VS project.  Remove all existing BSP .c files and re-add them so they get the new, correct path (don’t forget the start_stm32h743xx.c)
Open VisualGDB properties and correct ‘Include directories’ to be relative path instead of an incorrect absolute path
Add the relative path to “..\Code”

 

Now you should be in position to break things!  You need to create a header file and modify int main() to call something in it.

int main(void)
{
	HAL_Init();

	TestObj* obj = new TestObj();
	
	for (;;)
	{
		obj->Inc();
	}
}

This was my header file

#ifndef __TEST_OBJ_H__
#define __TEST_OBJ_H__

class TestObj 
{
public:

TestObj();

void Inc();

private:
int m_nTest;
};

#endif

That should cause you to throw an undefined reference error which will throw the Visual Studios error when you click on it.  I’d like to note that before I created the /Code folder and the main.cpp was in the same folder as the project, it didn’t break.  It was only after I moved the .cpp into the separate /code folder that things break.

After I got this in a broken state, I opened the solution using Visual Studios 2019, which did NOT have VisualGDB installed for it.  While the normal output window isn’t quite as advanced, it basically did what was expected and didn’t throw any errors.  I then installed VisualGDB for VS2019 and used the VisualGDB output window and it broke.

[support]

Thanks for the detailed repro steps. We have tried reproducing it on our side, and got the “../” paths in the build log, however clicking on them worked as expected.

Please try updating to VisualGDB 5.6 Beta 4. If the problem  persists, please try attaching a .zip archive with the faulty project so that we could recheck it on our side.

Also, as a side note, moving the project like this would break the connection to the BSP folder, and might interfere with some of the functionality (although not the build log navigation).  A much easier way to accomplish it would be to already create a project in a subdirectory (e.g. c:\projects\name\Solution) and use “..\BSP” instead of “BSP” when converting it to a stand-alone one.

Also, please consider switching to the Advanced CMake Project Subsystem. It is designed to specifically address the shortcomings of GNU Make and MSBuild, and generally works much better, while allowing you to build the projects outside VisualGDB as well.

[Ancaritha]

I’ve attached two projects, one of them works and the other one breaks.  I did have to remove the BSP folder from the rar file as it put it over the 500KB limit.

In our real builds, we don’t actually use the BSP folder.  When creating it as a stand-alone we remove all references to the BSP files rather than copying them over.  We then reference the STM32 frameworks directly.  The folder structure is also defined before I start doing anything with files, I just did it this way to try and track down the exact point that it breaks.

Yea, I’d love to move over to using the CMake system but we have a lot of infrastructure built around makefiles as they are.  For the time being its a necessary pain but I hope to get free time in the future to upgrade our support tools to support CMake…

Once you take a look at these project files I’ll play around with the 5.6 beta.

Thanks!

[Ancaritha]

Trying again except as .zip files…

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Unless the project contains all the necessary files so that we could build it and observe the same behavior as you have, it’s hard to suggest anything specific.

Please try updating to VisualGDB 5.6 Beta 4. If the problem persists, please try uploading the entire project to a file sharing service (e.g. Dropbox/OneDrive) and posting the link here.

[Ancaritha]

I put them up on my google drive.

Broken: https://drive.google.com/file/d/1R3ggILujlAv-eyjpK-MRLWH4d0Ym7lLd/view?usp=sharing

Working: https://drive.google.com/file/d/1oyRoaibynUWN2I1H489s4j3x2tl8G2_0/view?usp=sharing

I’ll check out the beta later today

[Author]

Posts