diablo

oprofile

Juha Kallioinen — Wed, 13 May 2009 11:09:16 +0000

Description

Oprofile is a low overhead system-wide profiler for linux. It can be used to find CPU usage bottlenecks in the whole system and within processes.

Packages

source: oprofile

binary: oprofile

Installing Oprofile

Configuring the device

In order to run oprofile on your device, the device's kernel needs to be oprofile-enabled. A pre-compiled kernel with oprofile support is provided in the kernel-diablo-oprofile package.

Getting a new kernel

The kernel package can be downloaded from the Diablo tools repository in scratchbox environment (in an ARM target) with the command

[sbox-arm: ~] > fakeroot apt-get install kernel-diablo-oprofile

This will install the kernel image to /boot/

[sbox-arm: ~] > ls -l /boot/
total 1512
-rw-r--r--  1 user users 1543892 Dec 20 10:02 zImage-oprofile-diablo-200850

the numbers at the end of the filename resemble a date and will be different if the kernel has been updated since the writing of this document.

By copying the image to outside of the scratchbox chroot environment, you'll be able to easily access it when you're ready to flash the image.

[sbox-arm: ~] > cp /boot/zImage-oprofile-diablo-200850 /tmp

Using the new kernel

There are two ways to use the kernel image. You can flash it to the device or you can just boot the device so that it uses this kernel until you reboot it again.

Option 1: Flashing the kernel

To flash your new kernel image, use the linux flasher utility (as root)
```
$ flasher -f --kernel /tmp/zImage-oprofile-diablo-200850 -R
```
Flashing just the kernel does not destroy your other data. After the flasher has finished, your device is ready for oprofile.
Option 2: Boot with the new kernel
```
$ flasher --load --boot --kernel /tmp/zImage-oprofile-diablo-200850
```
With the boot option the power cord has to be kept plugged in until you want to revert back to the previous kernel.

Restoring the normal kernel

After you are done with oprofile you can restore the normal kernel. How you do this depends on which one of the options above you used to load the oprofile kernel.

Option 1: You chose to flash the oprofile kernel

In this case the normal kernel needs to be re-flashed:
```
$ flasher -f --flash-only kernel -F <FIASCO image> -R


# The FIASCO image is the whole product image with a name like:
# RX-44_DIABLO_3.2008.17-8_PR_COMBINED_MR0_ARM.bin
```
Note that just re-flashing the kernel part does not overwrite any of the other parts, so your data and settings will be intact.
Option 2: You chose to just boot with the new kernel

Restoring the old kernel is as easy as unplugging the power cable and power cycling the device.

Recognizing a suitable kernel

It's easy to see if your current kernel does not support oprofile by testing it with opcontrol:

Nokia-N810:~# opcontrol --status
modprobe: cannot parse modules.dep
modprobe: cannot parse modules.dep
Kernel doesn't support oprofile

Installing oprofile to the device

Providing that you have the Diablo tools repository in your APT sources.list, the easiest way to install oprofile is using apt.

Nokia-N810:~# apt-get install oprofile

This will also install binutils.

Installing debug symbols

In order to view any useful profiling information at functions level, you will have to install debugging symbols. Debugging symbols normally come with debugging (-dbg) packages. The easiest way to install all dbg packages required for a given binary is to use debug-dep-install script which comes with the maemo-debug-scripts package:

Nokia-N810:~# apt-get install maemo-debug-scripts
Nokia-N810:~# debug-dep-install /usr/bin/osso-xterm.launch

Usage

On the device, type:
```
Nokia-N810:~# opcontrol --init
Nokia-N810:~# opcontrol --no-vmlinux
Nokia-N810:~# opcontrol -e=CPU_CYCLES:100000
```
100000 indicates the number of CPU cycles between interrupts. Increasing this number lowers down the accuracy but decreases the CPU overhead. --no-vmlinux indicates we are not interested in the kernel or do not have an unstripped kernel image.
Start the usecase you are interested in and type:
```
Nokia-N810:~# opcontrol --start
```
When you've finished, type:
```
Nokia-N810:~# opcontrol --stop
```

Now you've collected the data.

Viewing profile reports

To see basic per-process picture, type opreport:

