Bug 654636

Hello Michael,

  thank you for your report. Just FYI, the responsible
tool for above crash is not /usr/bin/ltrace, but rather
/bin/true:

$ ltrace -i nice true
[..]
[0x8048a9c] --- SIGSEGV (Segmentation fault) ---
[0xffffffff] +++ killed by SIGSEGV +++

$ gdb -q ltrace core.18109 

warning: core file may not match specified executable file.
Core was generated by `true'.
Program terminated with signal 11, Segmentation fault.
[..]

=> reassigning to proper component.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Core was generated by `true'.
Program terminated with signal 11, Segmentation fault.
#0  0x08048af8 in _start ()
...Dump of assembler code for function _start:
0x08048af0 <_start+0>:	xor    %ebp,%ebp
0x08048af2 <_start+2>:	pop    %esi
0x08048af3 <_start+3>:	mov    %ecx,%esp
0x08048af5 <_start+5>:	and    $0xfffffff0,%esp
0x08048af8 <_start+8>:	push   %eax
0x08048af9 <_start+9>:	push   %esp
0x08048afa <_start+10>:	push   %edx
0x08048afb <_start+11>:	push   $0x804b410
0x08048b00 <_start+16>:	push   $0xcc04b420
0x08048b05 <_start+21>:	push   %ecx
0x08048b06 <_start+22>:	push   %esi
0x08048b07 <_start+23>:	push   $0x8048e00
0x08048b0c <_start+28>:	call   0x80489a0 <__libc_start_main@plt>
0x08048b11 <_start+33>:	hlt    
0x08048b12 <_start+34>:	nop
0x08048b13 <_start+35>:	nop
0x08048b14 <_start+36>:	int3   
0x08048b15 <_start+37>:	nop
0x08048b16 <_start+38>:	nop
...
So true failed to even start ... maybe more glibc issue?

But note that your disassembly contains three int3 instructions injected by ltrace:

0x08048af3 <_start+3>: mov    %ecx,%esp
and
0x08048b00 <_start+16>: push   $0xcc04b420
and
0x08048b14 <_start+36>: int3   

In the first case, the instruction should actually be "move %esp,%ecx", in the second the address should be 0x8004b420 (0xcc is the int3 opcode). The third is not reachable.

What seems to be happening is that ltrace is not loading the new program's PLT; it's simply reapplying the breakpoints at the locations determined for the old program.

This is also evident from if ltrace is run with debugging turned up ("ltrace -dd nice true"):

...
execvp(0xbfa15889, 0xbfa139e8, 10, 0x804e820, 0 <unfinished ...>
DEBUG: breakpoints.c:35: insert_breakpoint(): insert_breakpoint(symbol=(nil), addr=0x8049468)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8049468)
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048c40)
DEBUG: process_event.c:119: process_event(): event: breakpoint
DEBUG: process_event.c:239: process_breakpoint(): event: breakpoint (0xa14aff)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048c40)
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_execve [11])
DEBUG: breakpoints.c:128: disable_all_breakpoints(): Disabling breakpoints for pid 1759...
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048a80)
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048a90)
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048aa0)
...
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048cd0)
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048ce0)
DEBUG: breakpoint.c:55: disable_breakpoint(): disable_breakpoint(1759,0x8048d11)
DEBUG: process_event.c:115: process_event(): event: sysret (SYS_execve [11])
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_execve [11])
DEBUG: process_event.c:115: process_event(): event: sysret (SYS_execve [11])
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_execve [11])
DEBUG: process_event.c:115: process_event(): event: sysret (SYS_execve [11])
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_execve [11])
DEBUG: process_event.c:115: process_event(): event: sysret (SYS_execve [11])
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_execve [11])
DEBUG: process_event.c:115: process_event(): event: sysret (SYS_execve [11])
DEBUG: process_event.c:119: process_event(): event: breakpoint
DEBUG: process_event.c:239: process_breakpoint(): event: breakpoint (0x95086f)
unexpected breakpoint at 0x95086f
DEBUG: process_event.c:109: process_event(): event: syscall (SYS_brk [45])
DEBUG: breakpoints.c:109: enable_all_breakpoints(): Enabling breakpoints for pid 1759...
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048a80)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048a90)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048aa0)
...
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048cd0)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048ce0)
DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(1759,0x8048d11)
...
_exit(-1079609207 <unfinished ...>
...

(My addresses are slightly different from the ones in you disassembly...)

What appears to be happening is that the "unexpected breakpoint" is occurring immediately after the return from SYS_execve, and since it's being treated as an error the *old* breakpoints are being reinstated.

As far as I can see, however, the address of the breakpoint is not touched by ltrace since it gets it from the kernel -- get_instruction_pointer in sysdeps/linux-gnu/i386/regs.c uses ptrace to get it from the process' USER area.

Either ltrace is not calling this, so it's just using whatever random data happens to be left in event.proc->instruction_pointer, or it *is* calling this and ptrace (and, I guess, the kernel) is returning the wrong value.

That true segfaults is hard to believe.  Either there's something major going on in toolchain, or ltrace screws it.  Somehow I'd rather believe the second option.  I should update ltrace to something way more decent shortly, new release is in the making.

I'm taking the bug back to ltrace.

ltrace-0.6.0-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/ltrace-0.6.0-1.fc16

Package ltrace-0.6.0-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ltrace-0.6.0-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/ltrace-0.6.0-1.fc16
then log in and leave karma (feedback).

ltrace-0.6.0-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.