VIX1.7 glib-2.0 crash against Server 2

[fixitchris]

Calling the below code multiple times in a row causes an exception. Can anyone verify this?

Private Sub TestConnect()
	Dim _host As New VMWareVirtualHost
        _host.ConnectToVMWareVIServer(New Uri("https://172.16.2.5:8333/sdk", "user", "pass", 30)
        _host.Disconnect()
        _host = Nothing
End Sub

Tested against vmware Server 2 // version=2.0.0, build=build-122956 using VMwareTasks 1.3 over VIX 1.7

I tested against 4 different Server 2.0.0 hosts with similar results.

[fixitchris]

Same result w/o vmwaretasks lib:

        Dim m_lib As New VixLib
        Dim m_hostJob As VixCOM.IJob = Nothing

        m_hostJob = m_lib.Connect( _
                        VixCOM.Constants.VIX_API_VERSION, _
                        VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_VI_SERVER, _
                          New System.Uri(txtconnString.Text).ToString(), _
                           0, _
                           txtUser.Text, _
                           txtPass.Text, _
                           0, _
                           Nothing, _
                           Nothing)

        Dim m_propertyIds() As Integer = {VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE}
        Dim m_results() As Object = Nothing
        Dim m_vixError As ULong
        m_vixError = m_hostJob.Wait(m_propertyIds, m_results)

        Dim m_hostHandle As VixCOM.IHost = Nothing

        If m_vixError = VixCOM.Constants.VIX_OK Then
            m_hostHandle = CType(m_results(0), VixCOM.IHost)
        End If

        If m_lib.ErrorIndicatesFailure(m_vixError) Then
            Console.WriteLine("ERR: Failed to Connect to Host: " & m_lib.GetErrorText(m_vixError, Nothing))
        Else

                m_hostHandle.Disconnect()

[fixitchris]

I'm forced to go back to 1.6 to work with Server2!

[lemke · Accepted solution]

We recently found and fixed a bug here. What triggers it is doing the Connect/Disconnect very quickly, so that the Disconnect is started while we're still getting data from the server. There was some bad code dealing with throwing the late responses away. It shouldn't matter if the server is Server 2.0 or an ESX flavor. But its very dependent on timing, so its quite possible that you see it on Server 2.0 because that system is slower than your ESX boxes (esp since Server 2.0 has to share.)

If your problem vanishes with a short sleep between, then its probably the same bug.

[fixitchris]

Excellent, is an interim release available for testing?