| Summary: | qemu-kvm core dumps when being killed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Xiaoqing Wei <xwei> | ||||
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.3 | CC: | acathrow, areis, bsarathy, juzhang, michen, mkenneth, shuang, tburke, virt-maint | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-04-12 10:24:02 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Xiaoqing Wei
2012-02-17 10:29:33 UTC
Created attachment 563879 [details]
gdb thread apply all bt full
"killing" qemu means sending SIGTERM here? At which point during the installation do you kill it? How did you create the image file (size, options)? (In reply to comment #3) > "killing" qemu means sending SIGTERM here? At which point during the kill -9 $qemu-pid > installation do you kill it? How did you create the image file (size, options)? I encountered once / twice manually, on starting the copy process. images created by: qemu-img create -f qcow2 xxx.qcow2 20G How can qemu-kvm abort and generate a core dump when you used SIGKILL? (In reply to comment #5) > How can qemu-kvm abort and generate a core dump when you used SIGKILL? Oops, maybe is SIGTERM / kill -15. I found that can be reproduced sometimes when install guest by autotest, and then ctrl+c to end the autotest process, that might pass -15 to qemu-kvm instead of -9. This may be related to bug 798857. Can you please try if the following scratch build fixes the problem? https://brewweb.devel.redhat.com/taskinfo?taskID=4281327 (In reply to comment #7) > This may be related to bug 798857. > > Can you please try if the following scratch build fixes the problem? > https://brewweb.devel.redhat.com/taskinfo?taskID=4281327 Sure, will update then. (In reply to comment #7) > This may be related to bug 798857. > > Can you please try if the following scratch build fixes the problem? > https://brewweb.devel.redhat.com/taskinfo?taskID=4281327 still able to reproduce with qemu-kvm-0.12.1.2-2.272.el6.kwolf_drain_on_close_3.x86_64, 1) but this time I am using kill -6, 2) tried 10+ installation killed with ctrl-C didn't reproduce. btw, I re-check the attachment gdb output of this bug, seems it was killed by signal 6 when reporting, sorry for incorrect info in comment 6. Signal 6 is SIGABRT, a core dump is expected there. What shouldn't happen is corrupted images. Do you still get messages like "ERROR cluster 40041 refcount=1 reference=6" in qemu-img check? Oh, and in the original case the SIGABRT is not what you did. I believe you really did a SIGTERM and qemu tried to shut down in response. It's just that during the shutdown something went wrong (an assertion failed) and qemu called abort(), which uses SIGABRT internally. (In reply to comment #10) > Signal 6 is SIGABRT, a core dump is expected there. > > What shouldn't happen is corrupted images. Do you still get messages like > "ERROR cluster 40041 refcount=1 reference=6" in qemu-img check? is shows "Leaked clusters were noticed during image check. No data integrity problem was found though." this time. Thanks for testing. It seems to be fixed by this patch then. *** This bug has been marked as a duplicate of bug 798857 *** |