Sysprogs forums › Forums › VisualGDB › "Object reference not set to an instance of an object" when opening source
Tagged: visualgdb embedded
- This topic has 6 replies, 2 voices, and was last updated 3 years, 9 months ago by Chris Shaw.
-
AuthorPosts
-
February 21, 2021 at 21:09 #29942Chris ShawParticipant
Hi,
I have a VS 2017 solution containing multiple vgdb ARM projects. Some of those projects use common source code, i.e. the file ADC.c from a folder may be used in more than one project. Where this is the case, attempting to open the source file results in the dialog box with the text “Object reference not set to an instance of an object”. The projects build correctly, and double-clicking the source to open it produces the error message but successfully ‘expands’ the file to show symbols.
Using 5.5R4
Any help appreciated.
Chris
February 21, 2021 at 21:23 #29943supportKeymasterHi,
This should normally not happen, so most likely the issue is triggered by some rare combination of settings.
Please try reproducing the problem from scratch (i.e. on a newly created set of projects) and share the steps we could follow to reproduce it on our side per our problem reporting guidelines.
Please make sure you also share the relevant screenshots and the call stack from the “details” view of the error window.
February 21, 2021 at 22:06 #29944Chris ShawParticipantI actually managed to recreate the problem quickly and simply. This time the error dialog shows “Cannot open file”, and I also saw that before. I seem to be able to switch between the two errors by closing/reopneing the solution and switching IntelliSense engine between Default (Clang) and Advanced Clang IntelliSense.
I’m using Visual Studio 2017 (15.9.33) and VisualGDB 5.4R4.
Steps to reproduce:
- In VS use File -> New -> Project
- Create a new solution and use Embedded Project Wizard.
- Choose a processor and template – in my case I used STM32L151R8-A and LED Blink.
- Add a second project to the same solution – I used the same options again with a different project name.
- In each project, remove the reference to the main .c file.
- Move the main file for the first project to the solution root – in my case this was EmbeddedProject1.c moved up one level next to the .sln file.
- In each project ‘Source Files’ filter, add a reference to the moved EmbeddedProject1.c file using ‘Add -> Existing Item’.
- Build solution.
- Try and open one of the references to EmbeddedProject1.c.
I’ve attached a zip file containing a solution according to above. The file appears to be ‘openable’ on first load, but some processing occurs soon after solution load and then it cannot be opened.
NB I’ve just tried this on another computer and it appears to be ok, so I wonder if something is messed up in my VS installation. I’ve previously cleared out my VS cache from %APPDATA%, but maybe I need to uninstall/reinstall.
Regards,
Chris
Attachments:
You must be logged in to view attached files.February 22, 2021 at 11:04 #29955supportKeymasterThanks for the detailed repro steps. We have rechecked it in 2 different environments and unfortunately could not reproduce the issue. Both following the steps you described and opening the project you attached worked as expected.
Most likely, it is indeed a VS-level bug on a specific machine (e.g. some cache or VS component is corrupt). You can try narrowing it down by creating GNU Make-based projects that do not require VisualGDB to be loaded into Visual Studio, reproducing the problem and then checking if the problem persists if you completely uninstall VisualGDB. If it still fails, the issue is definitely on the Visual Studio side.
That said, if you are planning to have any non-trivial project structure, we would advise using the new Advanced CMake Project Subsystem. It natively supports multiple targets sharing the same BSP, emulation platforms, lets VisualGDB fully control the Solution Explorer window contents, eliminating many bugs caused by Visual Studio itself.
February 22, 2021 at 15:18 #29956Chris ShawParticipantI cleared the caches and was still having the problem. After commenting before though about switching the error message by changing the IntelliSense engine, I selected the third option (Regular VC++ IntelliSense) for just one of the projects and all appears to be ok now. Both projects can open files without problem.
So I’m going to blame Clang at this point. If I get the Clang IntelliSense Diag Console window then by changing those options I can see processing and errors. I’ve removed my local .clang-format file, tried a new one but each causes the same problem. Below is a common stack trace I can see on changing options.
If you are able to help or point me at a better resource that would be appreciated.
[+0:38:36.067] Replacing VC++ language service for C:\cstemp\vgdb_test\EmbeddedProject1.c [+0:38:36.067] [0%] gftoCheckingForModifications [+0:38:36.074] [56%] gftoCheckingForModifications [+0:38:36.079] [0%] gftoBypassed [+0:38:36.084] Object reference not set to an instance of an object. while trying to hook previously open files belonging to C:\cstemp\vgdb_test\EmbeddedProject1\EmbeddedProject1.vcxproj [+0:38:36.084] Stack trace: [+0:38:36.084] at pu.v1(String b, List`1 a) [+0:38:36.084] at p3.t4(String a) [+0:38:36.084] at n02..ctor(IVsTextLines d, jw1 c, gd a, i b) [+0:38:36.084] at jw1.y2(IVsTextLines a, Boolean b) [+0:38:36.084] at jw1.CreateSource(IVsTextLines a) [+0:38:36.084] at Microsoft.VisualStudio.Package.LanguageService.GetOrCreateSource(IVsTextLines buffer) [+0:38:36.084] at Microsoft.VisualStudio.Package.LanguageService.GetCodeWindowManager(IVsCodeWindow codeWindow, IVsCodeWindowManager& mgr) [+0:38:36.084] at Microsoft.VisualStudio.Editor.Implementation.CompoundTextViewWindow.TextDocData_OnNewLanguageService(Guid& sidLangServiceID) [+0:38:36.084] at Microsoft.VisualStudio.Editor.Implementation.TextDocData.NewLanguageServiceEventHandler.Invoke(Guid& sidLangServiceID) [+0:38:36.084] at Microsoft.VisualStudio.Editor.Implementation.TextDocData.SetLanguageServiceID(Guid& guidLangService, Boolean changeContentType, Boolean sendChangedEvent) [+0:38:36.084] at Microsoft.VisualStudio.Editor.Implementation.TextDocData.SetLanguageServiceID(Guid& guidLangService) [+0:38:36.084] at jw1.n(Guid a, Guid b, ou1 c, x03 d) [+0:38:36.084] at c73.m_2(List`1 a)
- This reply was modified 3 years, 9 months ago by support. Reason: formatting
February 22, 2021 at 20:12 #29958supportKeymasterThanks for sharing the stack trace. This looks like a different error triggered by changing the “For Files Used by Multiple Projects” setting and opening a solution with 2 VisualGDB-based projects using the same file (and no non-VisualGDB projects using it). This explains why the project did not trigger the issue when we tried it with default global settings.
Please try this build, it fully resolves the issue: VisualGDB-5.6.1.4017.msi
February 22, 2021 at 20:52 #29959Chris ShawParticipantHmmm, yes it appears that I did have that setting on ‘Prefer Visual Studio IntelliSense’. And on my second environment (working fine yesterday) if I set the same option then the error starts happening there too.
I’ve installed the beta version you supplied and that does indeed seem to fix it.
Thank you very much for the assistance.
-
AuthorPosts
- You must be logged in to reply to this topic.