On 09/26/2012 08:08 AM, sya...@gmail.com wrote:
> Hi,
> 
> Thanks for responding to my email.
> 
> Firstly, I've to admit that I'm new to this Android stuff.  Hope you can bear 
> with me.
> 
> What I'm trying to do is to study on system call used by an application, in 
> this case a SMS application that I installed in an emulator.  
> I want to know the what are the system calls involved when I use the 
> application to send and receive the SMS.
> 
> What I've done :
> 
> 1) I installed the android sdk together with a third party  SMS application
> 2) I used the adb shell to get the PID and dump the strace output to a file.  
> The command I used:
>      " strace -e trace=open,read -p 834  -v -o handcent2.txt" 
> 
> The full strace dump is as attached.
> 
> I've difficulty in understanding the output and now based on your feedback 
> I'm not sure whether this is the actual output of strace or not.
> 
> Hope you can give some guidance.

Where did you get the strace program that you used for this dump?

This syscall_983042() doesn't look like anything I've seen before.
My experience is that the strace code in AOSP is a bit dated --
it had at least one syscall incorrectly named when I looked at it
a few years ago.
But in that case the name was just wrong (and, of course the
argument/results decode was then wrong as well).  In your case,
the name and decode seem completely bogus.  (There is no syscall
number 983042 on ARM - trust me. :-)

Maybe this is something funky like a futex.

Can you try the strace using -tt and see what the timing is between
calls?  Sometimes futexes and/or gettimeofday are called a whole lot, and often
in short intervals.

The other thing to do is to look at the strace source code, and see
where this syscall_983042 name is coming from.  I suspect from the decode
that this is what strace does when it doesn't know what the heck it just
saw.  (So, this might be another indication that this is from an
out-of-date strace implementation.)  But, assuming the decode wasn't
completely botched, it looks like the syscall is returning success.
If this isn't the thing you are looking for, then maybe you can just
'grep -v' it, and ignore it for your analysis.

I hope this is helpful.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel

Reply via email to