Bug 1044838
| Summary: | Facing the segmentation fault when destroying the VM. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Dharmalingam <cooldharma06> | ||||
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | unspecified | CC: | acathrow, cooldharma06, mprivozn, raistlin | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Other | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-12-20 08:51:12 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dharmalingam
2013-12-19 05:17:48 UTC
Created attachment 838763 [details]
Log file
logs which logged during the process.
(In reply to Dharmalingam from comment #0) > Continuing. > [New Thread 0x7f8170682700 (LWP 18504)] > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > Not very useful, is it? You have to issue a 'bt' command in gdb, to print the stack trace and have at least a hint of where the problem is originating. Notice that, in order to such stacktrace to be useful, you need debugging symbols, do you have them (from the above, it seems to me that you don't)? BTW, `virsh destroy' works for me, using both libvirt and xen git tip. Dario (In reply to Dario Faggioli from comment #2) > (In reply to Dharmalingam from comment #0) > > Continuing. > > [New Thread 0x7f8170682700 (LWP 18504)] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0000000000000000 in ?? () > > > Not very useful, is it? > > You have to issue a 'bt' command in gdb, to print the stack trace and have > at least a hint of where the problem is originating. > > Notice that, in order to such stacktrace to be useful, you need debugging > symbols, do you have them (from the above, it seems to me that you don't)? > > BTW, `virsh destroy' works for me, using both libvirt and xen git tip. > > Dario ____ I am newbie to this gdb debugging. now i did the bt in the debugging. In my side still it showing the error. Following are the stacktrace which i got. Kindly refer the following logs for full information: **** [New Thread 0x7f8503695700 (LWP 20012)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f84f671281e in libxl_osevent_occurred_timeout (ctx=<optimized out>, for_libxl=0x7f8503bbbc38) at libxl_event.c:1039 #2 0x00007f84f69439c7 in libxlDomainObjTimerCallback (timer=<optimized out>, timer_info=0x7f8503bb5930) at libxl/libxl_domain.c:216 #3 0x00007f8502ba6f7d in virEventPollDispatchTimeouts () at util/vireventpoll.c:451 #4 virEventPollRunOnce () at util/vireventpoll.c:644 #5 0x00007f8502ba570b in virEventRunDefaultImpl () at util/virevent.c:274 #6 0x00007f8502cda065 in virNetServerRun (srv=0x7f8503ba6ba0) at rpc/virnetserver.c:1112 #7 0x00007f85036c251c in main (argc=<optimized out>, argv=<optimized out>) at libvirtd.c:1513 (gdb) ****** regards, cooldharma06. Dharmalingam, if you're building from git, it should be fairly simple to get debug symbols. Just run: export CFLAGS="-O0 -ggdb3" git clean -fxd; ./autogen.sh --system && make After this, you have debug symbols in libvirt (not the underlying libraries though). After this, you should be able to reproduce, and in the 'bt' command in gdb you should not see the <optimized out> but real pointers. Moreover, you can produce a coredump (a file which will help developers to see what's going on) you can issue "generate-core-file" command in the gdb console. It will produce a file which you should be able to attach to this bug. As per the discussion in the libvir mailing list, this behavior is due to the fact that Xen 4.2.1 (which is what is used) is lacking the following bugfixes: libxl: fix stale timeout event callback race libxl: fix stale fd event callback race Which are both present in the Xen branch stable-4.2, and hence in Xen 4.2.3, as commits: 6f0f339dd4378d062a211969f45cd23af12bf386 a87ef897295ec17788e41e9a8f4c0ada7a5a45f8 See here: http://bugs.xenproject.org/xen/mid/%3C21170.56484.749112.480737@mariner.uk.xensource.com%3E I think this can be considered enough for closing this bug. thanks to all people. :) its working in new version of xen-4.3.1 and libvirt-1.2.0. and once again thanks to all who are guided me.. **** regards, cooldharma06 (In reply to Dario Faggioli from comment #5) > As per the discussion in the libvir mailing list, this behavior is due to > the fact that Xen 4.2.1 (which is what is used) is lacking the following > bugfixes: > libxl: fix stale timeout event callback race > libxl: fix stale fd event callback race > > Which are both present in the Xen branch stable-4.2, and hence in Xen 4.2.3, > as commits: > 6f0f339dd4378d062a211969f45cd23af12bf386 > a87ef897295ec17788e41e9a8f4c0ada7a5a45f8 > > See here: > http://bugs.xenproject.org/xen/mid/%3C21170.56484.749112.480737@mariner.uk. > xensource.com%3E > > I think this can be considered enough for closing this bug. |