[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Segfault in event-test.c example



2010/1/10  <pspreadborough comcast net>:
>
> ----- "Matthias Bolte" <matthias bolte googlemail com> wrote:
>
>> 2010/1/10  <pspreadborough 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 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
>> event-test.
>>
>> Matthias
>
> Matthias,
>
> priv->domainEvents is NULL, here's the gdb output:

This explains the segfault. The next question is, why is it NULL?

> (gdb) p *priv
> $1 = {lock = {lock = {__data = {__lock = 1, __count = 0, __owner = 21806, __kind = 0, __nusers = 1, {__spins = 0, __list = {
>            __next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000.U\000\000\000\000\000\000\001\000\000\000\000\000\000",
>      __align = 1}}, sock = 150469168, watch = 3, pid = 4, uses_tls = 1982791681, is_secure = 1815048801, session = 0x782f6269,

Seeing uses_tls and is_secure being large numbers and knowing that
both are used as boolean values in the code and should have values of
0 or 1 make me think that priv points to already freed memory here.

>  type = 0x2f646e65 <Address 0x2f646e65 out of bounds>, counter = 1684956536, localUses = 1668248365,
>  hostname = 0x74656b <Address 0x74656b out of bounds>, debugLog = 0x0, saslconn = 0x0, saslDecoded = 0x0, saslDecodedLength = 0,

type and hostname are char pointers, but the seem to point into
nowhere, confirms that this is either freed memory or priv itself got
overwritten due to heap corruption.

>  saslDecodedOffset = 0, saslEncoded = 0x0, saslEncodedLength = 0, saslEncodedOffset = 0,
>  buffer = '\0' <repeats 68 times>, "n\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\bQ�\b����\030\034�\b\000\000\000\000�\033�\b\001\000\000\000\002\000\000\000�\033�\b\000\000\000\000\025|�\000\a", '\0' <repeats 11 times>, "X\000�\b", '\0' <repeats 12 times>, "\021\000\000\000\002\000\000\000P��\b\000\000\000\000\021", '\0' <repeats 15 times>, "\021\000\000\0008\036�\b\f\000\000\000\020\000\000\000\021\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\021\000\000\000\002\000\000\000\230\034�\b\000\000\000\000A\000\000\000\003\000\000\000\001\000\000\000\001\000"..., bufferLength = 0,
>  bufferOffset = 0, callbackList = 0x0, domainEvents = 0x0, eventFlushTimer = 0, domainEventDispatching = 1, wakeupSendFD = 0,
>  wakeupReadFD = 0, waitDispatch = 0x0, streams = 0x0}
>
> I'll try a run with valgrind and post the results.
>
> Pete
>

Could you test the Python version of this example found in
examples/domain-events/events-python/event-test.py? Does this work?

Otherwise lets see if valgrind gives any hints.

Matthias


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]