AV: assert from Glib + crash in a C# environment

[dblock]

Using 1.6.2 and an ESX VM. There's something very wrong caused by a RevertToSnapshot + Disconnect call. I can reproduce this 100%. Maybe I can have symbols for vix.dll or a developer can contact me? - Thx

gvmomi.dll!036c58ba()

http://Frames below may be incorrect and/or missing, no symbols loaded for gvmomi.dll

gobject-2.0.dll!0368718c()

glib-2.0.dll!035cb0d8()

glib-2.0.dll!035cb44e()

gobject-2.0.dll!03684f7f()

gobject-2.0.dll!03687926()

vix.dll!1114a888()

vix.dll!11119135()

vix.dll!11119150()

vix.dll!111070ab()

vix.dll!111079ca()

vix.dll!1110394d()

vix.dll!1115f23f()

vix.dll!1115f950()

vix.dll!11165353()

vix.dll!11154a79()

vix.dll!111540a3()

vix.dll!11153db5()

vix.dll!11165353()

vix.dll!11165277()

vix.dll!11102678()

vix.dll!11165353()

vix.dll!11154a79()

vix.dll!1115fa93()

vix.dll!1110198d()

vix.dll!11191380()

kernel32.dll!7c80b683()

[admin]

Hi, could you mention the full sequence of steps? Are you making and maintaining multiple connections by any chance?

Thanks!

[dblock]

I am not. It's very simple to reproduce. I wrote a repro in pure VixCOM API, no other libraries. In a loop: connect to a host, open a VM, get the root snapshot, revert to it, disconnect, force garbage collection. Attached is the repro program. The second loop crashes on my machine. If you don't force GC, obviously the crash won't happen for a while, but eventually the garbage collection will catch up with you and you'll get a random acess violation some time later.

Note that without reverting to the snapshot there's no crash.

Hope this helps.

[admin]

Very helpful, thanks.

[admin]

Hello,

If you are not already doing so, can you please test this by calling connect and disconnect in a seperate function from the rest of the loop?

For Example:

foo(...)

{

Connect(...);

for (...) {

InnerLoop(...);

}

Disconnect(...);

}

InnerLoop(...);

{

//All the other operations

}

If this does not work, could you also place the revert to snapshot call in its own function as well? Let me know if either of these approaches solves your issue.

[zcoolmatz]

I have a C# Vix Wrapper too and I got an error (attached file). I use VixCOM 1.6.2.2190 with ESX server 3.5 and Visual Studio 2005.

