Sorry as this is my productionsystem i can't
> Am 10.12.2015 um 14:18 schrieb Markus Armbruster <arm...@redhat.com>:
>
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
>> * Grundmann, Christian (christian.grundm...@fabasoft.com) wrote:
>>> Hi,
>>>
>>> qemu-img-ev-2.3.0-29.1.el7.x86_64
>>> libvirt-daemon-driver-qemu-1.2.8-16.el7_1.4.x86_64
>>> qemu-kvm-ev-2.3.0-29.1.el7.x86_64
>>> qemu-kvm-common-ev-2.3.0-29.1.el7.x86_64
>>> ipxe-roms-qemu-20130517-7.gitc4bce43.el7.noarch
>>> qemu-kvm-tools-ev-2.3.0-29.1.el7.x86_64
>>>
>>>
>>> it seems pc-i440fx-rhel7.2.0 is the default for ovirt 3.6
>>>
>>> I tried using only virtio-scsi disk but the VM wont boot (not
>>> bootable device) so i used IDE for the boot disk.
>>
>> I think this seg is actually quite different - although it depends
>> where the actual corruption
>> happened - looking at the backtrace again the failing thread wasn't
>> the io thread; it
>> failed in a call from the json parser in the main thread.
>
> Yes, in a free on behalf of parser_context_free() on parser cleanup.
> Smells like memory corruption. Habe you tried reproducing under
> valgrind?
