.NET runtime hangs upon entering (not executing!) a function with specific code in it RRS feed

  • Question

  • This looks like a .NET bug to me, but I'm still not 100 % sure whether the fault is not mine.

    Symptom: the .NET environment (not my code itself) freezes with 50 to 100 % CPU consumption when it is about to enter my function. Consider this scenario (please excuse some ugly formatting — the posting gets corrupted with each edit).

    MsgBox("About to call Foo()"

    Function Foo()
    MsgBox("Just entered Foo()" )
    '...{Actual code starts here}...

    End Function

    Only the first message box is displayed, then a hang occurs, but only under certain circumstances.
    • Compilation mode is Release with optimizations on ; when in “Debug” mode, or “Release without optimizations”, everything works fine.
    • The function being called resides in a separate .NET assembly; when application was a single-file (single-project solution), everything worked fine for years.
    • This function contains specific code in it. (Note, again, that the hang happens not while executing my code, but when the function is “post-compiled” by .NET runtime).
    That “specific code” looks like this.

     a, b, c, d As
    a = b + c + d
    'Where MyStruct is a simple 3-dimensional point or vector (X, Y, Z).

    Structure MyStruct
    Public X, Y, Z As Double
    Public Shared Operator +(ByVal op1 As MyStruct, ByVal op2 As MyStruct) As MyStruct
    Return New MyStruct(op1.X + op2.X, op1.Y + op2.Y, op1.Z + op2.Z)
    End Operator
    End Structure

    The essential thing about this is the addition statement and referencing of operands (in main function, not in operator): if only 2 operands are used with any 3rd being commented out, or if no addition is applied, everything works fine.

    For example, any of these (used separately, not at the same time) will work.
    a = b + c
    a = b + d
    a = c + d
    a = b : a = c : a = d

    But any of those would lead to a hanging.

    a = b + c : a += d
    a = b : a += c : a = d

    Very strange, isn't it?

    Let me repeat, all this worked fine for years, as long as the application remained in a single assembly. The glitch popped-out only recently, when I started to separate the modules into small projects, and only in Release mode with optimization. I could, of course, disable optimizations permanently (my project is not about performance at all), but would like to clear this confusion: maybe I'm doing something wrong that violates .NET concepts?

    My configuration is this:
    • Visual Basic 2005sp1 (.NET 2.0 assumed) with all up-to-date patches installed;
    • Windows XPsp3 and 2003sp2 as test platforms (32-bit, up-to-date).
    I probably will also test on VS2010 beta (.NET 4.0 assumed), but it seems to take years to download :), and, even if it won't show the same issue, I currently have no plans neither to upgrade the IDE nor to elevate host system requirements for my application.
    Wednesday, August 12, 2009 9:07 AM

All replies

  • This looks familiar.  There was a JIT compiler bug a while ago that behaved like this.  I'm fuzzy about the details now, I think it was present in .NET 3.5.  It was specific to having an exact number of variables/arguments, 4 was the trigger.  Update your .NET version to the latest, 3.5 SP1.

    Hans Passant.
    • Marked as answer by nobugzModerator Saturday, August 22, 2009 10:09 PM
    • Unmarked as answer by AntonSamsonov Friday, September 4, 2009 1:45 PM
    Wednesday, August 12, 2009 10:42 AM
  • Update your .NET version to the latest, 3.5 SP1.
    Thanks for your reply. As you can guess, nowadays it's hard to evade having all the .NET versions installed (for the purpose of other applications): 1.1, 2.0, 3.0 and 3.5, — all patched up to date. And I doubt that 3.5 is used for application that was designed for 2.0 when 2.0 is actually present.
    Wednesday, August 12, 2009 5:10 PM
  • That's not how .NET versioning works.
    Hans Passant.
    Wednesday, August 12, 2009 5:33 PM
  • That's not how .NET versioning works.

    Maybe you know it better… maybe not. When the application is running, it uses mscorwks.dll from %windir%\Microsoft.NET\Framework\v2.0.50727 and mscoree.dll (internally versioned 2.0.50727.3053) from %windir%\system32 .

    BTW, the latest Visual Studio 2005 update (KB971090, pretty huge and thorough) does not help either.

    Friday, September 4, 2009 2:02 PM