Bug#945188: xpdf: memory leak when changing page

[Adam Sampson]

> This issue might be in the package since poppler-0.71.patch.
> This patch makes some changes how containers get accessed.

I've had a look at this in xpopple today (my Poppler-ified version of
xpdf; see #977182 or http://offog.org/code/xpopple/).

Previously I'd kept a copy of GooList in xpopple when it was removed
from Poppler (renamed to XPDFList), but I've now reworked the remaining
GooList-using code to use std::vector instead, without using raw
pointers -- in the places where the items do need to be owning pointers
I've used vector> instead, which makes the code quite a bit
simpler.

My XPDFParams code would probably be tricky to backport to Debian's
current version, but you might be able to take the patches for the other
GooLists as is...

Cheers,

-- 
Adam Sampson  

Bug#945188: xpdf: memory leak when changing page

[Vincent Lefevre]

Control: reopen -1
Control: found -1 3.04-14

On 2019-11-21 00:05:56 +0100, Vincent Lefevre wrote:
> When one changes the displayed page (e.g. with PageDown or PageUp),
> xpdf takes more memory, even if the page has already been displayed
> (thus this is not due to caching).
> 
> For instance, consider /usr/share/pari/doc/users.pdf from pari-doc.
> It starts with 32 MB. And each time I do a PageDown or PageUp, it
> takes an additional 16 MB.

I still get the same problem, while the patch at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945188#10

was fixing the issue.

On a PDF file with big images, this quickly makes the machine start
swapping.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#945188: xpdf: memory leak when changing page

[Vincent Lefevre]

On 2019-11-21 20:15:24 +0100, Bernhard Übelacker wrote:
> This patch makes some changes how containers get accessed.

Thanks. I confirm that it solves the problem on my side.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#945188: xpdf: memory leak when changing page

[Bernhard Übelacker]

Control: tags -1 + patch


Dear Maintainer,
I tried to have a look and found something.

This issue might be in the package since poppler-0.71.patch.
This patch makes some changes how containers get accessed.

Following I found and tried to change in attached patch:
- std::erase, std::clear, std::remove:
  These methods of STL containers containing pointer to objects do
  not delete the objects pointed to.
- In continuousView in PDFCore::addPage the next page was inserted
  at the first position.

For running with valgrind it was nice to have the additional cflag
HAVE_XTAPPSETEXITFLAG set, as then the application cleans up
instead of just exit(0).

Bug #942086 and #926501 might be related.

Kind regards,
Bernhard

# Unstable amd64 qemu VM 2019-11-21

apt update
apt dist-upgrade


apt install dpkg-dev devscripts quilt systemd-coredump xserver-xorg lightdm 
openbox xterm htop mc gdb valgrind heaptrack heaptrack-gui pari-doc xpdf 
xpdf-dbgsym libfreetype6-dbgsym libpoppler82-dbgsym
apt build-dep xpdf



mkdir /home/benutzer/source/xpdf/orig -p
cd/home/benutzer/source/xpdf/orig
apt source xpdf
cd

mkdir /home/benutzer/source/libpoppler82/orig -p
cd/home/benutzer/source/libpoppler82/orig
apt source libpoppler82
cd




export LANG=C
export DISPLAY=:0

/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

# ~10 times next page and previous page - memory usage doubles.





##


# wget 
https://github.com/WuBingzheng/memleax/releases/download/v1.1.1/memleax_1.1.1-1_amd64.deb
# dpkg -i memleax_1.1.1-1_amd64.deb
# memleax $(pidof xpdf.real)
# gdb -q --args xpdf.real /usr/share/pari/doc/users.pdf
#   Reading symbols from 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug...
# memleax -d 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug 
$(pidof xpdf.real)
# Had no output at all.


##


script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'

script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
--leak-check=full --show-reachable=yes --leak-resolution=high --num-callers=100 
--trace-children=yes /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'


