[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