WWW-www.enlightenment.org pushed a commit to branch master.
http://git.enlightenment.org/website/www-content.git/commit/?id=85b880759057666e0953e5d80e39dff0878b8129
commit 85b880759057666e0953e5d80e39dff0878b8129
Author: Raster <ras...@rasterman.com>
Date: Thu Jun 18 23:09:01 2015 -0700
Wiki page docs-efl-debug changed with summary [] by Raster
---
pages/docs-efl-debug.txt | 388 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 364 insertions(+), 24 deletions(-)
diff --git a/pages/docs-efl-debug.txt b/pages/docs-efl-debug.txt
index e0bec06..93c086e 100644
--- a/pages/docs-efl-debug.txt
+++ b/pages/docs-efl-debug.txt
@@ -3,6 +3,8 @@
Remember to build EFL, Enlightenment etc. with debugging compile flags.
[[docs-efl-start]] has a section on this for your build environment. Remember
to have ''-g'' as a ''CFLAGS'' option to ensure binaries and libraries have all
the debug information they need. If you didn't build with debugging, simply
build again with these flags correctly set and debugging can begin.
+----
+
==== EFL Logs ====
Sometimes you will see logs as follows:
@@ -102,13 +104,15 @@ EINA_LOG_LEVEL=3 EINA_LOG_LEVELS_GLOB=eina_*:0 ./myapp
This will disable eina_log output from all internal eina code thus allowing
you to see your own domain messages easier.
+----
+
==== Debug tools ====
=== GDB ===
== General ==
-In general you would run some app "under gdb" like following:
+In general you would run some app "under GDB" like following:
<code bash>
gdb myapp
@@ -120,9 +124,11 @@ You can also attach to a running process with:
gdb myapp PID
</code>
-Where ''PID'' is the process id of the ''myapp'' process you want to attach to
and begin debugging. Enlightenment is special because it already has something
monitoring enlightenment for crashes (''enlightenment_start'' does this job),
so you can't attach gdb to it as normal. This is how enlightenment will produce
a ''~/.e-crashdump.txt'' log for every crash that happens. It needs gdb to do
this though, but it automated.
+Where ''PID'' is the process id of the ''myapp'' process you want to attach to
and begin debugging.
+
+> //Enlightenment is special because it already has something monitoring
enlightenment for crashes (''enlightenment_start'' does this job), so you can't
attach GDB to it as normal. This is how enlightenment will produce a
''~/.e-crashdump.txt'' log for every crash that happens. It needs GDB to do
this though, but it automated. you will see more enlightenment specific
mentions here that don't generally apply, but do to enlightenment.//
-Note that on modern systems, gdb attaching is prohibited. You may \explain why
no ''.e-crashdump.txt'' file is created. To enable it, please do:
+Note that on modern systems, GDB attaching is prohibited. This may explain why
no ''~/.e-crashdump.txt'' file is created. To enable it, please do:
<code bash>
sudo sysctl -w kernel.yama.ptrace_scope=0
@@ -130,13 +136,13 @@ sudo sysctl -w kernel.yama.ptrace_scope=0
== GDB with Enlightenment ==
-When Enlightenment crashes, it is stopped and a "white box of death" is
displayed on screen. A crashdump file should have been appended too, but if you
want to poke around, you need to do some special things. We can now go over to
a text console (CTRL+ALT+F1) and log in or use something liks ssh to remotely
log into your machine from another one. Now you need to attach gdb to
enlightenment. Find out the process ID of enlightenment as shown below.
+When Enlightenment crashes, it is stopped and a "white box of death" is
displayed on screen. A ''crashdump'' file should have been appended to, but if
you want to poke around, you need to do some special things. You can now go
over to a text console (CTRL+ALT+F1) and log in or use something like ssh to
remotely log into your machine from another one. Now you need to attach GDB to
enlightenment. Find out the process ID of enlightenment as shown below.
-short way:
+The short way:
<code bash>
-kill -SIGUSR1 "$(pidof enlightenment_start)" # tell enlightenment_start to
stop monitoring enlightenment
-gdb enlightenment "$(pidof enlightenment)"
+kill -SIGUSR1 "$(pidof enlightenment_start)" # Tell enlightenment_start to
stop monitoring enlightenment
+gdb enlightenment "$(pidof enlightenment)" # Attach to the enlightenment
process with GDB
</code>
If the above fails you have to find PIDs manually:
@@ -145,7 +151,7 @@ If the above fails you have to find PIDs manually:
ps -auwx | grep enlightenment
</code>
-or:
+Or:
<code bash>
pgrep enlightenment
@@ -158,16 +164,16 @@ kill -SIGUSR1 PID_OF_enlightenment_start
gdb enlightenment PID_OF_enlightenment
</code>
-Where PID_OF_enlightenment_start is the process id you found. Gdb will load
and stream along for a bit then give you a prompt.
+Where PID_OF_enlightenment_start is the process id you found. GDB will load
and stream along for a bit then give you a prompt.
== Generic debugging ==
-You can now debug. You may want to save the output of gdb to a log file, so
the following commands will let you do that. Replace log.txt with any file you
prefer, if you don't want to output to this file.
+You can now debug. You may want to save the output of GDB to a log file, so
the following commands will let you do that. Replace log.txt with any file you
prefer, if you don't want to output to this file.
(gdb) set logging file log.txt
(gdb) set logging on
-Now that you are saving everything you do in gdb, try to use gdb's backtrace
command:
+Now that you are saving everything you do in GDB, try to use GDB's backtrace
command:
(gdb) bt
#0 0xb7d539f8 in select () from /lib/tls/libc.so.6
@@ -199,15 +205,15 @@ Lets take a look at the function that was called:
#6 0x0808f706 in e_sigseg_act (x=11, info=0x80a9fb0, data=0x80aa030)
-The ''e_sigseg_act()'' function is called when enlightenment segfaults (it is
called directly by the kernel interrupting anything e was doing just before it
was called - the thing it was doing would have caused the segfault - this is
unique to enlightenment and most applications will just crash straight away as
opposed to calling a segfault handler). So that means in this example E
segfaulted inside the select() function (frame 7 is an intermediate frame that
calls the signal handler).
+The ''e_sigseg_act()'' function is called when enlightenment segfaults (it is
called directly by the kernel interrupting anything enlightenment was doing
just before it was called - the thing it was doing would have caused the
segfault. This is unique to enlightenment and most applications will just crash
straight away directly inside the function where they crash as opposed to
calling a segfault handler). So that means in this example E segfaulted inside
the ''select()'' function (frame [...]
-Next we need to get some more info about this crash. We will now go to the
stack frame just before the segfault. In this case its stack frame 8. you want
a listing of the code there and some info (so we can double check your code
there is what we have here too). the gdb commands you then want are:
+Next you need to get some more info about this crash. Now go to the stack
frame just before the segfault. In this case its stack frame 8. You want a
listing of the code there and some. The GDB commands you then want are:
- * **fr 8** = go to frame 8
- * **l** = list the source code here
- * **p ret** = print the value of ret
+|''fr 8'' | Go to frame 8 |
+|''l'' | List the source code here |
+|''p ret'' | Print the value of ret |
-If you want to get adventurous you should start dumping variable values for
us. In this example I can't debug select because its in libc and it is probably
not the reason for the crash. We will look to the frame above that, frame 9, to
see if any nasty data was being sent to select.
+If you want to get adventurous you should start dumping variable values. In
this example you can't debug ''select()'' because it's in libc and it is
probably not the reason for the crash. We will look to the frame above that,
frame 9, to see if any nasty data was being sent to ''select()''.
(gdb) fr 9
#9 0xb7f814ee in _ecore_main_select (timeout=0) at ecore_main.c:338
@@ -224,7 +230,7 @@ If you want to get adventurous you should start dumping
variable values for us.
341 if (errno == EINTR) return -1;
342 }
-We can see some variables there and function calls - often variables like
pointers may be garbage or NULL and thus causing a segv. We can see what they
are using the print (p) command, see the example below:
+You can see some variables there and function calls - often variables like
pointers may be garbage or NULL and thus causing a segv. You can see what they
are using the print (''p'') command, see the example below:
(gdb) p ret
$1 = -4
@@ -235,11 +241,11 @@ We can see some variables there and function calls -
often variables like pointe
(gdb) p exfds
$4 = {__fds_bits = {0 <repeats 32 times>}}
-If the variable is a pointer to something printing it will print the pointer
value, not what it points to, what it points to is important. To print that we
suggest:
+If the variable is a pointer to something, printing it will print the pointer
value, not what it points to. What it points to is important. To print that add
a ''*'' to dereference one level of pointer indirection:
p *pointer
-=Example:=
+= Example: =
(gdb) fr 5
#5 0x0809b698 in e_alert_show (
@@ -263,16 +269,350 @@ If the variable is a pointer to something printing it
will print the pointer val
(gdb) p dd
$5 = (Display *) 0x80d1018
-As we know its a pointer (Display *) the * means its a pointer to a Display
struct/type. The pointer value looks healthy, it is not 0x0 or a very low
number, so we can try and look at the data it is pointing to:
+As you see that it's a pointer ''(Display *)'' the ''*'' means its a pointer
to a Display struct/type. The pointer value looks healthy, it is not ''0x0'' or
a very low number, so you can try and look at the data it is pointing to:
(gdb) p *dd
$6 = <incomplete type>
-Nevermind, that's xlib's display struct. It's private and we don't know what's
inside - BUT all the types e uses(such as Evas_List) inside that it defines
will allow you to do this generally.
+Nevermind. That's xlib's display struct. It's private and you don't know
what's inside - BUT all the types e uses (such as Evas_List), are defined, so
this will allow you to do this generally in most situations.
+
+In general it's a good idea to spend some quality time with GDB and do all
this. If you want others to help with the issue, then mail all the output of
GDB during one of these "debugging sessions" and then it can be sifted through
by developers for nuggets of information. It may not mean a lot to you, but it
means a world developers who sling code around all day long. Sometimes the
stack is garbage and there is nothing you can do. Often this means you need to
resort to Valgrind to catch [...]
+
+=== Valgrind ===
+
+To debug using Valgrind, enlightenment must be run through Valgrind itself.
valgrind cannot be attached like GDB. This can be done by executing Valgrind in
a console as shown below.
+
+<code bash>
+valgrind --tool=memcheck --db-attach=yes enlightenment
+</code>
+
+Remember, Valgrind is intercepting all memory operations so it will make
things very slow. In fact it is literally emulating a whole CPU and all its
memory accesses. But this makes it thorough and Valgrind can find a lot of
difficult to find problems. When you get a problem, Valgrind will spew out a
complaint and then ask if you want to attach GDB. Often you get a harmless one
of these once when you start something - about reading uninitialized memory
inside XPutImage() - ignore this. It [...]
+
+ ==7072== Syscall param writev(vector[...]) points to uninitialised byte(s)
+ ==7072== at 0x1BC255E8: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BAC66D6: (within /usr/X11R6/lib/libX11.so.6.2)
+ ==7072== by 0x1BAC6986: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
+ ==7072== by 0x1BAAB03C: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
+ ==7072== by 0x1BA9EA6B: (within /usr/X11R6/lib/libX11.so.6.2)
+ ==7072== by 0x1BA9F1D2: XPutImage (in /usr/X11R6/lib/libX11.so.6.2)
+ ==7072== by 0x1B957459: evas_software_x11_x_output_buffer_paste
(evas_x_buffer.c:173)
+ ==7072== by 0x1B955FEA: evas_software_x11_outbuf_flush (evas_outbuf.c:327)
+ ==7072== by 0x1B953EB4: evas_engine_software_x11_output_flush
(evas_engine.c:417)
+ ==7072== by 0x1B93A6A4: evas_render_updates (evas_render.c:298)
+ ==7072== by 0x1B9A0960: _ecore_evas_x_render (ecore_evas_x.c:173)
+ ==7072== by 0x1B9A1EF8: _ecore_evas_x_idle_enter (ecore_evas_x.c:825)
+ ==7072== Address 0x1ED603FC is 596 bytes inside a block of size 38912 allocd
+ ==7072== at 0x1B90459D: malloc (vg_replace_malloc.c:130)
+ ==7072== by 0x1B957200: evas_software_x11_x_output_buffer_new
(evas_x_buffer.c:132)
+ ==7072== by 0x1B955224: evas_software_x11_outbuf_new_region_for_update
(evas_outbuf.c:256)
+ ==7072==
by0x1B953DDA:evas_engine_software_x11_output_redraws_next_update_get
(evas_engine.c:394)
+ ==7072== by 0x1B93A355: evas_render_updates (evas_render.c:210)
+ ==7072== by 0x1B9A0960: _ecore_evas_x_render (ecore_evas_x.c:173)
+ ==7072== by 0x1B9A1EF8: _ecore_evas_x_idle_enter (ecore_evas_x.c:825)
+ ==7072== by 0x1B9725E3: _ecore_idle_enterer_call (ecore_idle_enterer.c:78)
+ ==7072== by 0x1B9746AE: _ecore_main_loop_iterate_internal
(ecore_main.c:477)
+ ==7072== by 0x1B974A2A: ecore_main_loop_begin (ecore_main.c:79)
+ ==7072== by 0x8059BB2: main (e_main.c:551)
+ ==7072==
+ ==7072== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----
+
+To ignore the error just say no (n). You may even get it 2 times if you are
running multihead. Anything else though is a likely candidate for a problem,
when it complains say yes (y) to attach and get us the Valgrind and GDB info
(debug in GDB as above).
+
+Valgrind may complain a lot when enlightenment shuts down about problems
inside exit() these can also be ignored. They look like this:
+
+ ==7072==
+ ==7072== Invalid read of size 4
+ ==7072== at 0x1BB6B16C: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BB6B58C: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BBE6FF6: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC61422: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC61337: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC616C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1B8FEA08: _vgw(float, long double,...)(...)(long
double,...)(short) (vg_intercept.c:55)
+ ==7072== by 0x1BB7F1C5: exit (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BB6997D: __libc_start_main (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x8058AE0: ??? (start.S:102)
+ ==7072== Address 0x1C7BFD98 is 8 bytes inside a block of size 60 free"d
+ ==7072== at 0x1B904B04: free (vg_replace_malloc.c:152)
+ ==7072== by 0x1BB6BD37: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC2A902: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC2A7A6: tdestroy (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC611C1: (within /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BC616C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1B8FEA08: _vgw(float, long double,...)(...)(long
double,...)(short) (vg_intercept.c:55)
+ ==7072== by 0x1BB7F1C5: exit (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x1BB6997D: __libc_start_main (in /lib/tls/libc-2.3.2.so)
+ ==7072== by 0x8058AE0: ??? (start.S:102)
+ ==7072==
+ ==7072== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----
+
+If you see this it is Valgrind's own internal debugging hooks causing problems.
+
+== Nested Xservers for Enlightenment Debugging ==
+
+You will need an Xserver running for enlightenment to display on. The console
will need to be usable even if the window manager is broken (you could also ssh
in and run from that console, or use a text console too). Many people ask how
they can do this and debug a window manager. Here is one way, note, you will
need root access.
+
+<code bash>
+sudo X -ac :1 &
+export DISPLAY=:1
+valgrind --tool=memcheck --db-attach=yes enlightenment
+</code>
+
+This will run an empty Xserver on :1 and switch over to it. You can flip back
to your console with CTRL+ALT+F1 or where ever the console was. You can flip
back to the new Xserver with something like CTRL+ALT+F7.
+
+Enlightenment will be running (very slowly) under Valgrind. Do whatever it is
you do to make a bug happen. When enlightenment "locks up" and doesn't seem to
move (but the mouse does), flip back to the text console where you ran Valgrind
from and see if it is complaining (as per above). If you used ssh then no
switching with CTRL+AL+Fn is needed. You will see Valgrind saying things on the
SSH connection terminal as needed and you can interact with Valgrind there.
+
+== Valgrind Invocation - Xephyr ==
+
+You need to install Xephyr, Valgrind and bash for this to work. First you need
to put the following script (**desktop-xephyr**) in your **PATH**:
+
+<code bash>
+#!/usr/bin/env bash
+if [[ -z "$@" ]]; then
+ echo "you need to supply something to be started in Xephyr"
+ exit 1
+fi
+
+xdisplay()
+{
+ local disp=0;
+ while [ -e "/tmp/.X${disp}-lock" ]; do
+ disp=$(( disp + 1 ));
+ done;
+ echo $disp
+}
+
+#select display
+display=$(xdisplay)
+
+#start xserver
+Xephyr -ac -screen 1600x900 -br 2> /dev/null :$display &
+
+#set display
+export DISPLAY=:$display
+
+#wait for Xephyr to become ready
+sleep 1
+
+#start window manager
+bash -c "$@"
+
+#remove x lock
+rm -fr /tmp/.X${display}-lock
+</code>
+
+Then You need to put a second script in your path that uses the fist. This
script sets some variables and supplies the window manager to run to the fist
script.
+
+<code bash>
+#!/usr/bin/env bash
+# use this if you want to use a separate home for debugging
+#export HOME=/home/$USER/nobackup/HOME-$USER-debug
+# enable core files
+#limit -c unlimited
+# set log file
+log_file="$HOME/e17-xephyr-debug-valgrind.log"
+# set path to installation to use
+e17_install_path=/opt/e17
+
+set_and_log(){
+ export "$1=$2"
+ if [[ $1 == "PATH" ]]; then
+ #show head of PATH only
+ echo "$1=${!1%%:*}: ... " | tee -a $log_file
+ else
+ echo "$1=${!1}" | tee -a $log_file
+ fi
+}
+
+#start logging and set environment
+echo "Enlightenment Valgrind Debugging Log: $(date +%F)" > $log_file
+
+set_and_log LD_LIBRARY_PATH "$e17_install_path/lib"
+set_and_log PATH "$e17_install_path/bin:$PATH"
+
+#override enlightenment path autodetection
+set_and_log E_PREFIX "$e17_install_path"
+if [[ -n "$E_PREFIX" ]]; then
+ set_and_log E_BIN_DIR "$E_PREFIX/bin"
+ set_and_log E_LIB_DIR "$E_PREFIX/lib"
+ set_and_log E_DATA_DIR "$E_PREFIX/share/enlightenment"
+ set_and_log E_LOCALE_DIR "$E_PREFIX/share/locale"
+fi
+
+# build valgrind command
+valgrind_a="--tool=memcheck --db-attach=yes --num-callers=32"
+valgrind_b="--show-reachable=no --read-var-info=yes --leak-check=full"
+valgrind_c="--leak-resolution=high --undef-value-errors=yes"
+valgrind_d="--track-origins=yes --trace-children=yes"
+valgrind="exec valgrind $valgrind_a $valgrind_b $valgrind_c $valgrind_d"
+
+# call the frist script :P
+desktop-xephyr "$valgrind $e17_install_path/bin/enlightenment_start 2>&1 | tee
-a $log_file"
+</code>
+
+Now all you need to do is to call the second script to have some debugging fun.
+
+== Valgrind invocation - Xinit ==
+
+Create a file called .xinitrc-debug in your home with the following content:
+
+<code bash>
+#!/bin/sh
+
+ulimit -c unlimited
-In general it's a good idea to spend some quality time with gdb and do all
this - mail all the output of gdb during one of these "debugging sessions" and
then we can sift through it. it may not mean a lot to you, but it means a world
to us. Sometimes the stack is screwed and well - nothing you can do. Often this
means you need to resort to valgrind to catch things before the stack gets
screwed. this gets a bit more intense, BUT you will need to run E under
valgrind - allowing gdb to attach.
+log_file="$HOME/e17-xinit-debug-valgrind.log"
+#path of you installation
+e17_install_path=/opt/e17
-=== Valgrind ==
+#set vars
+LD_LIBRARY_PATH="$e17_install_path/lib"
+PATH="$e17_install_path/bin:$PATH"
+
+#log to file
+echo "using installation at $e17_install_path"
+echo "LD_LIBRARY_PATH=$LD_LIBRARY_PATH" > $log_file
+echo "PATH=$e17_install_path/bin: ... " >> $log_file
+
+#start e with valgrind
+exec valgrind --tool=memcheck --db-attach=yes --num-callers=32 \
+ --show-reachable=no --read-var-info=yes --leak-check=full \
+ --leak-resolution=high --undef-value-errors=yes \
+ --track-origins=yes --trace-children=yes \
+ $e17_install_path/bin/enlightenment_start 2>&1 | tee -a "$log_file"
+</code>
+
+Now you can start a debugging session via:
+
+<code bash>
+/usr/bin/xinit ~/.xinitrc-debug -- :1 -nolisten tcp
+</code>
=== Perf ===
+Perf is a tool for Linux that can help you identify performance bottlenecks.
This is also part of debugging - to find where CPU time is being spent and
perhaps answering why things are slow. Probably the most useful and simplest
way to use Perf is with Perf top like:
+
+<code bash>
+sudo perf top
+</code>
+
+You will get something like top, but for functions instead of processes:
+
+<code bash>
+Samples: 11K of event 'cycles', Event count (approx.): 401331122 [z]
+Overhead Shared Object Symbol
+ 35.91% libevas.so.1.14.99 [.]
_evas_common_scale_rgba_in_to_out_clip_smooth_mmx
+ 9.60% libevas.so.1.14.99 [.] _op_copy_p_dp_mmx
+ 7.29% libevas.so.1.14.99 [.] _op_blend_p_dp_mmx
+ 2.59% libevas.so.1.14.99 [.] _op_copy_c_dp_mmx
+ 1.90% libevas.so.1.14.99 [.] _op_blend_pas_dp_sse3
+ 0.94% [kernel] [k] clear_page_c
+ 0.74% libevas.so.1.14.99 [.]
evas_common_rgba_image_scalecache_items_ref
+ 0.67% [kernel] [k] shmem_getpage_gfp
+ 0.65% libeo.so.1.14.99 [.] _eo_do_start
+ 0.63% libevas.so.1.14.99 [.] evas_render_updates_internal
+ 0.63% libeo.so.1.14.99 [.] _eo_call_resolve
+ 0.57% [kernel] [k] page_fault
+ 0.54% libc-2.21.so [.] malloc_consolidate
+ 0.52% [kernel] [k] unmapped_area_topdown
+ 0.51% libc-2.21.so [.] _int_malloc
+ 0.45% libeina.so.1.14.99 [.] eina_hash_find_by_hash
+ 0.43% libpthread-2.21.so [.] pthread_spin_trylock
+ 0.42% [kernel] [k] mem_cgroup_begin_page_stat
+ 0.39% libevas.so.1.14.99 [.] evas_common_tilebuf_get_render_rects
+ 0.39% libevas.so.1.14.99 [.] evas_common_scale_rgba_sample_draw
+ 0.37% libevas.so.1.14.99 [.] evas_object_image_render
+ 0.34% [kernel] [k] unmap_single_vma
+ 0.33% libeo.so.1.14.99 [.] _eo_base_event_callback_call
+ 0.33% libevas.so.1.14.99 [.] _evas_common_scalecache_key_cmp
+ 0.31% libeo.so.1.14.99 [.] eo_data_scope_get
+ 0.30% [kernel] [k] _raw_spin_lock
+ 0.29% [kernel] [k] __wake_up_bit
+ 0.29% [kernel] [k] get_page_from_freelist
+ 0.28% libeina.so.1.14.99 [.] _eina_chained_mempool_alloc_in
+ 0.27% libevas.so.1.14.99 [.] evas_render_mapped
+ 0.26% [vdso] [.] __vdso_gettimeofday
+ 0.26% [kernel] [k] __rmqueue
+ 0.26% libeina.so.1.14.99 [.] eina_log_print
+ 0.26% module.so [.] _find_xob.constprop.3
+ 0.24% libeo.so.1.14.99 [.] _eo_do_end
+ 0.23% libpthread-2.21.so [.] pthread_mutex_lock
+ 0.23% [kernel] [k] find_vma
+ 0.22% libeina.so.1.14.99 [.] eina_chained_mempool_free
+ 0.22% libc-2.21.so [.] malloc
+ 0.22% [kernel] [k] __radix_tree_create
+ 0.22% libeina.so.1.14.99 [.] eina_evlog
+ 0.21% libc-2.21.so [.] _int_free
+</code>
+
+So here you can see that almost 34% of CPU execution time is spent in the
''_evas_common_scale_rgba_in_to_out_clip_smooth_mmx'' function from the
''libevas.so.1.14.99'' library. you can narrow down to a specific process
(which is generally most useful) with:
+
+<code bash>
+sudo perf top -p PID
+</code>
+
+And ensure that every sample clears previous sample history (like top does):
+
+<code bash>
+sudo perf top -p PID -z
+</code>
+
+And also try higher sample frequencies (the higher the better the accuracy):
+
+<code bash>
+sudo perf top -p PID -z -F 50000
+</code>
+
+=== Strace ===
+
+Strace is a tool to trace all system calls a process does. This will intercept
and log every interaction with a kernel via a system call. Sometimes this is
very useful to find out what is going on. You can run a process under Strace
like:
+
+<code bash>
+strace myapp
+</code>
+
+You can also attach to an existing process with:
+
+<code bash>
+strace -p PID
+</code>
+
+Be aware that as above with GDB attaching, this may be not allowed by your
kernel so you may have to:
+
+<code bash>
+sudo sysctl -w kernel.yama.ptrace_scope=0
+</code>
+
+Also if it's enlightenment, there already is a process attached
(enlightenment_start) and you need to tell it to stop monitoring:
+
+<code bash>
+kill -SIGUSR1 PID_OF_enlightenment_start
+</code>
+
+You will then be able to attach with Strace. Some useful ways of using Strace:
+
+Write the strace log to a specific file for the process id PID:
+
+<code bash>
+strace -o logfile.txt -p PID
+</code>
+
+Write the strace log to a specific file AND put a timestamp next to every
system call for process PID:
+
+<code bash>
+strace -o logfile.txt -tt -p PID
+</code>
+
+Write the strace log to a specific file AND time how long every system call
takes (to find calls that take too long ans slow things down):
+
+<code bash>
+strace -o logfile.txt -ttt myapp
+</code>
+
+You can combine options like above. See the manual page for Strace for more
details.
+
+----
+
+==== Reporting bugs ====
+
+Use the [[https://phab.enlightenment.org/maniphest/task/create||Maniphest]]
on Phabricator to report bugs. Don't send bug reports and patches to the
Enlightenment mailing list as it strips most patches. Bug reports get lost if
they're only discussed on the mailing list. If there is more discussion needed
add a bug report to the discussion on the mailing list. Always test again to
make sure there really is a reproducible bug before you make a ticket. Make
sure you haven't changed a setti [...]
\ No newline at end of file
--