Nokia-N810:~# opreport
CPU: ARM11 PMU, speed 0 MHz (estimated)
Counted CPU_CYCLES events (clock cycles counter) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CYCLES:100000|
  samples|      %|
------------------
     1677 69.1546 no-vmlinux
      240  9.8969 libc-2.5.so
      230  9.4845 busybox
      215  8.8660 ld-2.5.so
       58  2.3918 oprofiled
    3  0.1237 ophelp
    2  0.0825 libcrypt-2.5.so

To see more detailed symbol analysis use opreport -l:

Nokia-N810:~# opreport -l|more
warning: /no-vmlinux could not be found.
BFD: /usr/lib/debug/lib/ld-2.5.so: warning: sh_link not set for section `.ARM.exidx'
BFD: /usr/lib/debug/lib/libc-2.5.so: warning: sh_link not set for section `.ARM.exidx'
CPU: ARM11 PMU, speed 0 MHz (estimated)
Counted CPU_CYCLES events (clock cycles counter) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        app name                 symbol name
1695     65.3179  no-vmlinux               (no symbols)
255       9.8266  busybox                  (no symbols)
222       8.5549  oprofiled                (no symbols)
43        1.6570  libc-2.5.so              strchr
37        1.4258  ld-2.5.so                check_match.0
32        1.2331  ld-2.5.so                do_lookup_x
17        0.6551  ld-2.5.so                _dl_relocate_object
17        0.6551  libc-2.5.so              _dl_addr
16        0.6166  ld-2.5.so                strcmp
14        0.5395  ld-2.5.so                _dl_lookup_symbol_x
13        0.5010  ld-2.5.so                __udivsi3
13        0.5010  ld-2.5.so                _dl_fixup
12        0.4624  libc-2.5.so              _int_malloc
10        0.3854  libc-2.5.so              strcmp
8         0.3083  ophelp                   (no symbols)
7         0.2697  libc-2.5.so              strpbrk
7         0.2697  libc-2.5.so              vfprintf

Profiling with callgraphs

Quite often a basic flat profile is useless. In such a cases a callgraph profile can be used. In order to profile code with callgraphs:

Add -fno-omit-frame-pointer to GCC options and recompile all the code (binaries, libraries) involved. You can do this without changing the package build rules by setting the appropriate scratchbox environment variable (documented in the Scratchbox installation /scratchbox/doc/variables.txt file) before re-building the packages:

[sbox-arm: ~] > export SBOX_BLOCK_COMPILER_ARGS="-fomit-frame-pointer"
[sbox-arm: ~] > export SBOX_EXTRA_COMPILER_ARGS="-fno-omit-frame-pointer"
[sbox-arm: ~] > cd package-1/
[sbox-arm: ~/package-1] > dpkg-buildpackage -rfakeroot
[sbox-arm: ~/package-1] > cd ../package-2/
[sbox-arm: ~/package-2] > dpkg-buildpackage -rfakeroot
...

Install re-built code and debug packages on the device

Init oprofile as usually, but add -c parameter:

Nokia-N810:~# opcontrol --init
Nokia-N810:~# opcontrol --no-vmlinux
Nokia-N810:~# opcontrol -e=CPU_CYCLES:100000 -c

Add -c to opreport:
```
Nokia-N810:~# opreport -l -c
```

Viewing reports from a PC

opreport -l, and especially opreport -c -l can take quite a long time (10 minutes) when fired up on N800/N810 devices. Therefore, it often makes sense to run opreport in scratchbox.

Configure scratchbox target in a way that its binaries and libraries 100% match the target's.
Collect profiling data as usual
Copy contents of /var/lib/oprofile from the device to the corresponding directory in scratchbox target.
in scratchbox, apt-get install maemo-debug-scripts (this may not be omitted)
install debug packages either with debug-dep-install or by hand

Note: the binaries and libraries in the scratchbox target must match what's in the device, otherwise you will get bogus results.

Oprofile with kcachegrind

kcachegrind is a useful GUI tool for viewing performance data interactively. It comes with many modern linux distros.

To use it:

