[Ltrace-devel] mips: Feedback ltrace v0.7.0-gitf97b187

[Petr Machata]

Sedat Dilek <sedat.dilek at gmail.com> writes:

> Ltracing the dsld-daemon (closed source) on my router box lead
> sometimes to stalls and/or my box rebooted. This could be due to
> limited RAM as I have approx. 2MiB free.

It is very possible that we leak stuff in ltrace.  I'm currently working
on plugging valgrind into the test suite (pmachata/valgrind has this
code).  For starters, I'd like to get rid of hard memory errors, but I
think it should eventually be possible to keep an eye on leaks as well.

ltrace also slows down the process a lot, so maybe some watchdog isn't
updated and the router auto-reboots, but that doesn't explain the lags.

The main-debug log looks sane, but in dsld log I see:

time(0 <no return ...>
unexpected breakpoint at 0x2acb39a8
unexpected breakpoint at 0x2acb39a8
<... time resumed> )                             = 1349108115

This might be a wrong categorization of ptrace events (entry and exit
from a system call being reported as a breakpoint).  Perhaps the time
system call is implemented in a VDSO.  Whether that would trigger ptrace
I don't know off-hand.  But if it does, then this MIPS code (trace.c)
for deciding whether it's a system call might fail:

		/* On a mipsel,  syscall looks like:
		   24040fa1    li v0, 0x0fa1   # 4001 --> _exit syscall
		   0000000c    syscall  */
		if(insn!=0x0000000c){
			return 0;
		}

If you fell adventurous, you could try to find out what's on that
address.  Use /proc/pid/maps to find out which object it lies in and use
objdump to find out the exact instruction that is there, and which
function it is in.  This might give us some insight into what's
happening.

Thanks,
PM