==35071== 34,438,272 bytes in 11 blocks are possibly lost in loss record 1,608 
of 1,608
==35071==at 0x483577F: malloc (vg_replace_malloc.c:309)
==35071==by 0x11F82C: gmalloc (gmem.h:41)
==35071==by 0x11F82C: gmallocn (gmem.h:115)
==35071==by 0x11F82C: XPDFCore::updateTileData(PDFCoreTile*, int, int, int, 
int, bool) (XPDFCore.cc:1276)
==35071==by 0x119C5C: PDFCore::clippedRedrawRect(PDFCoreTile*, int, int, 
int, int, int, int, int, int, int, int, bool, bool) (PDFCore.cc:2171)
==35071==by 0x119D5F: PDFCore::redrawCbk(void*, int, int, int, int, bool) 
(PDFCore.cc:2068)
==35071==by 0x1166F5: dump (CoreOutputDev.cc:53)
==35071==by 0x1166F5: CoreOutputDev::dump() (CoreOutputDev.cc:46)
==35071==by 0x4E6016F: Gfx::go(bool) (Gfx.cc:827)
==35071==by 0x4E6049D: Gfx::display(Object*, bool) (Gfx.cc:714)
==35071==by 0x4EB6940: Page::displaySlice(OutputDev*, double, double, int, 
bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, 
void*), void*, bool) (Page.cc:548)
==35071==by 0x11AD82: PDFCore::needTile(PDFCorePage*, int, int) 
(PDFCore.cc:924)
==35071==by 0x11BBB0: PDFCore::update(int, int, int, double, int, bool, 
bool, bool) (PDFCore.cc:724)
==35071==by 0x122380: XPDFCore::update(int, int, int, double, int, bool, 
bool, bool) (XPDFCore.cc:297)
==35071==by 0x11734E: gotoNextPage (PDFCore.cc:963)
==35071==by 0x11734E: PDFCore::gotoNextPage(int, bool) (PDFCore.cc:947)
==35071==by 0x1223E1: XPDFCore::gotoNextPage(int, bool) (XPDFCore.cc:325)
==35071==by 0x127937: XPDFViewer::nextPageCbk(_WidgetRec*, void*, void*) 
(XPDFViewer.cc:2451)
==35071==by 0x49361BA: ??? (in /usr/lib/x86_64-linux-gnu/libXm.so.4.0.4)
==35071==by 0x505F4DE: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5060552: _XtTranslateEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038479: XtDispatchEventToWidget (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038ED1: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5039030: XtDispatchEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5044CFF: XtAppProcessEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x503944C: XtAppMainLoop (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x11626C: main (xpdf.cc:310)



gdb -q --args /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

set width 0
set pagination off
directory /home/benutzer/source/xpdf/orig/xpdf-3.04/xpdf
directory /home/benutzer/source/libpoppler82/orig/poppler-0.71.0
b CoreOutputDev::CoreOutputDev
y
run


###


try1:

debian/rules
HAVE_XTAPPSETEXITFLAG 
--> XPDFApp::~XPDFApp get now reached

xpdf/XPDFApp.cc
void 

Bug#945188: xpdf: memory leak when changing page

[Vincent Lefevre]

Package: xpdf
Version: 3.04-13
Severity: important

When one changes the displayed page (e.g. with PageDown or PageUp),
xpdf takes more memory, even if the page has already been displayed
(thus this is not due to caching).

For instance, consider /usr/share/pari/doc/users.pdf from pari-doc.
It starts with 32 MB. And each time I do a PageDown or PageUp, it
takes an additional 16 MB.

One can easily end up filling the memory of the machine. This happened
to me several times, with my machine completely freezing for several
minutes, until I found out that xpdf was the main cause.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xpdf depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-19
ii  libpaper1 1.1.28+b1
ii  libpoppler82  0.71.0-6
ii  libstdc++69.2.1-19
ii  libx11-6  2:1.6.8-1
ii  libxm42.3.8-2
ii  libxt61:1.1.5-1+b3

Versions of packages xpdf recommends:
ii  cups-bsd2.3.0-7
ii  gsfonts-x11 0.27
ii  poppler-data0.4.9-2
ii  poppler-utils   0.71.0-6
ii  sensible-utils  0.0.12

xpdf suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)