[CRIU] Re: sometimes we get coredump on zombie00
Cyrill Gorcunov
gorcunov at openvz.org
Tue Jan 31 03:47:27 EST 2012
On Tue, Jan 31, 2012 at 12:45:09PM +0400, Cyrill Gorcunov wrote:
> Hi guys,
>
> it seems we sometimes are getting core-dump for various
> tests, which are hard to repeat. Meanwhile I've got one
> and here is an output
>
> [root at neptune static]# gdb ../../../../crtools ./core.16438
> Reading symbols from /home/crtools/crtools...done.
>
> warning: core file may not match specified executable file.
> [New Thread 16438]
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> Core was generated by `./zombie00 --pidfile zombie00.pid --outfile zombie00.out'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x0000000000401088 in ?? ()
> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.25.el6.x86_64
> (gdb) bt
> #0 0x0000000000401088 in ?? ()
> #1 0x0000000100004033 in ?? ()
> #2 0x0000403400000000 in ?? ()
> #3 0x0000000300000001 in ?? ()
> #4 0x0000000000004035 in ?? ()
> #5 0x0000000000000009 in ?? ()
> #6 0x0000000b00000000 in ?? ()
> #7 0x000000383b40fb68 in ?? ()
> #8 0x0000000000402100 in write_img_buf (fd=Cannot access memory at address 0xffffffffffffffef) at ./include/util.h:132
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> investigating...
>
0xffffffffffffffef is -EAGAIN, which means -- it seems it came from parasite
code...
Cyrill
More information about the CRIU
mailing list