On 05/28/2018 at 14:37 UTC, Sérgio Basto wrote:
On Mon, 2018-05-28 at 08:51 +0000, Martin Gansser wrote:
> 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
at RPMFusion bugzilla shows an empty list (i.e., there is no activity
regarding flowblade) while the query
at Red Hat bugzilla shows only 1 item. Therefore giving a brief hint
here in this mailing list isn't totally crazy.
> 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
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
#1 0x00007fffe1ebaf7e in XrmQGetResource (db=0x55555601a1f0,
#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
#4 0x00007fffe19dbb36 in _cairo_xlib_init_screen_font_options (info=0x5555561a0160,
dpy=0x555555a08c00) at cairo-xlib-screen.c:146
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'
) 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).