Your message dated Wed, 1 Feb 2012 19:07:37 -0500
with message-id 
<CANTw=mo1bqxey1dt1diqyoht-mcfgiscpbxw0t8uxzua41p...@mail.gmail.com>
and subject line Re: Bug#658264: xpdf totally unusable due to memory corruption 
in globalParams class (namespace conflict with libpoppler)
has caused the Debian Bug report #658264,
regarding xpdf totally unusable due to memory corruption in globalParams class 
(namespace conflict with libpoppler)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
658264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658264
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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.



--- End Message ---
--- Begin Message ---
forcemerge 628591 658264
thanks

On Wed, Feb 1, 2012 at 11:23 AM, Wolfram Gloger wrote:
> Package: xpdf
> Version: 3.02-12+squeeze1
> Severity: grave
>
> After upgrading to squeeze, xpdf crashes on startup, even without any
> input file:

Make sure you've also updated to the expa from squeeze.  This bug has
been reported many times now: #628591, #603153, etc.

Best wishes,
Mike


--- End Message ---

Reply via email to