CRASH: seg fault during initialization with the private loader

[derekbruening]

From [email protected] on August 17, 2011 13:20:03

For several proprietary apps, with the private loader,
DR gets SIGSEGV signal while it's initializing vm areas.
It doesn't happen with -no_private_loader option. I have
tested a few non-proprietary programs, but couldn't find
one that shows similar behavior. I'll add it if I can
find one later.

The callstack, register, and disassemble information is
as follows. I obfuscated some paths.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff70eae16 in _IO_vfscanf_internal () from /-/lib64/libc.so.6
(gdb) bt
#0 0x00007ffff70eae16 in _IO_vfscanf_internal () from /-/lib64/libc.so.6
#1 0x00007ffff7103d35 in vsscanf () from /-/lib64/libc.so.6
#2 0x00000000711e4371 in our_sscanf (str=0x7158c120 "00400000-00605000 r-xp 00000000 fc:01 18875407", ' ' <repeats 27 times>, "/-/tool",
fmt=0x7131dbe0 "%016lx-%016lx %s %016lx %*s %lu %4096s") at /-/dynamorio/core/io.c:657
#3 0x000000007128c640 in maps_iterator_next (iter=0x7fffffffd620) at /-/dynamorio/core/linux/os.c:6554
#4 0x000000007128dd21 in find_executable_vm_areas () at /-/dynamorio/core/linux/os.c:7307
#5 0x00000000711a8359 in vm_areas_init () at /-/dynamorio/core/vmareas.c:1615
#6 0x0000000071082926 in dynamorio_app_init () at /-/dynamorio/core/dynamo.c:582
#7 0x00007ffff7bd3b02 in _init () at /-/dynamorio/core/linux/preload.c:186

(gdb) info reg
rax 0xffffffffffffef60 -4256
rbx 0x7fffffffd370 140737488343920
rcx 0x7fffffffd4a0 140737488344224
rdx 0x7fffffffd4a0 140737488344224
rsi 0x7131dbe0 1899092960
rdi 0x7fffffffd370 140737488343920
rbp 0x7fffffffd360 0x7fffffffd360
rsp 0x7fffffffcfd0 0x7fffffffcfd0 r8 0x0 0 r9 0x7fffffffd638 140737488344632 r10 0x7158c120 1901642016 r11 0x246 582 r12 0x7131dbe0 1899092960 r13 0x7158c120 1901642016 r14 0x7fffffffdd38 140737488346424 r15 0x2 2
rip 0x7ffff70eae16 0x7ffff70eae16 <_IO_vfscanf_internal+54>
eflags 0x10202 [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x63 99
gs 0x6b 107

(gdb) disas _IO_vfscanf_internal
Dump of assembler code for function _IO_vfscanf_internal:
0x00007ffff70eade0 <+0>: push %rbp
0x00007ffff70eade1 <+1>: mov %rsp,%rbp
0x00007ffff70eade4 <+4>: push % r15 0x00007ffff70eade6 <+6>: push % r14 0x00007ffff70eade8 <+8>: push % r13 0x00007ffff70eadea <+10>: push % r12 0x00007ffff70eadec <+12>: mov %rsi,% r12 0x00007ffff70eadef <+15>: push %rbx
0x00007ffff70eadf0 <+16>: mov %rdi,%rbx
0x00007ffff70eadf3 <+19>: sub $0x368,%rsp
0x00007ffff70eadfa <+26>: mov 0x32d157(%rip),%rax # 0x7ffff7417f58
0x00007ffff70eae01 <+33>: mov %rdx,-0x2b0(%rbp)
0x00007ffff70eae08 <+40>: mov %rcx,-0x2e8(%rbp)
0x00007ffff70eae0f <+47>: mov -0x2b0(%rbp),%rcx
=> 0x00007ffff70eae16 <+54>: mov %fs:(%rax),%rax

Thank you.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=539

[derekbruening]

From [email protected] on August 17, 2011 10:26:14

Xref issue #534

[derekbruening]

From [email protected] on August 17, 2011 11:25:04

Which revision of DR are you using? Did you try the latest DR?

[derekbruening]

From [email protected] on August 17, 2011 12:17:04

Yes I tried the lates DR ( r934 ).

[derekbruening]

From [email protected] on August 17, 2011 12:41:54

I need reproduce the problem before I can debug it. Anyway I can reproduce the problem?

[derekbruening]

From [email protected] on August 24, 2011 08:53:16

Please check out the latest DR to see if the problem is solved.

[derekbruening]

From [email protected] on August 26, 2011 02:34:41

Sorry for the late reply. I just checked the latest version ( r951 ) on those
programs and they just hang. CPU usage from system monitor doesn't go up.
This is for both debug and release build. For debug build, the log size stop
increasing when it's smaller than 1MB even with -loglevel 4. This version
works well with -no_private_loader option.

[derekbruening]

From [email protected] on August 26, 2011 08:27:13

Can you send me the log file created. If it does not use any CPU, is it possible that the process is waiting for some input.

[derekbruening]

From [email protected] on August 26, 2011 09:55:34

I sent you the log file.