Segmentation faults galore with poppler 0.82

[mozcelikors]

Hi,
I am using this plugin in one of my projects. I'd have to say it works quite well. However, it crashes a lot. I've tried it on both x86_64 Linux PC and Raspberry Pi 4 (64-bit) OS, Custom Poky/Yocto distro.

Reproducing the crashes:

It seems to me like "loaded" flag does not function correctly. It is almost always true. Shouldn't there be a flag for "document completely loaded"? If the document is not visible and waiting for the load because you zoomed and you select a new file, you get a Segmentation fault. (possibly related to poppler)
Also, after you select .pdf file it also gives Segmentation fault randomly. This does not happen on PC if you wait 5 second between .pdf file selections. If you do it quickly, it even crashes on PC.
"Error (0): Call to Object where the object was type 13, not the expected type 7"

I am using poppler 0.82 with Qt 5.13.0.
Do you have any suggestions or validated versions to avoid such problems? Thank you.

[cyberbobs]

Have you been using the latest version of the plugin? In the last month, I've completely overhauled its code with almost nothing being left from the original version (it also broke API and ABI compatibility, sorry for that).

Document isn't being loaded all at once. Poppler parses the PDF structure and we fill the model (Poppler object) with document data, including number of pages.

Pages are rendered on demand when QML code requests the needed page, an in the requested resolution. That's how we keep memory usage nice and low. Take a look at the supplied PDFView.qml QML component installed with plugin or simply use it directly.

[mozcelikors]

@cyberbobs Hi, I am having the following problem constantly with poppler, if I use PDFView example on Raspberry Pi: Could you share your ideas with me what could be done to overcome this problem?

qml: /home/root/My-Storage/Internal_Storage/pdf-samples/Linux Device Drivers Development_ Develop customized drivers for embedded Linux.pdf
"Error (0): Call to Object where the object was type 13, not the expected type 7"

Thread 11 "QQuickPixmapRea" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f8af9a100 (LWP 2382)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

My sincere thanks.

[cyberbobs]

The problem may be your application and/or plugin and/or poppler-qt5 that are built or run with incompatible versions of Qt.

Quick web search seems to show this message being some bug in Poppler itself. Try newer version maybe?

[pauldotknopf]

I'm experiencing this same issue, using Debian Buster:

Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f09dbbfa700 (LWP 1053))]
(gdb) bt
#0  0x00007f0f2fc727bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f0f2fc5d535 in __GI_abort () at abort.c:79
#2  0x00007f09e145b18e in Page::replaceXRef(XRef*) () at /usr/lib/x86_64-linux-gnu/libpoppler.so.82
#3  0x00007f09e145c8df in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) ()
    at /usr/lib/x86_64-linux-gnu/libpoppler.so.82
#4  0x00007f0a180a96a9 in Poppler::Page::renderToImage(double, double, int, int, int, int, Poppler::Page::Rotation, void (*)(QImage const&, QVariant const&), bool (*)(QVariant const&), bool (*)(QVariant const&), QVariant const&) const () at /usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1
#5  0x00007f0a180a98c0 in Poppler::Page::renderToImage(double, double, int, int, int, int, Poppler::Page::Rotation, void (*)(QImage const&, QVariant const&), bool (*)(QVariant const&), QVariant const&) const () at /usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1
#6  0x00007f0a180a992b in Poppler::Page::renderToImage(double, double, int, int, int, int, Poppler::Page::Rotation) const () at /usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1
#7  0x00007f0a180f1ccc in PageImageProvider::requestImage(QString const&, QSize*, QSize const&) () at /usr/lib/x86_64-linux-gnu/qt5/qml/org/docviewer/poppler/libpopplerPlugin.so
#8  0x00007f0f319d27c1 in  () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x00007f0f319d301e in  () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x00007f0f319d33ed in  () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007f0f3043e489 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007f0f3044146b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007f0f30490103 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007f0f2f6bafee in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f0f2f6bb288 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007f0f2f6bb31c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007f0f3048f727 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007f0f3043d15b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007f0f3028ce76 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f0f319d3476 in  () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#21 0x00007f0f30296a67 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007f0f30126fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#23 0x00007f0f2fd344cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[cyberbobs]

@pauldotknopf This could be an entirely different issue. Are you getting the Error (0): Call to Object where the object was type 13, not the expected type 7 message too? Any specific steps to reproduce this behavior? The example document and parameter values of the PageImageProvider::requestImage call before the crash could also help.

Not trying to waive the issue, but this specific place in the source seems trivial enough to not screw it up, except the obvious lack of page number check before requesting its render.

[pauldotknopf]

Yes, I did get Error (0): Call to Object where the object was type 13, not the expected type 7 in the standard output of the app as well.

This happens when we navigate the plugin quickly (go through pages fast), and then dispose of the page. There is likely some async stuff not being cancelled.