Re: [Pyvix-discuss] Anything I should know about pyvix before using it for serious work?

[David R. <dav...@ya...>]

>> I mentioned that once I started writing multiple testcases, I
>> found the python process crashed.
>> I have slimmed down the code to a three-line script that always
>> causes python.exe to crash:
>> ----------
>> import pyvix.vix
>> host = pyvix.vix.Host(hostName="192.168.0.139", username="admin",
>> password="secret")
>> host = pyvix.vix.Host(hostName="192.168.0.139", username="admin",
>> password="secret")
>> ----------
>> 
>> I'm not expecting help to debug my code, but I thought you might be
>> interested in what may well be a newbie mistake of mine (or perhaps
a
>> bug in VMware's code) that cases python to crash -- if only to add
it
>> to your docs as a "trap for beginners".
>
> When I get a chance (hopefully tonight or tomorrow night), I will
take
> a look at the operations that pyvix performs in response to your
> example code, and see whether the crash is due to a bug in pyvix or
in
> VMWare.  Even if it's due to a bug in VMWare, perhaps I can add a 
> workaround.

I finally had time to investigate the problem.

I found that the crash occurs in the second call to VixHost_Disconnect.
 VixHost_Connect returns the same handle value when the client program
connects multiple times to the same VM from the same client process.

The destructor of the Host class automatically invokes the close()
method of the object being released, if the programmer has not already
done so explicitly.  Adding explicit close() calls did not change the
behavior of the sample code for me (and theoretically, it should not).

The VixHost_Connect/VixHost_Disconnect pairs in pyvix are written just
as the VIX API Reference Guide recommends (or at least, as I understand
it to recommend).  The VIX implementation is supposed to
reference-count the handles, and to do so in a thread-safe way
(thread-safety is not an issue in this trivial sample code, but I
mention it to make it clear that I considered the issue when writing
pyvix).

---

I think there are two possibilities:
  1) There might an internal resource-tracking bug in the VIX API
implementation due to an assumption that a single client process will
open at most one handle to the same host at the same time.  All of the
sample code that I could find opens at most one handle to the same
host.  However, no such limitation is documented (as far I understand,
having freshly read the VIX API documentation).

  2) The behavior mentioned above is not a bug, but a deliberate
limitation.  But if it's a "deliberate limitation", why would it be
implemented in such a way as to cause low-level memory corruption in
the client process when the client programmer violates it?  Most of the
rest of the VIX API is (at least documented as being) resilient in the
face of abuse by the client programmer, so why would that sound policy
suddenly be suspended in this case?

---

Since my past interactions with VMWare give me no hope of their
responding promptly to bug reports, perhaps the best way to explore
this issue is to compile the Perl VIX wrapper and try to connect
multiple times to the same host via that wrapper.  If the program
segfaults, then we can be pretty sure that the behavior we've observed
is due to a bug in the VIX implementation.  If it raises an error, or
"just works", then I guess the behavior is as designed, and I'll modify
pyvix to keep track of the process-wide number of Host objects that
point to the same host, and not to call VixHost_Disconnect on any
handle to that host until the last Host object is closing.  (Of course
I would implement that tracking in a thread-safe way.)

You mentioned that you have some experience with Perl, so if you have a
Win32 Perl installation and a suitable Microsoft Visual C++
installation, I'd appreciate it if you'd perform that experiment
yourself and report the results.  Note that when I speak of "the Perl
VIX wrapper", I'm talking about the code that resides in "Program
Files\VMware\VMware VIX\vix-perl.zip", *not* in "Program
Files\VMware\VMware VmPerl Scripting API".  The latter Perl API is
implemented on top of an older control library, not VIX.

If you're not able to test the Perl wrapper, I'll try to get around to
it sometime this week.  I have both Visual C++ 6 and 7.1, and can
download Perl for Win32 (the Perl interpreters included with VMWare
don't seem to include the infrastructure necessary to compile XS
modules, so they can't generate the necessary makefile via the "perl
Makefile.PL" command, as the documentation recommends).


 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com