Get the callgraph oprofile data (see above) and install the same packages also to scratchbox.
Copy the profile data to scratchbox session as described above.
install kcachegrind-converters package on HOST (debian, ubuntu)
in scratchbox: opreport -gdf | op2calltree (you might want to copy op2calltree script somewhere on target)
the resulting files can now be opened with kcachegrind on host, provided you set it to display ALL files (extensions are wrong)

Links

oprofile man page

gdb

Juha Kallioinen — Wed, 18 Feb 2009 12:08:05 +0000

Description

GDB, the GNU Project debugger, allows you to see what is going on 'inside' another program while it executes -- or what another program was doing at the moment it crashed.

GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

Start your program, specifying anything that might affect its behavior.
Make your program stop on specified conditions.
Examine what has happened, when your program has stopped.
Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

Packages

source: gdb

binary: gdb

Usage Examples

There are several issues you need to be aware when debugging (optimized) code on ARM. Please read the maemo debugging guide.

Links

gdb man page

gdb server man page

maemo debugging guide

strace

Juha Kallioinen — Wed, 18 Feb 2009 12:04:55 +0000

Description

Strace is a handy tool for seeing how an application is interacting with the operating system using the system calls. It displays the used system calls and parameters. It also shows the return codes of the system calls. In addition strace can attach to a running process making it a suitable tool for debugging the system calls that an already running process is calling.

Strace is especially helpful for:

Figuring out why the program is failing to start or exits early.
Finding out what (configuration) files are used by the program.
Checking out whether the program is idle or wasting battery when it should not be doing anything.
Finding out where a frozen program got stuck.
Viewing an application's communications with the network.

Packages

source: strace

binary: strace

Usage Examples

Installing Strace

The strace tool can be installed to the Internet Tablet. In Scratchbox it is possible to use the Scratchbox-provided strace. Using strace in an X86 target rather than in an ARMEL target is preferable for the reason that in an ARMEL target strace will actually trace the system calls of the QEMU process (which is used to run the arm binary).

Using Strace

These examples can be run both in Scratchbox X86 environment and in the Internet Tablet device itself.

Getting a System Call Trace from an Application

To get a simple list of the system calls the application is calling, strace is run with the path to the program as a parameter. Below strace is run with the small gdb_example program that is introduced in the maemo debugging guide.

