Skip to content
This repository was archived by the owner on Jun 5, 2019. It is now read-only.

VB debug static variable examination causes crash #212

Open
rockybooth opened this issue Jun 25, 2015 · 6 comments
Open

VB debug static variable examination causes crash #212

rockybooth opened this issue Jun 25, 2015 · 6 comments
Assignees

Comments

@rockybooth
Copy link

I have been debugging a large VB program and having lots of debug issues and decided to try to find the cause. With the following not so long program, I can crash Visual Studio (2012 or 2013) every time by simply waiting for the stop, then using the cursor to see the present value of I. Using the immediate window to find the value will also crash VB.

Local variables declared inside the sub can be explored without issue but variables passed to a sub or function also cannot be examined in that sub or function.

Similar code in C# using Static instead of Private works just peachy.

This happens with the emulator, so this is not a GHI issue, and none of their dlls are loaded.

Option Explicit On
Option Strict On

Imports Microsoft.SPOT
Imports Microsoft.VisualBasic.CompilerServices

Namespace MFConsoleApplication1

Public Module Module1
    Private I As Integer = 1

    Sub Main()

        Debug.Print(Resources.GetString(Resources.StringResources.String1))
        Stop
        Debug.Print(I.ToString)
    End Sub

End Module

End Namespace

Presumably the issue is in Microsoft.VisualBasic.dll
This occurs running
Microsoft.Spot.Native 4.3.1
mscorlib 4.3.1
Microsoft.Visualbasic 1.0.0.0 (v4.0.30319)

I hope I am posting in the right place. Also see https://www.ghielectronics.com/community/forum/topic?id=19600&page=1#msg193443
where this is discussed

@smaillet-ms
Copy link
Member

Thanks for reporting this, we'll investigate and post what we find here. Yes, this is the right place to post bugs and other discussions on the .NET Micro Framework.

@smaillet-ms smaillet-ms self-assigned this Jul 7, 2015
@lt72 lt72 added the VB.NET label Feb 16, 2016
@rockybooth
Copy link
Author

Can anyone comment on when this might be resolved or if there are workarounds?
Thanks

@smaillet-ms
Copy link
Member

Other than not using statics we don't have any workarounds yet. We're working on core runtime and porting issues first (such as a memory leak in OpenSSL)

We're more than happy to have someone look into this, if someone is interested feel free to claim this one here.

@martincalsyn
Copy link
Contributor

I have a fix for this which I will submit as a PR once I clean it up a bit. The changes are all in the CorDebug component. Basically CorDebugClass has to return an instance of CorDebugGenericType in the CorDebugClass implementation of ICorDebugClass2.GetParameterizedType. And CorDebugGenericType needs an implementation for GetStaticFieldValue. Those two changes stop the crashing and will return proper hover and watch values for VB globals.

@rockybooth
Copy link
Author

Martin: This would be great. I stub my toe on this all the time. Will this be for both 4.3 and 4.4?
Thanks,
Rocky

@martincalsyn
Copy link
Contributor

Should work for both, as the change is in the Visual Studio debugging code which is in the MicroFramework Visual Studio Extension (vsix), which is common to 4.3 and 4.4. I have built and tested it for VS2017. I haven't built vsix packages for earlier versions (yet).

martincalsyn added a commit to PervasiveDigital/netmf-interpreter that referenced this issue Sep 20, 2018
This fixes Issue NETMF#212 where VS crashes when hovering over a global var in a vb module.

The fix here is to make sure that CorDebugClass
 responds correctly to calls to
CorDebugClass.GetParameterizedType. Originally it
should have returned E_NOTIMPL, but it returned OK
and a null which is what causes the crash. This
function is supposed to return full specified types
derived from generic classes and wasn't implemented
because netmf doesn't do generics, but it also gets
called for classes with no specialization types when
trying to create a type enclosure for Vb globals.

Now, with this change, it returns a properly
specialized type definition. The constructor had to be
specialized to accommodate the fact debugger values
known the appdomain, and type specializations need
an assembly and type domain.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants