Bug 1981108
Summary: | evince crashes with a normal pdf file as input. | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Leon Fauster <leonfauster> | ||||
Component: | poppler | Assignee: | Marek Kašík <mkasik> | ||||
Status: | CLOSED ERRATA | QA Contact: | Radek Duda <rduda> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 8.4 | CC: | rduda, tpelka | ||||
Target Milestone: | beta | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | poppler-20.11.0-3.el8 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-11-09 17:40:50 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Leon Fauster
2021-07-11 14:01:02 UTC
Hi, it is hard to debug this without a PDF which triggers the issue so I'll ask you to show me backtrace from valgrind. First, you'll need to install debug packages. I hope that you can do that this way: "dnf debuginfo-install evince gtk3 glib2 poppler" Then install valgrind package please "dnf install valgrind" Then run evince inside valgrind (replacing the the-document.pdf with actual document name): "valgrind --track-origins=yes --num-callers=80 --malloc-fill=0xfa --free-fill=0xfb --trace-children=yes --read-var-info=yes --error-limit=no evince the-document.pdf &> ./valgrind.log" It will be very slow but it will give us better view of what is going on. Also, could you have a look at "Title" and "Author" of the PDF? Evince probably crashes when saving this info as metadata. So I would need to know whether there is something unusual (as some non-standard characters etc.). "pdfinfo the-document.pdf | grep -e Author -e Title" pdfinfo is part of poppler-utils package. (In reply to Marek Kašík from comment #1) > Also, could you have a look at "Title" and "Author" of the PDF? Evince > probably crashes when saving this info as metadata. So I would need to know > whether there is something unusual (as some non-standard characters etc.). > > "pdfinfo the-document.pdf | grep -e Author -e Title" > > pdfinfo is part of poppler-utils package. It seems to be plain ASCII: $ pdfinfo nonpublic_test.pdf |egrep 'Author|Title|Subject|Keywords|Producer|CreationDate' > pdfinfos.txt $ file pdfinfos.txt pdfinfos.txt: ASCII text $ cat pdfinfos.txt |tr -d [A-Z][a-z][0-9] : // . : : ,//,,. , : : : :: I also deleted this content without any change to the coredumps $ cp nonpublic_test.pdf nonpublic_test_deltitle.pdf $ /usr/bin/exiftool -all= --ICC_Profile:all nonpublic_test_deltitle.pdf $ pdfinfo nonpublic_test_deltitle.pdf |egrep 'Author|Title|Subject|Keywords|Producer|CreationDate' (manually annotated: empty output) $ evince nonpublic_test_deltitle.pdf (manually annotated: dumped core here again) YFI: The ExifTool PDF edits are reversible. So the data may be still in the file. (In reply to Marek Kašík from comment #1) > Then run evince inside valgrind (replacing the the-document.pdf with actual > document name): > > "valgrind --track-origins=yes --num-callers=80 --malloc-fill=0xfa > --free-fill=0xfb --trace-children=yes --read-var-info=yes --error-limit=no > evince the-document.pdf &> ./valgrind.log" > I added --show-error-list=yes $ cat valgrind.log ==3908== Memcheck, a memory error detector ==3908== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3908== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info ==3908== Command: evince nonpublic_test.pdf ==3908== ==3908== Thread 6 EvJobScheduler: ==3908== Invalid read of size 4 ==3908== at 0x7F02BB8: g_date_time_to_instant (gdatetime.c:734) ==3908== by 0x7F02BB8: g_date_time_to_unix (gdatetime.c:2502) ==3908== by 0x19656DB8: ??? (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x1964C40A: poppler_document_get_attachments (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x19420D3D: ??? (in /usr/lib64/evince/4/backends/libpdfdocument.so) ==3908== by 0x50A36FD: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x50A5821: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x7F41E59: g_thread_proxy (gthread.c:784) ==3908== by 0x8786149: start_thread (in /usr/lib64/libpthread-2.28.so) ==3908== by 0x8A9ADC2: clone (in /usr/lib64/libc-2.28.so) ==3908== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==3908== ==3908== ==3908== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==3908== Access not within mapped region at address 0x10 ==3908== at 0x7F02BB8: g_date_time_to_instant (gdatetime.c:734) ==3908== by 0x7F02BB8: g_date_time_to_unix (gdatetime.c:2502) ==3908== by 0x19656DB8: ??? (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x1964C40A: poppler_document_get_attachments (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x19420D3D: ??? (in /usr/lib64/evince/4/backends/libpdfdocument.so) ==3908== by 0x50A36FD: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x50A5821: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x7F41E59: g_thread_proxy (gthread.c:784) ==3908== by 0x8786149: start_thread (in /usr/lib64/libpthread-2.28.so) ==3908== by 0x8A9ADC2: clone (in /usr/lib64/libc-2.28.so) ==3908== If you believe this happened as a result of a stack ==3908== overflow in your program's main thread (unlikely but ==3908== possible), you can try to increase the size of the ==3908== main thread stack using the --main-stacksize= flag. ==3908== The main thread stack size used in this run was 8388608. ==3908== ==3908== HEAP SUMMARY: ==3908== in use at exit: 7,411,381 bytes in 83,157 blocks ==3908== total heap usage: 435,452 allocs, 352,295 frees, 33,521,745 bytes allocated ==3908== ==3908== LEAK SUMMARY: ==3908== definitely lost: 20,829 bytes in 41 blocks ==3908== indirectly lost: 21,935 bytes in 931 blocks ==3908== possibly lost: 13,680 bytes in 131 blocks ==3908== still reachable: 6,078,609 bytes in 73,676 blocks ==3908== of which reachable via heuristic: ==3908== length64 : 16,792 bytes in 211 blocks ==3908== newarray : 2,672 bytes in 87 blocks ==3908== suppressed: 32 bytes in 1 blocks ==3908== Rerun with --leak-check=full to see details of leaked memory ==3908== ==3908== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==3908== ==3908== 1 errors in context 1 of 1: ==3908== Invalid read of size 4 ==3908== at 0x7F02BB8: g_date_time_to_instant (gdatetime.c:734) ==3908== by 0x7F02BB8: g_date_time_to_unix (gdatetime.c:2502) ==3908== by 0x19656DB8: ??? (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x1964C40A: poppler_document_get_attachments (in /usr/lib64/libpoppler-glib.so.8.19.0) ==3908== by 0x19420D3D: ??? (in /usr/lib64/evince/4/backends/libpdfdocument.so) ==3908== by 0x50A36FD: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x50A5821: ??? (in /usr/lib64/libevview3.so.3.0.0) ==3908== by 0x7F41E59: g_thread_proxy (gthread.c:784) ==3908== by 0x8786149: start_thread (in /usr/lib64/libpthread-2.28.so) ==3908== by 0x8A9ADC2: clone (in /usr/lib64/libc-2.28.so) ==3908== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==3908== --3908-- --3908-- used_suppression: 1 dtv-addr-tail /usr/libexec/valgrind/default.supp:1450 suppressed: 32 bytes in 1 blocks ==3908== ==3908== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) BTW: The pdf document can be opened in Fedora 34's evince ... I am able to reproduce the issue now. I've attached a file inside a PDF and modified its ModDate and CreationDate to contain non-existing dates. This causes passing NULL to "g_date_time_to_unix()" and the crash at RHEL 8, it does not crash at Fedora 34 since it placed assert in the function so it just shows a warning. Could you check values of ModDate and CreationDate in your PDF? If they are not readable there you maybe need to uncompress streams in the PDF by "qpdf --stream-data=uncompress input.pdf output.pdf". Created attachment 1805938 [details]
reproducer
Great that you can reproduce it. Indeed my PDF file (both original and uncompressed) does not have any ModDate entry ! (In reply to Leon Fauster from comment #7) > Great that you can reproduce it. Indeed my PDF file (both original and > uncompressed) does not have any ModDate entry ! Is there any CreationDate? The backtrace I get is the same as yours. Hi, I've prepared a COPR repository with a fix for the issue I see. Could you try to update poppler from it and test whether it fixes the crash? You can enable it by running: dnf copr enable mkasik/poppler-test-build and then run the update: dnf update poppler The COPR repository comes from here: https://copr.fedorainfracloud.org/coprs/mkasik/poppler-test-build/ (In reply to Marek Kašík from comment #8) > (In reply to Leon Fauster from comment #7) > > Great that you can reproduce it. Indeed my PDF file (both original and > > uncompressed) does not have any ModDate entry ! > > Is there any CreationDate? > > The backtrace I get is the same as yours. It has only the CreationDate: $ pdfinfo Q1.pdf|grep -i date CreationDate: Mon Apr 19 23:55:54 2021 CEST (In reply to Marek Kašík from comment #10) > I've prepared a COPR repository with a fix for the issue I see. Could you > try to update poppler from it and test whether it fixes the crash? > > You can enable it by running: > > dnf copr enable mkasik/poppler-test-build > > and then run the update: > > dnf update poppler > > The COPR repository comes from here: > https://copr.fedorainfracloud.org/coprs/mkasik/poppler-test-build/ Hey Marek, this worked! Evince does not crash anymore and displays the PDF document. JFI: When looking into the "properties" of the document in Evince the "ModDate" field (that is missing in the PDF file) has the epoch time as value displayed. So, it seems that the patch addresses this issue. Thanks! Great! Thank you for testing it. You'll need to downgrade the poppler and remove the COPR repository before updating to official release once ready though (it will take some time yet). You can do it this way: dnf downgrade poppler dnf copr remove mkasik/poppler-test-build I reproduced evince crash with attached pdf file (poppler-20.11.0-2.el8.x86_64) Then I installed poppler-20.11.0-3.el8.x86_64 and file was successfully opened by evince. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (evince bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4155 |