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).
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/GHXFCL2JKCAYIHNTRFZZVTCZK6NHBUFA/
