11:01 a.m.
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
11:23 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:30 p.m.
New subject: [Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
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
6:11 p.m.
New subject: [Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
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
6:52 p.m.
New subject: [Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
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
7:23 p.m.
New subject: [Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
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
6806
days inactive
6808
days old
5 comments
3 participants
participants (3)
-
Bryan D. Payne -
Daniel Veillard -
Jim Fehlig