You're right - it is indeed the X server that crashes.
I've only noticed the problem recently, but that doesn't necessarily mean
that it's a new problem.
Changing the font as you suggested doesn't have any effect, so I
don't think it's the font rendering. The backtrace from Xorg.0.log
[ 10759.847] (EE) Backtrace:
[ 10759.860] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x55662f3b7e05]
[ 10759.861] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fe2d501b8e0]
[ 10759.861] (EE) 2: ? (?+0x0) [0x7fe2c169003a]
[ 10759.861] (EE)
[ 10759.861] (EE) Segmentation fault at address 0x7fe2c28be000
I guess I'd better re-report the bug. This report can be closed.
Thanks for the tip about changing the fonts, though. The new default
fonts are too large for my liking so I'll play around and find a suitable
smaller typeface. The fixed fonts are missing some characters.
All the best,
On 2021-11-30 01:13:23 +0000, Adam Sampson wrote:
> Mark Hindley <mark@???> writes:
> > Thanks. Notwithstanding this, you should report this issue directly to
> > Debian. Devuan uses Debian's xpdf packages directly without
> > recompilation.
> (I'm the maintainer of xpopple, which is the upstream source for
> Debian's xpdf these days.)
> The problem reported here is not that xpdf crashes, it's that the window
> manager crashes. That shouldn't happen regardless of what client
> programs do, so this isn't a fault in xpdf itself.
> Are you certain that it's the window manager crashing, and not the X
> server? The latter seems more likely -- when you're scrolling the table
> of contents, it's not changing any properties of the window (which would
> cause the WM to do something), but it is doing lots of X drawing
> operations to scroll the list and render new text. It'd be worth having
> a look at the X server log after a crash (/var/log/Xorg.0.log.old).
> If it's only just started doing this, one change we've made recently in
> xpdf is to enable Xft font support by default. You could try setting the
> following X resource (with xrdb):
> Xpdf*font: fixed
> This should make it use a bitmap font for the interface instead, which
> will be rendered using X's core font support rather than alpha
> blending. If that fixes it, then it could be a problem with your
> graphics driver's implementation of the RENDER extension.
> Adam Sampson <ats@???> <http://offog.org/>