Ubuntu
overlay-scrollbar package

sushi-start crashed with SIGSEGV in __pthread_mutex_lock()

Bug #931381 reported by gogo on 2012-02-13

36

This bug affects 5 people

Affects		Status	Importance	Assigned to	Milestone
	overlay-scrollbar (Ubuntu)	Confirmed	Medium	Unassigned

Bug Description

sushi-start crashed

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: overlay-scrollbar 0.2.14-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-15.24-generic 3.2.5
Uname: Linux 3.2.0-15-generic x86_64
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Mon Feb 13 12:23:35 2012
ExecutablePath: /usr/lib/gnome-sushi/sushi-start
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120207)
PackageArchitecture: all
ProcCmdline: /usr/lib/gnome-sushi/sushi-start
ProcEnviron:
SHELL=/bin/bash
PATH=(custom, no user)
LANG=hr_HR.UTF-8
SegvAnalysis:
Segfault happened at: 0x7f71566e1e84 <pthread_mutex_lock+4>: mov 0x10(%rdi),%esi
PC (0x7f71566e1e84) ok
source "0x10(%rdi)" (0x656d656863732d82) not located in a known VMA region (needed readable region)!
destination "%esi" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: overlay-scrollbar
StacktraceTop:
pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
XrmQGetResource () from /usr/lib/x86_64-linux-gnu/libX11.so.6
XGetDefault () from /usr/lib/x86_64-linux-gnu/libX11.so.6
?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
Title: sushi-start crashed with SIGSEGV in pthread_mutex_lock()
UpgradeStatus: Upgraded to precise on 2012-02-12 (1 days ago)
UserGroups: adm cdrom debian-tor dip disk lpadmin plugdev sambashare sudo

Tags:

Revision history for this message

gogo (trebelnik-stefina) wrote on 2012-02-13:

#1

Dependencies.txt Edit (2.3 KiB, text/plain; charset="utf-8")
Disassembly.txt Edit (1.0 KiB, text/plain; charset="utf-8")
ProcMaps.txt Edit (74.2 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (822 bytes, text/plain; charset="utf-8")
Registers.txt Edit (872 bytes, text/plain; charset="utf-8")
Stacktrace.txt Edit (16.7 KiB, text/plain; charset="utf-8")
ThreadStacktrace.txt Edit (18.4 KiB, text/plain; charset="utf-8")

visibility:

private → public

Revision history for this message

Apport retracing service (apport) wrote on 2012-02-13:

#2

StacktraceTop:
__pthread_mutex_lock (mutex=0x7fff36fcab30) at pthread_mutex_lock.c:50
XrmQGetResource (db=0x1b899e0, names=<optimized out>, classes=<optimized out>, pType=0x7fff36fcab5c, pValue=0x7fff36fcab30) at ../../src/Xrm.c:2543
XGetDefault (dpy=0x1b295a0, prog=0x7f7156ed0a27 "Xft", name=0x7f7156ed0a2b "antialias") at ../../src/GetDflt.c:254
get_boolean_default (value=<synthetic pointer>, option=0x7f7156ed0a2b "antialias", dpy=0x1b295a0) at /build/buildd/cairo-1.10.2/src/cairo-xlib-screen.c:95
_cairo_xlib_init_screen_font_options (info=0x2204c00, dpy=0x1b295a0) at /build/buildd/cairo-1.10.2/src/cairo-xlib-screen.c:143

Revision history for this message

Apport retracing service (apport) wrote on 2012-02-13: Stacktrace.txt

#3

Stacktrace.txt Edit (43.0 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2012-02-13: ThreadStacktrace.txt

#4

ThreadStacktrace.txt Edit (46.4 KiB, text/plain)

Changed in overlay-scrollbar (Ubuntu):
importance:	Undecided → Medium
summary:	- sushi-start crashed with SIGSEGV in pthread_mutex_lock() + sushi-start crashed with SIGSEGV in __pthread_mutex_lock()
tags:	removed: need-amd64-retrace

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-02-23:

#5

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in overlay-scrollbar (Ubuntu):
status:	New → Confirmed

Revision history for this message

Jeroen Ost (jeroen-ost-8) wrote on 2012-04-12:

#6

I ran into the same problem with a self written libwebkitgtk program, also for the 'antialias' property which is asked in the same path XGetDefault call from cairo-xlib-screen.c .

The segfault seems to always occur in the calls from libcairo2, more precisely cairo-xlib-screen.c function _cairo_xlib_init_screen_font_options (Display *dpy, cairo_xlib_screen_t *info)

it's always one of the get_integer_default or get_boolean_default calls.
If I write down the values in a successful run (for my system that is
    cairo_bool_t xft_hinting=1;
    cairo_bool_t xft_antialias=TRUE;
    int xft_hintstyle=0;
    int xft_lcdfilter=1;
)
and prevent the calls from happening, the segfault goes away. (I create a patched libcairo2)
Anyone else who wants to try this (on oneiric):
sudo apt-get source libcairo2
sudo apt-get build-dep libcairo2
cd cairo-1.10.2/
modify src/cairo-xlib-screen.c so that values above are used (line 135) and comment out all 3 function calls for get_integer_default or get_boolean_default.

sudo dpkg-buildpackage -rfakeroot -b -nc
cd ..
sudo dpkg -i libcairo2_1.10.2-6ubuntu3_i386.deb libcairo2-dbg_1.10.2-6ubuntu3_i386.deb libcairo2-dev_1.10.2-6ubuntu3_i386.deb libcairo-gobject2_1.10.2-6ubuntu3_i386.deb libcairo-script-interpreter2_1.10.2-6ubuntu3_i386.deb

As to what is the clean fix I'm not sure. Is there some requirement on pthread synchronization that cairo doesn't meet when calling XGetDefault, or is it a regular Xorg bug ?

I also noticed /etc/xdg/xfce4/Xft.xrdb allows you to set defaults but that didn't seem to help me (even though I'm running xfce4/xubuntu)

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.