The stack trace is as follows:

Program received signal SIGABRT, Aborted.
0x00000035ad830265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00000035ad830265 in raise () from /lib64/libc.so.6
#1 0x00000035ad831d10 in abort () from /lib64/libc.so.6
#2 0x00000035ad86a84b in __libc_message () from /lib64/libc.so.6
#3 0x00000035ad8722ef in _int_free () from /lib64/libc.so.6
#4 0x00000035ad87273b in free () from /lib64/libc.so.6
#5 0x0000000000406771 in vshDeinit (ctl=0x7fffd35d35e0) at virsh.c:8244
#6 0x00000000004069a5 in vshError (ctl=0x7fffd35d35e0, doexit=<value optimized out>, format=0x414f66 "%s") at virsh.c:7861
#7 0x00000000004067c4 in vshDeinit (ctl=0x7fffd35d35e0) at virsh.c:8248
#8 0x000000000041335e in main (argc=3, argv=0x7fffd35d3748) at virsh.c:8493

I am trying to run libvirt-0.7.1-0.1.git3ef2e05.fc12.src.rpm on RHEL5.4.

vshDeinit gets called twice, so ctl->name is freed twice.

How about this patch then?

(See attached file: 0001-Fix-possible-double-free.patch)

--
Mark

You must be the change you wish to see in the world. -- Mahatma Gandhi
Worrying is praying for that you do not wish to happen.
Inactive hide details for Chris Lalancette <clalance@redhat.com>Chris Lalancette <clalance@redhat.com>


          Chris Lalancette <clalance@redhat.com>

          09/16/2009 06:30 AM


To

Mark Hamzy/Austin/IBM@IBMUS

cc

libvir-list@redhat.com

Subject

Re: [libvirt] PATCH] Stop double free

Mark Hamzy wrote:
> diff --git a/src/virsh.c b/src/virsh.c
> index 4825f1c..5fc6c8f 100644
> --- a/src/virsh.c
> +++ b/src/virsh.c
> @@ -8201,7 +8201,7 @@ vshError(vshControl *ctl, int doexit, const char
> *format, ...)
> fputc('\n', stderr);
>
> if (doexit) {
> - if (ctl)
> + if (ctl && ctl->conn)
> vshDeinit(ctl);
> exit(EXIT_FAILURE);
> }

I don't think this patch is right.  vshDeinit() already has a check for
ctl->conn, and if you put it higher up in the call chain like this, you'll leak
the ctl->name memory and the ctrl->log_fd file descriptors.  Do you have a stack
trace with line numbers in it (i.e. debugging information)?  Also, what version
of libvirt are you using?  That might shed a bit more light on what the problem is.

--
Chris Lalancette