xpdf.real assert failure: xpdf.real: tpp.c:62: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.

Bug #1205732 reported by Logan Rosen
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
xpdf (Ubuntu)
Fix Released
High
Dmitry Shachnev

Bug Description

I attempted to open a file from Launchpad [1] with xpdf, and it aborted.

[1] https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1054482/+attachment/3354416/+files/atuer.pdf

ProblemType: Crash
DistroRelease: Ubuntu 13.10
Package: xpdf 3.03-11ubuntu1
ProcVersionSignature: Ubuntu 3.10.0-5.15-generic 3.10.2
Uname: Linux 3.10.0-5-generic x86_64
ApportVersion: 2.11-0ubuntu1
Architecture: amd64
AssertionMessage: xpdf.real: tpp.c:62: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.
Date: Sat Jul 27 18:42:58 2013
ExecutablePath: /usr/bin/xpdf.real
InstallationDate: Installed on 2012-08-21 (340 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120821)
MarkForUpload: True
ProcCmdline: xpdf.real atuer.pdf
Signal: 6
SourcePackage: xpdf
StacktraceTop:
 __assert_fail_base (fmt=0x7f834b855578 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f83495f7d10 "new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)", file=file@entry=0x7f83495f7d04 "tpp.c", line=line@entry=62, function=function@entry=0x7f83495f7de0 <__PRETTY_FUNCTION__.8353> "__pthread_tpp_change_priority") at assert.c:92
 __GI___assert_fail (assertion=assertion@entry=0x7f83495f7d10 "new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)", file=file@entry=0x7f83495f7d04 "tpp.c", line=line@entry=62, function=function@entry=0x7f83495f7de0 <__PRETTY_FUNCTION__.8353> "__pthread_tpp_change_priority") at assert.c:101
 __pthread_tpp_change_priority (previous_prio=previous_prio@entry=-1, new_prio=new_prio@entry=0) at tpp.c:60
 __pthread_mutex_lock_full (mutex=0x7f834e00a130) at pthread_mutex_lock.c:420
 GlobalParams::getVectorAntialias() () from /usr/lib/x86_64-linux-gnu/libpoppler.so.37
Title: xpdf.real assert failure: xpdf.real: tpp.c:62: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo

Related branches

Revision history for this message
Logan Rosen (logan) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceTop.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in xpdf (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Logan Rosen (logan)
information type: Private → Public
Revision history for this message
Graham Inggs (ginggs) wrote :

I've just tested xpdf 3.03-11ubuntu2 and the same error occurs.
Even running 'xpdf' with no arguments core dumps.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in xpdf (Ubuntu):
status: New → Confirmed
Changed in xpdf (Ubuntu):
status: Confirmed → In Progress
importance: Medium → High
assignee: nobody → Dmitry Shachnev (mitya57)
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

I've spent a big amount of today trying to debug this issue.

Here on i386 I get:

#7 0xb7bdbe13 in GlobalParams::getVectorAntialias (this=0x8005c008) at GlobalParams.cc:1701
1701 lockGlobalParams;
(gdb) p this
$1 = (GlobalParams * const) 0x8005c008
(gdb) p globalParams
$2 = (GlobalParams *) 0x8005c008
(gdb) p mutex.__data.__kind
$3 = -2146993984 ### BROKEN ###
(gdb) p &mutex
$4 = (GooMutex *) 0x8005c0c8
(gdb) p globalParams->mutex.__data.__kind
$5 = 1
(gdb) p &globalParams->mutex
$6 = (GooMutex *) 0x8005c0f8

For some reason, "mutex" is 6 bytes behind "globalParams->mutex" (though "this" and "globalParams" are the same object).

The attached patch (against poppler) partially works around the issue by explicitly using "globalParams" object. However, this only helps when running xpdf without any arguments. When trying to open the file, I still have the same crash, and "globalParams->mutex" is broken.

Any thoughts?

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

For those who want to use Xpdf until we have the fix, try running it under Valgrind — it runs successfully here.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xpdf - 3.03-11ubuntu3

---------------
xpdf (3.03-11ubuntu3) saucy; urgency=low

  * Use GlobalParams module from Poppler and disable all settings that
    are not available in Poppler (LP: #943195, #1205732).
  * Remove fix-622877.patch and one hunk in
    track_libpoppler43_api_changes.patch that are no longer needed.
 -- Dmitry Shachnev <email address hidden> Wed, 04 Sep 2013 15:06:52 +0400

Changed in xpdf (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

I've applied an ugly fix that just makes Xpdf use Poppler's GlobalParams module. The downside is that keybindings no longer work, but it's at least better than having Xpdf that doesn't start.

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

Nevermind, in 3.03-11ubuntu5 keybindings now work again.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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