Passing a NULL pointer to IMachine::delete virtualbox API causes VBoxSVC to raise an assertion. This patch passes an empty array instead. --- src/vbox/vbox_tmpl.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index 68e3b05..be25828 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -5294,7 +5294,8 @@ vboxDomainUndefineFlags(virDomainPtr dom, unsigned int flags) ((IMachine_Delete)machine->vtbl->Delete)(machine, &safeArray, &progress); # else - machine->vtbl->Delete(machine, 0, NULL, &progress); + vboxArray array = VBOX_ARRAY_INITIALIZER; + machine->vtbl->Delete(machine, 0, (IMedium**)&array, &progress); # endif

Am 20. April 2012 01:36 schrieb Eric Blake <eblake(a)redhat.com&gt;: > Commit 78345c68 makes at least gcc 4.1.2 on RHEL 5 complain: > > cc1: warnings being treated as errors > In file included from vbox/vbox_V4_0.c:13: > vbox/vbox_tmpl.c: In function 'vboxDomainUndefineFlags': > vbox/vbox_tmpl.c:5298: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] > > * src/vbox/vbox_tmpl.c (vboxDomainUndefineFlags): Use union to > avoid compiler warning. > --- > > Pushing this under the build-breaker rule. > >  src/vbox/vbox_tmpl.c |    7 +++++-- >  1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c > index be25828..57c18a4 100644 > --- a/src/vbox/vbox_tmpl.c > +++ b/src/vbox/vbox_tmpl.c > @@ -5294,8 +5294,11 @@ vboxDomainUndefineFlags(virDomainPtr dom, unsigned int flags) > >         ((IMachine_Delete)machine->vtbl->Delete)(machine, &safeArray, &progress); >  # else > -        vboxArray array = VBOX_ARRAY_INITIALIZER; > -        machine->vtbl->Delete(machine, 0, (IMedium**)&array, &progress); > +        union { > +            vboxArray array; > +            IMedium *medium; > +        } u = { .array = VBOX_ARRAY_INITIALIZER }; > +        machine->vtbl->Delete(machine, 0, &u.medium, &progress); >  # endif >         if (progress != NULL) { >             progress->vtbl->WaitForCompletion(progress, -1); Actually, NACK. As stated in the other mail, vboxArray is not castable to IMedium*. True, it silences the compiler any might even work by accident on XPCOM because VirtualBox might not touch the pointer beyond checking it for being non-NULL because the 0 tells it that it's an empty array. But still this is wrong and might crash on MSCOM. I might come up with a proper solution tomorrow.

Am 20. April 2012 01:07 schrieb Eric Blake <eblake(a)redhat.com&gt;: > On 04/17/2012 10:50 AM, Eric Blake wrote: >> On 04/13/2012 07:04 AM, Jean-Baptiste Rouault wrote: >>> Passing a NULL pointer to IMachine::delete virtualbox API >>> causes VBoxSVC to raise an assertion. This patch passes >>> an empty array instead. >>> --- >>>  src/vbox/vbox_tmpl.c |    3 ++- >>>  1 files changed, 2 insertions(+), 1 deletions(-) >>> >>> diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c >>> index 68e3b05..be25828 100644 >>> --- a/src/vbox/vbox_tmpl.c >>> +++ b/src/vbox/vbox_tmpl.c >>> @@ -5294,7 +5294,8 @@ vboxDomainUndefineFlags(virDomainPtr dom, unsigned int flags) >>> >>>          ((IMachine_Delete)machine->vtbl->Delete)(machine, &safeArray, &progress); >>>  # else >>> -        machine->vtbl->Delete(machine, 0, NULL, &progress); >>> +        vboxArray array = VBOX_ARRAY_INITIALIZER; >>> +        machine->vtbl->Delete(machine, 0, (IMedium**)&array, &progress); >>>  # endif >> >> ACK and Pushed. Actually, this is not how vboxArray is supposed to be used. vboxArray is a wrapper with specific implementations for MSCOM and XPCOM. You cannot just cast it to a VirtualBox API type. > Phooey.  Now I'm getting compile failure: > > cc1: warnings being treated as errors > In file included from vbox/vbox_V4_0.c:13: > vbox/vbox_tmpl.c: In function 'vboxDomainUndefineFlags': > vbox/vbox_tmpl.c:5298: warning: dereferencing type-punned pointer will > break strict-aliasing rules [-Wstrict-aliasing] I think we need a new vboxArrayPass/Set function to get this right. I might have time to take care of this tomorrow, if nobody fixed it before then.