I have it each time that I connect and list the VM machines ( .... .vmx|http://storage 2] .... .vmx]. I'm not sure if there's another way to reproduce it... Just before I update to the 1.6.2 API, I used the VMServer 2.0 Vix API (I think it's 1.6.3(?), but I know that 1.5 work for near everything except "Capture screenshot").

If you need more info, tell me.

Thx

[admin]

Hello zcoolmatz,

Can you verify for me that your wrapper properly calls Disconnect? The error you are encountering is often associated with failing to call Disconnect.

Thank you,

Joe

[zcoolmatz]

Hi JK,

Thx alot, I forgot to disconnect after that listing. Everything seems work now.

Thank you,

Matt

[dblock]

None of the suggestions work around the problem: the bug on top of the loop is very real.

[admin]

Thank you for your response. Can you try one other thing for me? I was able to solve the issue on my own system with the solution I posted before provided I added GC.Collect(); GC.WaitForPendingFinalizers(); inside the foo loop after the call to innerLoop.

i.e

foo(...)

{

Connect(...);

for (...) {

innerLoop();

GC.Collect();

GC.WaitForPendingFinalizers();

}

Disconnect();

}

Please let me know if this solves the issue for you. Thank you.

[dblock]

Yep, this works. Explicitly releasing the objects and garbage-collecting works around the problem. Code attached. It's still a bug, forcing GC at opportunistic places isn't going to fly for a very long time.

[admin]

I am glad to hear the proposed solution works for you. I agree that it is not ideal for .Net development. We are investigating the issue and hope to implement a more elegant solution for a later release of VIX. We'll be sure to consider your feedback. In the meantime, I hope this solution allows you to keep working with the VIX API and take full advantage of its potential

[fixitchris]

dblock, have you found a permanent solution to this issue? I am running into a similar issue on one Linux guest with your c# wrapper. Please see my post 'vmware server 2.0 backup (win)' ;toward the end... I narrowed it down to the PowerOn method, more specifically Waitfortoolsinguest. The guest OS does have tools installed but they do not start up. I am curious why this method does not just time out and continue ... any ideas?

[dblock]

The code I have in SVN or the latest build of VMWareTasks that GCs and nulls the right things at the right time definitely worked around the problem for me. Never tried on Linux though.

[fixitchris]

my issue was unrelated to this post and is solved. (programmer error)

[marteleras]

I have the same issue. But, in my case, it isn't related to RevertToSnapshot command. My application crashes right after the host connection been established. Specifically in the OpenVM command. I tried to use the workaround solution posted without success. In fact, the application often works in the first loop, but the next one crashes everytime.

Any thoughts?

BTW, I'm running under ESX 3.5 Update 3 with VIX 1.6.2

[marteleras]

If it helps... This is the log from Dr Watson...

--> State Dump for Thread Id 0xcec <--

eax=00000000 ebx=02ebf6f0 ecx=00000007 edx=00000001 esi=027628d8 edi=01b0bce0

eip=01eae5d0 esp=02ebf6f0 ebp=02ebf794 iopl=0 nv up ei pl zr na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246

• ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\VMware\VMware VIX\VIServer-2.0.0\32bit\glib-2.0.dll -

function: glib_2_0!g_win32_locale_filename_from_utf8

01eae5b4 f7d1 not ecx

01eae5b6 fe0f dec byte ptr

01eae5b8 af scasd

01eae5b9 c689459ceb248b mov byte ptr ,0x8b

01eae5c0 57 push edi

01eae5c1 28c1 sub cl,al

01eae5c3 e204 loop glib_2_0!g_win32_locale_filename_from_utf8+0x1a59 (01eae5c9)

01eae5c5 8b443208 mov eax,[edxesi0x8]

01eae5c9 8d5001 lea edx,[eax+0x1]

01eae5cc 8d642400 lea esp,[esp]

FAULT ->01eae5d0 8a08 mov cl,[eax] ds:0023:00000000=??

01eae5d2 83c001 add eax,0x1

01eae5d5 84c9 test cl,cl

01eae5d7 75f7 jnz glib_2_0!g_win32_locale_filename_from_utf8+0x1a60 (01eae5d0)

01eae5d9 2bc2 sub eax,edx

01eae5db eb09 jmp glib_2_0!g_win32_locale_filename_from_utf8+0x1a76 (01eae5e6)

01eae5dd ff15bc01eb01 call dword ptr

01eae5e3 8b459c mov eax,[ebp-0x64]

01eae5e6 8b4db4 mov ecx,[ebp-0x4c]

01eae5e9 3bc1 cmp eax,ecx

01eae5eb 7302 jnb glib_2_0!g_win32_locale_filename_from_utf8+0x1a7f (01eae5ef)

Regards..

[dblock]

I wish someone from VMWare would say something about this. There hasn't been an update since 1.6.2 except "yep, it's a bug, ttyl".

Looking at your call stack I think you might be in the same scenario as I got stuck in. The GC.Collect() workaround doesn't solve the threading problem with more than one connection at a time. If you aren't making more than one connection at a time, then make sure to disconnect explicitly, de-reference all objects and then GC.Collect(), GC.WaitForPendingFinalizers(). Use VMWareTasks, it's worth the switch since it does the proper disposing work for you. If you're making more than one connection at a time, you're in the same boat as my application, ie. waiting for the next release to maybe fix it.

[admin]

marteleras: Do you call OpenVM in the same function you called host connect? Also, if you could include the pertinent VIX code so I can better understand where you are encountering the issue, that would be helpful. I am unable to reproduce the assert with the workaround I provided.

dblock: I am sorry for the inconvenience. We are currently looking into the issue and do intend to fix it in a later release of Vix.

[dblock]

jkovacic: thanks, please also make sure to pass on to the developers my repro in , that's a different stack in the crash from this one. Thx.