On 05/28/2018 at 14:37 UTC, Sérgio Basto wrote:
On Mon, 2018-05-28 at 08:51 +0000, Martin Gansser wrote:
> Hi,
>
> the recent flowblade-1.16.0-2.gitd2f153f.fc28 version crahes with a
> segmentation fault.
Please move this question for RPMFusion bugzilla , we might have to
rebuilt it for new MLT
The query
https://bugzilla.rpmfusion.org/buglist.cgi?quicksearch=flowblade
at RPMFusion bugzilla shows an empty list (i.e., there is no activity
regarding flowblade) while the query
https://bugzilla.redhat.com/buglist.cgi?quicksearch=flowblade
at Red Hat bugzilla shows only 1 item. Therefore giving a brief hint
here in this mailing list isn't totally crazy.
> [1]
https://github.com/jliljebl/flowblade/files/2042707/flowblade-f28
> -backtrace.txt
>
> is there a hint at which point the segfault happens ?
The first clue is near the beginning of the file flowblade-f28-backtrace.txt:
=====
Thread 1 "python" received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:65
65 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex);
=====
so the immediate problem is that 'mutex' is a null pointer
("mutex=0x0"),
which pthread_mutex_lock() tried to de-reference.
A more-complete clue is in the last portion of the file
where "Thread 1" is examined more thoroughly:
=====
Thread 1 (Thread 0x7ffff7fbf4c0 (LWP 63747)):
#0 0x00007ffff776fca0 in __GI___pthread_mutex_lock (mutex=0x0) at
../nptl/pthread_mutex_lock.c:65
#1 0x00007fffe1ebaf7e in XrmQGetResource (db=0x55555601a1f0,
names=names@entry=0x7fffffff8ab0, classes=classes@entry=0x7fffffff8abc,
pType=pType@entry=0x7fffffff8a9c, pValue=pValue@entry=0x7fffffff8aa0)
at Xrm.c:2549
#2 0x00007fffe1e96d5a in XGetDefault (dpy=dpy@entry=0x555555a08c00,
prog=prog@entry=0x7fffe1a28281 "Xft", name=name@entry=0x7fffe1a298d4
"antialias") at GetDflt.c:231
#3 0x00007fffe19dbb36 in get_boolean_default (value=<synthetic pointer>,
option=0x7fffe1a298d4 "antialias", dpy=0x555555a08c00) at
cairo-xlib-screen.c:146
#4 0x00007fffe19dbb36 in _cairo_xlib_init_screen_font_options (info=0x5555561a0160,
dpy=0x555555a08c00) at cairo-xlib-screen.c:146
<<snip>>
=====
which shows a call chain with source files and line numbers.
Some environment parameter to the locking protocol for Resources
(perhaps specifically: screen fonts) was left unspecified.
If that is not enough of a hint, then you might try running under 'rr'
(
https://rr-project.org ) which enables "executing backwards"
from the point of the SIGSEGV, and even re-running the *EXACT*
same execution many times under control of gdb. This removes
variability due to timing, and supports reliable debugging
using repeated divide-and-conquer (guess-and-verify).