Package: xpdf
Version: 3.02-12+squeeze1
Severity: grave
After upgrading to squeeze, xpdf crashes on startup, even without any
input file:
% /usr/bin/xpdf any.pdf
xpdf: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Abgebrochen (core dumped)
I also compiled poppler_0.16.7-2 and xpdf_3.03-8 from unstable
and the problem persists -- there is no crash but an indefinite
hang.
Source inspection and -instrumentation clearly show the explanation,
however I have no patch or even a good suggestion.
There is a class 'GlobalParams' in poppler and in xpdf.
Its ABI is defined in
/usr/include/poppler/GlobalParams.h (A)
and
xpdf-<version>/xpdf/GlobalParams.h (B)
and these 2 files have diverged considerably.
In xpdf, the class is actually instantiated by
globalParams = new GlobalParams(cfgFileName);
in xpdf-<version>/xpdf/xpdf.cc and this uses (A). However, all the
GlobalParams-functions in libpoppler used by xpdf call the ABI (B).
This results in memory corruption, notably of the 'mutex' member.
If you are not convinced, apply the following to GlobalParams.h
in _both_ source packages:
--- poppler-0.16.7/poppler/GlobalParams.cc~ 2010-12-27 21:44:28.000000000
+0100
+++ poppler-0.16.7/poppler/GlobalParams.cc 2012-02-01 16:26:24.000000000
+0100
@@ -74,7 +74,7 @@
#endif
#if MULTITHREADED
-# define lockGlobalParams gLockMutex(&mutex)
+# define lockGlobalParams do { fprintf(stderr, "t=%p
m=%p\n",this,&mutex);gLockMutex(&mutex); }while(0)
# define lockUnicodeMapCache gLockMutex(&unicodeMapCacheMutex)
# define lockCMapCache gLockMutex(&cMapCacheMutex)
# define unlockGlobalParams gUnlockMutex(&mutex)
(also applies to the xpdf version)
When running xpdf such instrumented, I get:
% LD_LIBRARY_PATH=/home/wg/Debian/poppler-0.16.7/poppler/.libs \
~/Debian/xpdf-3.03/build/xpdf.real any.pdf
t=0x18ae010 m=0x18ae188
t=0x18ae010 m=0x18ae188
t=0x18ae010 m=0x18ae188
...
t=0x18ae010 m=0x18ae0f0
This proves that the same mutex object is accessed at two locations.
As said, I have no easy fix. I'd say including the GlobalParams class
and also the globalParams global variable in libpoppler was a horrible
design decision. But going back to a poppler-independent xpdf package
now also doesn't look good. :-(
The problem was already clearly pointed out 8 months ago:
https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/669211
esp. comment 47..
Regards,
Wolfram.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
