On Fri, Mar 28, 2008 at 04:39:31PM +0100, Guido Guenther wrote:
---
src/virterror.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/virterror.c b/src/virterror.c
index 1463129..49f3b89 100644
--- a/src/virterror.c
+++ b/src/virterror.c
@@ -115,6 +115,11 @@ virResetError(virErrorPtr err)
free(err->str1);
free(err->str2);
free(err->str3);
+ if(err->dom) {
+ if(err->dom->name)
+ free(err->dom->name);
+ free(err->dom);
+ }
memset(err, 0, sizeof(virError));
}
@@ -383,6 +388,15 @@ __virRaiseError(virConnectPtr conn, virDomainPtr dom, virNetworkPtr
net,
virResetError(to);
to->conn = conn;
to->dom = dom;
+ if (dom) {
+ if (!(to->dom = malloc(sizeof(virDomain)))) {
+ fprintf(stderr, "cannot allocate memory in %s", __FUNCTION__);
+ } else {
+ to->dom->name = strdup(dom->name);
+ memcpy (to->dom->uuid, dom->uuid, VIR_UUID_BUFLEN);
+ to->dom->id = dom->id;
+ }
+ }
to->net = net;
to->domain = domain;
to->code = code;
What problem are you trying to solve?
The 'conn', 'dom' and 'net' fields in a virterror can't be
accessed
safely, particularly from a garbage-collected language. The only safe
thing one could do with them is a physical equality test on the
pointer against an existing conn/dom/net pointer.
But the solution isn't to copy the dom object, since in a GC-d
language someone could grab a handle to the copied dom which would
have a different lifetime from the error object. If anything the
solution would be to remove those fields from the error object since
they are highly unlikely to be useful in any real world application.
We can't do this because of backwards compatibility promises but we
should instead deprecate them.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat
http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top