[User-mode-linux-devel] More info on misterious coredump

[Yuri P. <yu...@sw...>]

I figured out how to locate the exact place of coredump.

Then I run newly compiled uml-linux-2.3.99-pre2,  it dumps core
in memcpy at user_utils.c:156, after the first crearte_vm_file() call.

The mistery is that both src and dst addresses for memcpy,
as well as size seems to be reasonably correct.
mmap() to dst is also successed.
However memcpy call did not return, resulted in segfault.

Here is a gdb session:

Breakpoint 6, remap_data (perms=0x1015ef53 "rw-") at user_util.c:156
156           memcpy(addr, (void *) start, size);
1: x/i $eip  0x10084fa1 <remap_data+165>:       mov    0xfffffff4(%ebp),%eax
(gdb) list
151           data = create_vm_file(size);
152           if((addr = mmap(NULL, size, PROT_WRITE, MAP_SHARED, data, 0)) < 0){
153             perror("mapping new data segment");
154             exit(1);
155           }
156           memcpy(addr, (void *) start, size);
157           if(munmap((void *) start, size) < 0){
158             perror("unmapping old data segment");
159             exit(1);
160           }
(gdb) p data
$24 = 10
(gdb) p/x addr
$25 = 0x40000000
(gdb) p/x size
$26 = 0x97000
(gdb) p/x start
$27 = 0x100d0000
(gdb) p/x 618496
$28 = 0x97000
(gdb) p ((char*)addr)[0]
$29 = 0 '\000'
(gdb) p ((char*)addr)[size-1]
$30 = 0 '\000'
(gdb) p ((char*)start)[size-1]
$31 = 0 '\000'
(gdb) p ((char*)start)[0]
$32 = 0 '\000'
(gdb) p $esp
$33 = (void *) 0xbffff754
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x1008ebf9 in memcpy ()
1: x/i $eip  0x1008ebf9 <memcpy+41>:    mov    0x1c(%edi),%edx
(gdb) p/x $edi
$35 = 0x40001000

And the most interesting observation:
the exact address at which program segfaulted depends on
my print manipulations from gdb.
I.e. if I do print ((char*)addr[0], it segfaulted at addr+0x1000,
if I do touch also addr[0x1000], it segfaulted at addr+0x2000.
In case I did not print at all, I got segfault @ 0x400000000.

Got the point?

FYI: I use 2.2.15-pre15 as a host kernel (with ptrace() syscall-overwrite patch).

Will continue my efforts tomorrow, please help me with advise
if you have some explanations.