Qemu terminating with SIGABRT
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again.
Thanks,
Signature · 1 line
David Ahern
Quoted 4 lines · David S. Ahern
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again.
My experience with abort() was with code calling qemu_malloc(0). (*) Not sure if this is the problem that you are seing, but this is as good guess as anyother one.
Later, Juan.
(*): Please, not atother qemu_malloc(0) flame, please.
Quoted 5 lines · David S. Ahern
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again.
There's pretty much nothing we can do without a core.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 7 lines · David S. Ahern
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again.
Thanks,
Look for "abort" in QEMU's code to see the possible reasons.
In many cases, the reason will be printed to stderr before aborting. Did you call QEMU from a console and get some output there? Or maybe the stderr output went into a file?
Run "ulimit -c unlimited" before you run QEMU, then a core file will be written automatically on SIGABRT.
Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT.
David Ahern
Quoted 18 lines · Stefan Weil
Quoted 7 lines · David S. Ahern
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again.
Thanks,
Look for "abort" in QEMU's code to see the possible reasons.
In many cases, the reason will be printed to stderr before aborting. Did you call QEMU from a console and get some output there? Or maybe the stderr output went into a file?
Run "ulimit -c unlimited" before you run QEMU, then a core file will be written automatically on SIGABRT.
Quoted 4 lines · On Sat, 12 Dec 2009 11:09:38 -0700 "David S. Ahern" <[email protected]> wrote:
Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT.
Are you using qemu-kvm or upstream qemu? Which version? Don't you
have any procedure which would make the bug more likely to happen?
Thanks.
I'm using a variant of the KVM source from RHEL5 plus a few cherry-picked patches. Host OS is RHEL 5.3. The servers are using E5540 or E5504 processors. The host OS is running from a small USB key, and there is no place to write a core file. Other accommodations have to be made to get it. Hopefully by the end of the week I can get make to reproducing the abort and capturing a core.
David Ahern
Quoted 12 lines · Luiz Capitulino
Quoted 4 lines · On Sat, 12 Dec 2009 11:09:38 -0700 "David S. Ahern" <[email protected]> wrote:
Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT.
Are you using qemu-kvm or upstream qemu? Which version? Don't you
have any procedure which would make the bug more likely to happen?Thanks.
Quoted 7 lines · David S. Ahern
I still have not been able to capture a core, but I did get this from stderr:
unhandled vm exit:
0x31vcpu_id3
This was fixed by 083e9e10dd9.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 10 lines · Luiz Capitulino
Quoted 8 lines
Quoted 4 lines · On Sat, 12 Dec 2009 11:09:38 -0700 "David S. Ahern" <[email protected]> wrote:
Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT.
Quoted 4 lines
Quoted 4 lines
Are you using qemu-kvm or upstream qemu? Which version? Don't you
have any procedure which would make the bug more likely to happen?Thanks.
I still have not been able to capture a core, but I did get this from stderr:
unhandled vm exit: 0x31 vcpu_id 3
ax 0000000000000000 rbx 00000000c0109120 rcx 0000000000000000 rdx 00000000c9ee2000
rsi 00000000c9ee2000 rdi 00000000c9ee2000 rsp 00000000c9ee3fb0 rbp 00000000c0109120
r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000
r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
rip 00000000c0109149 rflags 00000246
cs 0060 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0068 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0068 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0068 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0070 (c0433300/000000eb p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0078 (fff5c000/00000027 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt c0384300/ff
idt c0436000/7ff
cr0 8005003b cr2 ad2f77a0 cr3 36e72440 cr4 6f0 cr8 0 efer 800
David