[Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
I just updated to the latest CVS version of libvir. It looks like there's a bug in virDomainLookupByID. The behavior that I'm seeing is that the path variable is set and so the code never enters the block to find the value for name. Therefore, at the end of the function, the condition (ret->name == NULL) is true and it jumps into the error code and returns NULL. If I comment out the code that sets the path variable, things seem to work normally. Although, I presume that the idea was to extract the name from the path information... -bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org
On Mon, Apr 03, 2006 at 12:01:17PM -0400, Bryan D. Payne wrote:
I just updated to the latest CVS version of libvir. It looks like there's a bug in virDomainLookupByID. The behavior that I'm seeing is that the path variable is set and so the code never enters the block to find the value for name. Therefore, at the end of the function, the condition (ret->name == NULL) is true and it jumps into the error code and returns NULL.
If I comment out the code that sets the path variable, things seem to work normally. Although, I presume that the idea was to extract the name from the path information...
Right, that's a bug I introduced in the refactoring. Even if trivial sending a small patch (cvs diff -u) is always a good idea :-) Also see my next mail about servers, thanks, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Mon, Apr 03, 2006 at 12:01:17PM -0400, Bryan D. Payne wrote:
I just updated to the latest CVS version of libvir. It looks like there's a bug in virDomainLookupByID. The behavior that I'm seeing is that the path variable is set and so the code never enters the block to find the value for name. Therefore, at the end of the function, the condition (ret->name == NULL) is true and it jumps into the error code and returns NULL.
If I comment out the code that sets the path variable, things seem to work normally. Although, I presume that the idea was to extract the name from the path information...
Right, that's a bug I introduced in the refactoring. Even if trivial sending a small patch (cvs diff -u) is always a good idea :-)
AFAIK, name is not contained in the domain's home path. Here is a patch I have been using for virDomainLookupByID(). Regards, Jim
AFAIK, name is not contained in the domain's home path. Here is a patch I have been using for virDomainLookupByID().
Actually it is... /local/domain/<num>/name Cheers, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org
Bryan D. Payne wrote:
AFAIK, name is not contained in the domain's home path. Here is a patch I have been using for virDomainLookupByID().
Actually it is...
/local/domain/<num>/name
Ah... I'm just not seeing it included in path returned by xs_get_domain_path(), only see /local/domain/<num> Regards, Jim
I'm just not seeing it included in path returned by xs_get_domain_path(), only see /local/domain/<num>
For what it's worth, I was trying to put a patch together for this, but I kept getting memory corruption errors. I was trying to access the name through the xenstore as shown below... /* lookup is easier with the Xen store so try it first */ if (conn->xshandle != NULL) { char *namepath = NULL; path = xs_get_domain_path(conn->xshandle, (unsigned int) id); namepath = strdup(path); strcat(namepath, "/name"); name = xs_read(conn->xshandle, NULL, namepath, NULL); if (namepath) free(namepath); } /* fallback to xend API then */ if (path == NULL) { ...etc... The memory corruption error is thrown by glibc at runtime. Ironically, I tried running it through valgrind and the error went away ;-) Anyway, perhaps this will lead someone to the right solution... Unfortunately, I don't have the time right now to keep playing with it. Cheers, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org
participants (3)
-
Bryan D. Payne -
Daniel Veillard -
Jim Fehlig