[Webkit-unassigned] [Bug 128928] New: Improve GDB backtrace generation for GTK/EFL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=128928

           Summary: Improve GDB backtrace generation for GTK/EFL
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: clopez at igalia.com
                CC: abrhm at inf.u-szeged.hu


To current GDB backtrace generation (see https://bugs.webkit.org/show_bug.cgi?id=119338 )
uses the Linux kernel sysctl core_pattern variable to generate the core dumps with a specific name.

  echo "/path/to/cores/core-pid_%p-_-process_%e" > /proc/sys/kernel/core_pattern

The problem is that the executable filename (variable "%e") used in core_pattern
has a limit of 16 characters. See comm variable defined on task_struct at include/linux/sched.h

This causes most of the times that cores generated have a filename on disk
different than the one expected:

Ex: 
core-pid_25409-_-process_WebKitTestRunne
core-pid_25411-_-process_WebKitWebProces
core-pid_25461-_-process_testwebinspecto

                              ^ notice the cut

This causes that the script that launches gdb when a test crashes is unable to find the core.
See for example our current GTK Linux 64-bit Release bot:
http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release/r164108%20%2844874%29/fast/dom/Geolocation/not-enough-arguments-crash-log.txt

In order to fix this the variable "%E" could be used (introduced on https://git.kernel.org/linus/57cc083ad ),
but a more interesting approach is to set core_pattern to pipe to a program
(introduced on https://git.kernel.org/linus/d025c9d ).

This approach of piping the core to a program have some extra benefits:

This program can have much more information about the crashed process since
the /proc/$pid structures are still available when this helper program is executed.
So it can extract easily more information about the crashed program.

Also the tests can set a WEBKIT_CURRENT_TEST="name_test" environment variable
that this program can check (/proc/$pid/environ) in order to detect without
doubt which test was the one that crashed.
This avoid the problem that we currently have when the crashing process
is a child and we don't know its pid. What the current code does is to
just pick the most recent core matching the executable filename. This is
not deterministic in a context where the tests are ran in parallel.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.