[sbox-DIABLO_X86: ~/src/testing/gdb_example] > strace ./gdb_example
execve("./gdb_example", ["./gdb_example"], [/* 50 vars */]) = 0
brk(0)                                  = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686/sse2", 0xbff86948) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686", 0xbff86948)     = -1 ENOENT (No such file or directory)
open("/lib/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/sse2", 0xbff86948)     = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0xbff86948)          = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/i686/sse2", 0xbff86948)    = -1 ENOENT (No such file or directory)
open("/lib/i686/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/i686", 0xbff86948)         = -1 ENOENT (No such file or directory)
open("/lib/sse2/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/sse2", 0xbff86948)         = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 Y\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1213256, ...}) = 0
mmap2(NULL, 1222300, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4001d000
mmap2(0x40142000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124) = 0x40142000
mmap2(0x40145000, 9884, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40145000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40148000
set_thread_area({entry_number:-1 -> 6, base_addr:0x401486c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x40142000, 4096, PROT_READ)   = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40149000
write(1, "Now in main().\n", 15Now in main().
)        = 15
write(1, "Now in example_1(1) function.\n", 30Now in example_1(1) function.
) = 30
write(1, "Now in example_2(parameter here)"..., 43Now in example_2(parameter here) function.
) = 43
write(1, "Now in example_3()\n", 19Now in example_3()
)    = 19
exit_group(0)                           = ?
[sbox-DIABLO_X86: ~/src/testing/gdb_example] >

N.B.

If you are using strace in an ARMEL target, the option -f needs to be given, so that the process run under the QEMU is also traced.

Essentially, one line in the output refers to one system call made to the Linux kernel. Every line has the name of the system call, the parameters to the call, and finally the return value of the system call.

For example, the line:

write(1, "Now in main().\n", 15Now in main().
)        = 15

tells that the system call that was called from gdb_example was write() with parameters (1,"Now in main().\n", 15), next the output of the call is shown: "Now in main()." and finally the return code is displayed: =15.

Note: Failed system calls usually (not always) return a return code of -1.

An example of a failed stat64 call would be:

stat64("/lib/sse2", 0xbff86948)         = -1 ENOENT (No such file or directory)

Here the stat64 return value of -1 is displayed together with the symbolic name of ENOENT error code. You can see clearly that the program tried to access /lib/sse2, but failed for the reason that the file does not exist.

Studying the output of strace and comparing it to the source file tells that, for example, the gdb_example program's printf() functions are each calling the write() system call. In addition, it shows all the open() and stat64() and other system calls in the list.

Attaching to a Running Process with Strace

One can attach to a running process with strace. This is helpful, especially when debugging a daemon type of an application, and it is necessary to see what system calls the daemon is calling without restarting the daemon.

In the following example, the top application is started inside Scratchbox and left running in one terminal. Then another terminal will be opened and strace is attached to the top application.

Start the top application inside one terminal in Scratchbox X86 target:

[sbox-DIABLO_X86: ~] > top


## the screen clears and top starts to loop...


top - 14:49:35 up 17 days, 23:38,  0 users,  load average: 0.07, 0.02, 0.00
Tasks: 115 total,   2 running, 113 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    775176k total,   754708k used,    20468k free,   126608k buffers
Swap:  1622524k total,    19716k used,  1602808k free,   413752k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12807 user      16   0  2184 1172  888 R 79.0  0.2   0:00.09 top
    1 root      16   0  1632  536  448 S  0.0  0.1   0:01.56 init
    2 root      34  19     0    0    0 R  0.0  0.0   0:00.08 ksoftirqd/0
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0 
    4 root      10  -5     0    0    0 S  0.0  0.0   0:00.18 events/0 
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.01 khelper
    6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
    8 root      10  -5     0    0    0 S  0.0  0.0   0:00.11 kblockd/0
    9 root      10  -5     0    0    0 S  0.0  0.0   0:00.05 kacpid
 ... etc ...

Start another terminal window, log in on the Scratchbox and run the following commands:

[sbox-DIABLO_X86: ~] > pidof top
12807
[sbox-DIABLO_X86: ~] > strace -p 12807

With the -p flag strace can be attached to a running process.

The pidof command tells the process id (PID) of a running program. In this example, it is 12807 (in your machine the number will be different). The output of strace would look similar to this:

Process 12807 attached - interrupt to quit
select(1, [0], NULL, NULL, {2, 320000}) = 0 (Timeout)
fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
read(0, 0xbfeb191f, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
ioctl(0, TCFLSH, 0)                     = 0
fcntl64(0, F_SETFL, O_RDWR)             = 0
gettimeofday({1195023907, 63212}, {4294967176, 0}) = 0
open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
getdents64(7, /* 35 entries */, 1024)   = 1008
getdents64(7, /* 37 entries */, 1024)   = 1008
stat64("/proc/1", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/1/stat", O_RDONLY)          = 8
read(8, "1 (init) S 0 1 1 0 -1 4194560 43"..., 1023) = 187
close(8)                                = 0
open("/proc/1/statm", O_RDONLY)         = 8
read(8, "738 463 133 21 0 361 0\n", 1023) = 23
close(8)                                = 0
stat64("/proc/2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/2/stat", O_RDONLY)          = 8
read(8, "2 (kthreadd) S 0 0 0 0 -1 41024 "..., 1023) = 128
close(8)                                = 0
open("/proc/2/statm", O_RDONLY)         = 8
read(8, "0 0 0 0 0 0 0\n", 1023)        = 14
close(8)                                = 0
stat64("/proc/3", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/3/stat", O_RDONLY)          = 8
read(8, "3 (migration/0) S 2 0 0 0 -1 410"..., 1023) = 135
close(8)                                = 0


... long list of output ...

Studying the output of strace, you can see what system calls the top program is calling during its main loop. In this case, top is opening a lot of files under the /proc/ file system to get information about the running processes in the system.

How to Trace All the Running Applications

Occasionally it may be necessary to trace all the running applications in the device. For example, it may be necessary to know which process accesses some specific file, while not keeping it open all the time (if it is kept open all the time, it can be found from /proc/*/fd/ or with lsof).

In the following example from the device, the open() system calls are traced from all running programs started after the DSME process.

/home/user # strace -e trace=open \
      $(cd /proc/; dsme=$(pidof dsme|cut -d' ' -f1); \
      for pid in [0-9]*; do \
         if [ $pid -gt $dsme ] && [ $pid != $$ ]; then \
             echo "-p $pid"; \
         fi; \
      done)

Note: The above command does not start to trace the DSME. Accidentally suspending DSME would cause the device to reboot because DSME keeps the device's HW watchdog refreshed.

The output of the command will look similar to this:

/home/user # strace -e trace=open \
>       $(cd /proc/; dsme=$(pidof dsme|cut -d' ' -f1); \
>       for pid in [0-9]*; do \
>          if [ $pid -gt $dsme ] && [ $pid != $$ ]; then \
>              echo "-p $pid"; \
>          fi; \
>       done) 
Process 1019 attached - interrupt to quit
Process 1036 attached - interrupt to quit
Process 1039 attached - interrupt to quit
...snip...
Process 13559 attached - interrupt to quit
attach: ptrace(PTRACE_ATTACH, ...): No such process
Process 332 attached - interrupt to quit
Process 3606 attached - interrupt to quit
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Process 434 attached - interrupt to quit
Process 682 attached - interrupt to quit
...snip...
Process 332 detached
[pid   762] open("/dev/dspctl/ctl", O_RDWR) = 6
[pid   762] open("/dev/dspctl/ctl", O_RDWR) = 6
[pid   762] open("/dev/dspctl/ctl", O_RDWR) = 6
[pid   709] --- SIGALRM (Alarm clock) @ 0 (0) ---
[pid   709] --- SIGALRM (Alarm clock) @ 0 (0) ---
[pid   762] open("/dev/dspctl/ctl", O_RDWR) = 6
[pid   709] --- SIGALRM (Alarm clock) @ 0 (0) ---
... etc ...

The output shows which processes strace attaches to and what are the files those processes are opening.

N.B.

If there are lots of system calls performed by the process(es), strace might not show all of them. So, basically the output in this kind of a situation is only indicative. For more accurate information, a specific single processes can be traced.

Other Strace Options

Here are examples of some of the useful strace options.

-f fork

The -f fork option tells strace to follow the execution to the forked process from the calling process. By default, strace does not follow forks.
-e expr

The -e option is handy when it is necessary to limit the scope of the output. For example,
```
[sbox-DIABLO_X86: ~/src/testing/gdb_example] > strace -e trace=network ./gdb_example
```
would only output those calls that are network-related. In this example, there would be no other output than the normal output of the program.

However,
```
[sbox-DIABLO_X86: ~/src/testing/gdb_example] > strace -e trace=file ./gdb_example
```
would only show which system calls are called related to accessing files.
-tt

The -tt option makes strace precede each system call with the time it was called. This could potentially be used for rough performance analysis.

Start a process and trace all IPC and network related system calls it makes and print the time of day with microseconds for each traced system call.
```
[sbox-DIABLO_X86: ~/] > strace -tt -e trace=ipc,network ./some_program -programs -own -args
```

Links

strace man page

maemo debugging guide

crash-reporter

Juha Kallioinen — Tue, 25 Nov 2008 12:55:06 +0000

Description

Crash Reporter provides a user-friendly graphical user interface that allows users to easily upload crash reports provided by sp-rich-core to a centralized location to help developers to fix issues.

Packages

source: nitro

binary: nitro

Usage Examples

Links

nitro_ui man page

bluez-hcidump

Juha Kallioinen — Tue, 25 Nov 2008 12:53:11 +0000

Description

Bluez-hcidump is the BlueZ project Bluetooth HCI data dumper.

Hcidump lets you view raw HCI data to and from a Bluetooth device in a human readable way.

Packages

source: bluez-hcidump

binary: bluez-hcidump

Usage Examples

Start hcidump like this and create a Bluetooth connection to your phone:

# hcidump -V -x

you'll see a lot of verbose messages of the data and state of the connection.

Links

hcidump man page

http://www.bluez.org/

Description

bluez-utils-test contains several test tools for testing the BlueZ stack. Listed here are a few of the tools:

hciconfig configure Bluetooth devices
hcitool configure Bluetooth connections
l2ping send L2CAP echo request and receive answer
pand BlueZ Bluetooth PAN daemon

Packages

source: bluez-utils

binary: bluez-utils-test

Usage Examples

Links

http://www.bluez.org/

check

Juha Kallioinen — Tue, 25 Nov 2008 12:50:29 +0000

Description

check features a simple interface for defining unit tests, putting little in the way of the developer. Tests are run in a separate address space, so Check can catch both assertion failures and code errors that cause segmentation faults or other signals. The output from unit tests can be used within source code editors and IDEs.

Packages

source: check

binary: check

Usage Examples

Links

http://check.sourceforge.net/

http://check.sourceforge.net/doc/check.html/index.html

functracer-postproc

Juha Kallioinen — Tue, 25 Nov 2008 12:44:35 +0000

Description

functracer-postproc is a post-processing tool. It generates detailed reports from Functracer output data. For now, functracer-postproc generates the following reports:

Non-freed allocations detection (possible leaks)
Free malloc/calloc/realloc detection

Packages

source: functracer-postproc

binary: functracer-postproc

Usage Examples

Links

xxx man page

Description

functracer is a debugging tool that gets backtraces of all allocations done in ARM/x86 processes. It works with optimized (-O2) code, where debugging symbols are available either in the application binaries themselves, or in separate debug files.

Packages

source: functracer

binary: functracer

Usage Examples

Links

xxx man page

xresponse

Midgard Administrator — Tue, 24 Jun 2008 11:39:10 +0000

Description

Xresponse synthetizes X stylus events and outputs screen update sizes and their timestamps.

Xresponse can catch applications doing screen updates which are not done as a response to user input/request and updates of unnecessary parts of application UIs. These are detrimental to application performance and device use-time.

Xresponse can also be used to time the applications screen updates i.e. their response time.

The screen update areas are output in the "X geometry" format (WIDTH x HEIGHT + X + Y).

Packages

source: xresponse

binary: xresponse

Usage Examples

Monitoring screen updates

Xresponse can be used to monitor how large parts of the screen and how often an application is updating them. To run it in the screen update monitoring mode, use:

# xresponse -w 0 -i

Then just use the applications.

Timing application response / screen updates

Xresponse can synthetize stylus taps; just specify where they should happen with the -c option and how long Xresponse should wait for the screen updates before proceeding with the -w option:

# xresponse -w 5 -c 200x20

If you want to monitor only part of the screen, e.g. toolbar, you can give which area of the screen is monitored with the -m option:

# xresponse -m 800x80+0+400 -w 20 -c 650x430

(This is useful for example if an application like Browser can be updating the normal application area also without user interaction.)

To time application startup, open the Task Navigator application menu, synthetize a tap to the menu item starting the application and monitor the screen updates. With most applications the last screen update is the time when the application is fully initialized and ready for use.

Keypress simulation

Xresponse can also simulate pressing single keys and typing strings.

To simulate pressing the Tab key, entering the string 'Foobar' and pressing Enter with a pause of one second between the events:

# xresponse -w 1 -k Tab,100 -w 1 -t Foobar -w 1 -k Return,100

Notes

There are a few quirks with the order of the options. The -o or --logfile option has to be given as the first option for it to work.

Links

xresponse man page

diablo

Midgard Administrator — Tue, 24 Jun 2008 11:17:37 +0000

The SDK tools documentation for maemo 4 Chinook is available from the diablo tools page:

http://maemo.org/development/tools/diablo.html

sp-response-time

Midgard Administrator — Tue, 17 Jun 2008 12:08:59 +0000

Description

sp-response-time monitors UI response times.

This application monitors keyboard and mouse/touchscreen events and calculates how long it takes when updates on the screen are done. This tool is designed for giving support on performance analysis when calculating UI response times against some performance requirements.

Packages

source: sp-response-time

binary: sp-response-time

Usage Examples

Running this in a Scratchbox target and opening up menus in the emulated device desktop results in output like this:

[sbox-i386: ~/] > ./sp-response-time -w 100

sp-response-time 0.0.8

Timestamp      : Info ([event(s), damage(s), update(ms), ]message) -------------
1213704219.115 : 1213704218.997, 1213704219.008, 11, "Event at 1213704218.997s. Update took 11ms."
1213704221.367 : 1213704221.190, 1213704221.200, 10, "Event at 1213704221.190s. Update took 10ms."
1213704223.718 : 1213704222.220, 1213704223.574, 1354, "Event at 1213704222.220s. Update took 1354ms."

Links

sp-response-time man page

valgrind

Midgard Administrator — Tue, 17 Jun 2008 11:43:44 +0000

Description

Valgrind is an Open Source suite of tools for debugging and profiling Linux programs. It works only on x86 (and PPC).

Valgrind is a really powerful and easy to use tool that can save you a lot of debugging time.

Because Valgrind works by simulating the x86 processor and instrumenting the binaries on the fly, it can control the program execution completely. As a downsize it makes program execution 10-300 times slower than normally, depending on the used Valgrind tools (massif is the fastest, callgrind the slowest) and can take a huge amount of memory.

The tools available for Valgrind are:

Massif: run-time memory usage graph and hyperlinked allocation backtraces (allocation are sorted by time*size)
Memcheck: Detects memory access errors (writes to freed memory, reads from uninitialized memory) and memory leaks (process has lost a pointer to allocation). This reports less false positives than any other (Open Source) tool and can call gdb when the error happens
Cachegrind: Performance profiling which can be started and stopped at any moment and the results can be sorted according to instructions, cache hits etc.
Callgrind: Like Cachegrind, but stores also callgraph information (but can show only instruction counts). Works very well with the Kcachegrind UI.
Helgrind: Detects race conditions when (p)threaded programs access global data

Building Valgrind

Please note that in maemo environment we need to export G_SLICE="always-malloc" to avoid getting bogus leakage reports from Glib GSlice allocator (its TLS usage confuses Valgrind allocation tracking). If you build your own Valgrind version, you should use this setting when Valgrinding programs using Glib (e.g. all maemo UI apps).

Packages

source: valgrind

binary: valgrind

Usage Examples

See the maemo debugging guide for usage examples.

Links

valgrind man page

http://valgrind.org/

Valgrind tool-suite

Memcheck memory checker

Massif heap-profiler

Callgrind profiler

Helgrind data-race tracker

maemo debugging guide

doxygen

Midgard Administrator — Mon, 16 Jun 2008 14:51:01 +0000

Description

Doxygen is a documentation system for C, C++, Java, Python and other languages.

Doxygen extracts comments from source code comments and it can generate online and offline documentation from them. Among the supported output formats are for example HTML, RTF and PDF.

Some of the maemo API documentation is published in Doxygen generated format.

Packages

source: doxygen (available in diablo/sdk repository)

binary: doxygen (available in diablo/sdk repository)

Usage Examples

Links

doxygen man page

http://www.doxygen.org/

http://en.wikipedia.org/wiki/Doxygen

maemo API documentation

Description

GTK-Doc is typically used to document the public C API of libraries. It has some special features that are useful in documenting signals and properties of GTK+ widgets and GObject classes. It can also be used to document application code.

Many of the maemo API documents have been generated with GTK-Doc.

Packages

source: gtk-doc-tools (available in diablo/sdk repository)

binary: gtk-doc-tools (available in diablo/sdk repository)

Usage Examples

Links

http://www.gtk.org/gtk-doc/

maemo API documentation

xresponse-visualize

Midgard Administrator — Mon, 16 Jun 2008 13:37:51 +0000

Description

xresponse-visualize is a set of scripts that can be used on the host/Scratchbox environment to visualize xresponse log files.

xresponse-convert: create a series of images from xresponse logs highlighting the area of the screen where changes were detected.
xresponse-visualize: animates images create with xresponse-convert

Packages

source: xresponse-visualize

binary: xresponse-visualize

Usage Examples

Notes

The recommended dependencies (imagemagick and python-pygame) for xresponse-visualize are not (yet) provided with the maemo SDK, but are expected to be found from the user's host system.

Links

xresponse-convert man page

xresponse-visualize man page

sp-memusage

Midgard Administrator — Mon, 16 Jun 2008 13:36:22 +0000

Description

sp-memusage is a collection of memory usage monitoring tools and scripts.

mem-dirty-code-pages: prints out the dirty code pages allocated by the given processes
mem-monitor: prints out system memory usage at a given interval
mem-monitor-smaps: prints out the memory usage of a given process at a given interval
mem-smaps-private: prints out the private memory usage of a given process
run-with-mallinfo: run maemo applications under mallinfo
run-with-memusage: run maemo applications under memusage

Packages

source: sp-memusage

binary: sp-memusage, sp-memusage-dbg

Usage Examples

See respective man pages for usage examples and more info on each utility.

Links

mem-dirty-code-pages man page

mem-monitor man page

mem-monitor-smaps man page

mem-smaps-private man page

run-with-mallinfo man page

run-with-meminfo man page

sp-smaps-measure

Midgard Administrator — Mon, 16 Jun 2008 12:46:58 +0000

Description

sp-smaps-measure installs an utility that can be invoked to take a snapshot of /proc/PID/smaps files. The smaps files contain very detailed information about processes' memory consumption.

Packages

source: sp-smaps

binary: sp-smaps-measure

Usage Examples

Writes output similar to head -2000 /proc/[1-9]*/smaps to logfile after_boot.cap.

# sp_smaps_snapshot > after_boot.cap

It is possible to request realtime priority with the --realtime option. This requires that the utility is run as superuser.

Links

sp_smaps_snapshot man page

Description

sp-smaps-visualize provides utilities primarily for the host/Scratchbox environment to analyze smaps data captured by sp-smaps-measure.

sp_smaps_analyze: Reads raw (.cap) or normalized (.csv) sp_smaps_snapshot capture data and produces detailed view to system / process / object memory usage in html format.
sp_smaps_appvals: Reads raw (.cap) or normalized (.csv) sp_smaps_snapshot capture data and produces a summary table for memory usage of all applications in the capture file.
sp_smaps_diff: Displays differences in application memory usage between smaps capture files.
sp_smaps_filter: Process captured smaps files in different ways.
sp_smaps_flatten: Reads raw capture files generated with sp_smaps_snapshot and tries to detect and remove duplicate entries due to multiple threads.
sp_smaps_normalize: Reads smaps snapshots and writes CSV format data that can be imported to spreadsheet programs or sp_smaps_analyze and friends.

Packages

source: sp-smaps

binary: sp-smaps-visualize

Usage Examples

Refer to each utility's man page for usage examples.

Links

sp_smaps_analyze man page

sp_smaps_appvals man page

sp_smaps_diff man page

sp_smaps_filter man page

sp_smaps_flatten man page

sp_smaps_normalize man page

xrestop

Juha Kallioinen — Tue, 06 May 2008 11:19:08 +0000

Description

Xrestop shows how much X resources from the X server are being used by the X clients. It is similar to top and htop.

Packages

source: xrestop

binary: xrestop

Usage

# xrestop

Links

xrestop man page

diablo

oprofile

Description

Packages

Installing Oprofile

Configuring the device

Getting a new kernel

Using the new kernel

Restoring the normal kernel

Recognizing a suitable kernel

Installing oprofile to the device

Installing debug symbols

Usage

Viewing profile reports

Profiling with callgraphs

Viewing reports from a PC

Oprofile with kcachegrind

Links

See Also

gdb

Description

Packages

Usage Examples

Links

See Also

strace

Description

Packages

Usage Examples

Installing Strace

Using Strace

Getting a System Call Trace from an Application

Attaching to a Running Process with Strace

How to Trace All the Running Applications

Other Strace Options

Links

See Also

crash-reporter

Description

Packages

Usage Examples

Links

See Also

bluez-hcidump

Description

Packages

Usage Examples

Links

See Also

bluez-utils-test

Description

Packages

Usage Examples

Links

See Also

check

Description

Packages

Usage Examples

Links

See Also

functracer-postproc

Description

Packages

Usage Examples

Links

See Also

functracer

Description

Packages

Usage Examples

Links

See Also

xresponse

Description

Packages

Usage Examples

Monitoring screen updates

Timing application response / screen updates

Keypress simulation