Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#48017 - [tilda] Segfault on start
Attached to Project:
Community Packages
Opened by Dan Liew (delcypher) - Wednesday, 03 February 2016, 17:12 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Thursday, 03 March 2016, 17:36 GMT
Opened by Dan Liew (delcypher) - Wednesday, 03 February 2016, 17:12 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Thursday, 03 March 2016, 17:36 GMT
|
DetailsDescription:
Tilda is segfaulting when I try to start it. I don't think my tilda config is relevant because I removed it and tilda still segfaulted. Additional info: * tilda 1.3.1-1 * gnome-shell 3.18.3-3 Steps to reproduce: 1. Run tilda under gnome-shell. I rebuilt tilda with debug symbols and got a backtrace (attached). It looks like the segfault happens when tilda calls into ``XGetModifierMapping()`` in libX11.so from ``reload_modmap()`` in Tilda (src/eggaccelerators.c). So I'm not sure if the bug is in X11 or tilda. |
This task depends upon
Closed by Jaroslav Lichtblau (Dragonlord)
Thursday, 03 March 2016, 17:36 GMT
Reason for closing: No response
Additional comments about closing: Possibly fixed by the latest update. Reopen if necessary.
Thursday, 03 March 2016, 17:36 GMT
Reason for closing: No response
Additional comments about closing: Possibly fixed by the latest update. Reopen if necessary.
gdb.txt
```
#define LockDisplay(d) if ((d)->lock_fns) (*(d)->lock_fns->lock_display)(d)
```
(there are other definitions but I'm not sure which one my build is using)
Examining d here in gdb shows
p dpy
$9 = (Display *) 0x68d800
p dpy->lock_fns
$10 = (struct _XLockPtrs *) 0x7ffff5ad0065
p dpy->lock_fns->lock_display
Cannot access memory at address 0x7ffff5ad0065
Looks like the "lock_fns" field in dpy is not pointing to valid memory. The value of ``dpy`` comes from a call to ``gdk_x11_get_default_xdisplay()`` inside Tilda. I wonder if that's screwing up in someway...