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

-- 


Reply via email to