[libvirt] Segfault in event-test.c example

Matthias Bolte matthias.bolte at googlemail.com
Sun Jan 10 20:17:31 UTC 2010

2010/1/10  <pspreadborough at comcast.net>:
> Hello,
> I have been trying to use the domain event C code example but
> unfortunately it segfaults (signal 11) every time I run it:
> [root at Spring events-c]# ./event-test
> myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
> myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
> myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
> myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
> myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> main:322 :: Registering domain event cbs
> Segmentation fault (core dumped)
>  Core was generated by
> `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
> Program terminated with signal 11, Segmentation fault.
> [New process 21806]
> [New process 21822]
> #0  remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> remote/remote_driver.c:8720
> 8720        tempQueue.count = priv->domainEvents->count;
> (gdb) bt
> #0  remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> remote/remote_driver.c:8720
> #1  0x080490d3 in main (argc=Cannot access memory at address 0x1
> ) at event-test.c:347
> The stack looks corrupted so I'm doubtful that this trace if of much value.
> I have built
> and installed libvirt-0.7.5 and it and it's tools seem to be operating
> correctly.

I tried the event-test with libvirt-0.7.5 and QEMU/Xen and both are
working as expected. No segfaults.

Could you inspect the values of priv and priv->domainEvents in GDB
using 'p priv' to see if they are NULL and try to dereference them in
GDB using 'p *priv' to see if they point to valid memory areas?

Yes the backtrace looks corrupted. If there is stack/heap corruption
involved valgrind may reveal it, so try to run the event-test in
valgrind and see if that gives any hints.

You can also try the GIT version of libvirt. There was a invalid free
call (resulting in heap corruption) in the node device code fixed
after the 0.7.5 release. But that should have no effect on the


More information about the libvir-list mailing list