evince crashes when opening rfc8798.pdf

Bug #1885313 reported by Erik Auerswald
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
poppler (Debian)
Fix Released
Unknown
poppler (Ubuntu)
Fix Released
High
Unassigned

Bug Description

evince reproducabely crashes when opening the file rfc8798.pdf from https://www.rfc-editor.org/rfc/rfc8798.pdf:

$ evince --version
GNOME Document Viewer 3.28.4
$ evince rfc8798.pdf
Segmentation fault (core dumped)
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

Required information:

1) Ubuntu release info:
$ lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04

2) Package version info:
$ apt-cache policy evince
evince:
  Installed: 3.28.4-0ubuntu1.2
  Candidate: 3.28.4-0ubuntu1.2
  Version table:
 *** 3.28.4-0ubuntu1.2 500
        500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     3.28.2-1 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

3) Expected outcome:
I expected evince to successfully open the PDF, allowing me to read the document.

4) Observed behavior:
The default PDF reader of Ubuntu, evince, crashed (reporting a "segmentation fault".

Tags: bionic snap
Revision history for this message
Kai Kasurinen (kai-kasurinen) wrote :

is this duplicate of# 1849888?

Revision history for this message
Erik Auerswald (auerswal) wrote :

Thanks for looking at this bug report.

While this crash looks similar, and all the other problematic RFC documents still crash the evince version in 18.04, there is another report of issues with this specific file on an IETF mailing list:

https://mailarchive.ietf.org/arch/msg/tools-discuss/hgenvnKeP9zX-IBX5FyD6zyEkmI

There it is reported that evince versions 3.30.2 and 3.36.5 cannot open _this_ file (https://www.rfc-editor.org/rfc/rfc8798.pdf). Since the evince in 19.10 that supposedly fixes the issue in bug #1849888 is 3.34.1-1, this bug is with a high probability _not_ a duplicate of said bug. It probably is related, but not the same.

And while initially all new format RFCs crashed evince, in the interim many additional new format RFCs have been published, and not all of them crash evince, not even the version in 18.04.

Looking at the evince versions in 20.04 (3.36.0-2) and the in-development "groovy" (3.36.5-2), this issue may well affect all the bleeding edge Ubuntu versions as well, opposed to #1849888.

Thus I do think that this bug is distinct from #1849888 and not a duplicate.

Thanks,
Erik

Revision history for this message
Erik Auerswald (auerswal) wrote :
Download full text (37.0 KiB)

Apport showed: "evince crashed with SIGSEGV in g_string_free()".

In the other evince crash bug report, I was asked to provide a stack trace. Here it is for this specific (publicly accessible) file:

Stacktrace:
 #0 0x00007fda9d0971b0 in g_string_free () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #1 0x00007fda743b1073 in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
 #2 0x00007fda9d355012 in g_object_unref () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 #3 0x00007fda745f025e in () at /usr/lib/x86_64-linux-gnu/evince/4/backends/libpdfdocument.so
 #4 0x00007fda9f7a4b7a in () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
 #5 0x00007fda9f7a6c02 in () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
 #6 0x00007fda9d09d175 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #7 0x00007fda9ca736db in start_thread (arg=0x7fda6bfff700) at pthread_create.c:463
         pd = 0x7fda6bfff700
         now = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140576091535104, -8300492376050083283, 140576091532416, 0, 94728809145744, 140737090109552, 8321084030215936557, 8321389215404677677}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
         not_first_call = <optimized out>
 #8 0x00007fda9c79c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
ThreadStacktrace:
 .
 Thread 15 (Thread 0x7fda767fc700 (LWP 5914)):
 #0 0x00007fda9c796839 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
 #1 0x00007fda9d0bb87a in g_cond_wait_until () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #2 0x00007fda9d048571 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #3 0x00007fda9d09db14 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #4 0x00007fda9d09d175 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #5 0x00007fda9ca736db in start_thread (arg=0x7fda767fc700) at pthread_create.c:463
         pd = 0x7fda767fc700
         now = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140576267683584, -8300492376050083283, 140576267680896, 0, 94728808515360, 140737090109328, 8321058738764143149, 8321389215404677677}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
         not_first_call = <optimized out>
 #6 0x00007fda9c79c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
 .
 Thread 14 (Thread 0x7fda932ad700 (LWP 5905)):
 #0 0x00007fda9c78fbf9 in __GI___poll (fds=0x5627c4ba6de0, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
         resultvar = 18446744073709551100
         sc_cancel_oldtype = 0
 #1 0x00007fda9d0755c9 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #2 0x00007fda9d075962 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #3 0x00007fda9d887276 in () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
 #4 0x00007fda9d09d175 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #5 0x00007fda9ca736db in start_thread (arg=0x7fda932ad700) at pthread_create.c:463
         pd = 0x7fda932ad700
         now = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {14057674865638...

Revision history for this message
Erik Auerswald (auerswal) wrote :

The problem may be related to how exactly an XML file is embedded inside the RFC PDF documents.
See https://mailarchive.ietf.org/arch/msg/tools-discuss/12Efvwr7KXrgjVTWpaR4pa2hv-U .

Removing the embedded file with 'pdftk rfc8798.pdf cat output rfc8798-no_xml.pdf' results in a PDF that evince can display.

Re-adding the embedded XML file with 'pdftk rfc8798-no_xml.pdf attach_file rfc8798.xml output rfc8798-pdftk-embed.pdf' again results in a PDF that works fine with evince.

Thus it is not the fact that an XML file is embedded that results in the evince crash, but rather the exact procedure used respective the specific result of document processing as done when creating a PDF rendering of an RFC for publication.

This still is a bug in evince, because evince is not supposed to perform invalid memory accesses and crash. Especially since other PDF viewers (e.g., Firefox) can display the PDF without visible problems (MuPDF creates error and warning messages, but still displays the PDF correctly).

Revision history for this message
Erik Auerswald (auerswal) wrote :

A stack trace and some additional crash info with a different recent RFC PDF document:

$ section -i '^(problem|proccmdline|stacktrace|segv|signal)' /var/crash/_usr_bin_evince.1000.crash
ProblemType: Crash
ProcCmdline: evince /tmp/mozilla_auerswald0/rfc8792.pdf
Signal: 11
SegvAnalysis:
 Segfault happened at: 0x7f83eb0061b0 <g_string_free+16>: mov (%rdi),%rbp
 PC (0x7f83eb0061b0) ok
 source "(%rdi)" (0xffffffff) not located in a known VMA region (needed readable region)!
 destination "%rbp" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading unknown VMA
Stacktrace:
 #0 0x00007f83eb0061b0 in g_string_free () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #1 0x00007f83d8103073 in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
 #2 0x00007f83eb2c4012 in g_object_unref () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 #3 0x00007f83d834225e in () at /usr/lib/x86_64-linux-gnu/evince/4/backends/libpdfdocument.so
 #4 0x00007f83ed713b7a in () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
 #5 0x00007f83ed715c02 in () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
 #6 0x00007f83eb00c175 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #7 0x00007f83ea9e26db in start_thread (arg=0x7f83c6456700) at pthread_create.c:463
         pd = 0x7f83c6456700
         now = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140203943880448, -5947558141446818078, 140203943877760, 0, 93867129415456, 140729791250992, 5940683226884634338, 5940760682756601570}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
         not_first_call = <optimized out>
 #8 0x00007f83ea70b88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
StacktraceAddressSignature: /usr/bin/evince:11:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4+6e1b0:/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0+28073:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4+15012:/usr/lib/x86_64-linux-gnu/evince/4/backends/libpdfdocument.so+c25e:/usr/lib/x86_64-linux-gnu/libevview3.so.3.0.0+1db7a:/usr/lib/x86_64-linux-gnu/libevview3.so.3.0.0+1fc02:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4+74175:/lib/x86_64-linux-gnu/libpthread-2.27.so+76db:/lib/x86_64-linux-gnu/libc-2.27.so+12188f
StacktraceTop:
 g_string_free () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
 g_object_unref () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 () at /usr/lib/x86_64-linux-gnu/evince/4/backends/libpdfdocument.so
 () at /usr/lib/x86_64-linux-gnu/libevview3.so.3

Changed in evince (Debian):
status: Unknown → New
Revision history for this message
Erik Auerswald (auerswal) wrote :

To test newer versions of evince I have installed evince via the snap store.

After installation via snap, the snap version can be started using its different program icon (I hope you can understand what I mean, I clicked the "9 dots" icon in the bottom of the task bar on the left, typed "evince", found two versions using different icons, and verified the version via "Show Details").

* 3.34.2+git4.91cbe4fe (from 2020-06-01) crashes with all the RFC PDF documents of this bug and bug #1849888 (which does cast some doubt about that bug being fixed in evince version 3.34.1-1).
* 3.36.6+git2.ce03847a (from 2020-06-27) crashes as well.
* 3.37.2+git65.582b220e (from 2020-06-30) does not start, so result for the problematic RFC PDFs.

So at least _this_ bug is relevant to more recent versions of evince than the 18.04 LTS default.

For the default latest/stable channel the snap package shows the following information:

$ sudo snap info evince
name: evince
summary: Document viewer for popular document formats
publisher: Ken VanDine
store-url: https://snapcraft.io/evince
contact: https://bugs.launchpad.net/ubuntu/+source/evince/+bugs?field.tag=snap
license: unset
description: |
  This is a document viewer for the GNOME desktop.
  It supports the following document formats: PDF, PS, EPS, XPS, DjVu, TIFF,
  DVI (with SyncTeX), and Comic Books archives (CBR, CBT, CBZ, CB7).
commands:
  - evince
  - evince.evince-previewer
  - evince.evince-thumbnailer
snap-id: EDFg87ESUg9sAIlm0Vm5Wmr0LjiEonSm
tracking: latest/stable
refresh-date: today at 13:17 CEST
channels:
  latest/stable: 3.34.2+git4.91cbe4fe 2020-06-01 (434) 8MB -
  latest/candidate: 3.36.6+git2.ce03847a 2020-06-27 (469) 8MB -
  latest/beta: ↑
  latest/edge: 3.37.2+git65.582b220e 2020-06-30 (474) 8MB -
installed: 3.34.2+git4.91cbe4fe (434) 8MB -

tags: added: bionic snap
Revision history for this message
Erik Auerswald (auerswal) wrote :

Trying different free software PDF readers, at least some of which use the same PDF library as evince, does not produce any crashes, but error (or warning) messages for some:

- xpdf works without messages.

- okular works without messages (and can extract the embedded XML).

- Firefox works without messages (and can extract the embedded XML).

- Chrome works without messages.

- pdfdetach (from poppler-utils) can extract the embedded XML file.

- pdftk can extract the XML.

- mupdf works with error and warning messages:
error: Unable to read ICC workflow
warning: Attempt to read Output Intent failed

- gv works with error messages:
   **** Error: ignoring annotation with scale factor of 0
               Output may be incorrect.
Error: Ignoring invalid annotation, output may be incorrect.
   **** Error: ignoring annotation with scale factor of 0
               Output may be incorrect.
Error: Ignoring invalid annotation, output may be incorrect.

The PDF document can be transformed to be acceptable to evince: recreating the PDF with pdftk results in a file that works without errors, even in evince.

But 'mutool clean' does not change anything.

This issue seems to be specific to evince, and affect many versions, including recent ones.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in evince (Ubuntu):
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the current version of Ubuntu.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please perform as much as possible of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Changed in evince (Ubuntu):
importance: Undecided → High
status: Confirmed → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

The focal version of poppler doesn't have the issue as pointed in the Debian report

affects: evince (Ubuntu) → poppler (Ubuntu)
Revision history for this message
Erik Auerswald (auerswal) wrote :

The Debian bug report clearly shows that current unstable still exhibits the bug.

Since Ubuntu is based on unstable, every Ubuntu version, released or in development, still exhibits this bug.

As before, the bug is closed as "fixed", but it is not fixed.

The first possible fix in an LTS release is in 22.04 LTS, if upstream picks the problem up and really fixes it. But since this report seems to show that it already is fixed, they might be lured into thinking it is fixed already. It is not.

Even if we assume that the bug was fixed in 19.10 and then re-appeared, and possibly fixed in some experimental code base, just closing this bug is the surest way to have it re-appear again, because it was never diagnosed and knowingly fixed, but rather happened to not show itself in some random version of the software.

This is very frustrating, and one of the reasons many people still think commercial proprietary software is of better quality than free software (as evidenced, e.g., in the IETF mailing list thread[1]). :-(

[1] https://mailarchive.ietf.org/arch/msg/tools-discuss/vIR4w4Qgj796wcTkiNtK6ljMxss/

The poppler-using xpdf in 18.04 does not have this issue. The tools from poppler-utils work fine with the PDF documents in question. So is it really an issue in poppler? Or rather in the way evince uses poppler? I am not familiar with either code base, so I have no idea.

The GNOME Document Viewer "evince" stands out as the only PDF viewer that actually crashes on those PDFs. Others display the PDFs, with some (e.g., MuPDF and gv) producing warning and/or error messages (but still correctly displaying the document). It also stands out as the default PDF viewer in Ubuntu.

It is not a problem of PDF attachments not working in poppler based PDF viewers, because (using, e.g., pdftk) it is possible to take the problematic PDFs, extract the attachment, create a new PDF without attachment, but otherwise the same contents, and then (re-)attach the file extracted in the first step. The result works fine in evince (and does not produce error nor warning messages in MuPDF).

I am sorry for venting my frustration.

Revision history for this message
Kai Kasurinen (kai-kasurinen) wrote :

Debian unstable has poppler 0.71.0-6
Ubuntu 20.04 has poppler 0.86.1-0ubuntu1

and from debian bug report:
"This appears to have been fixed in libpoppler-glib8_0.85.0-1 inexperimental (or at least, I can't reproduce it in that version)"

affects: evince (Debian) → poppler (Debian)
Revision history for this message
Kai Kasurinen (kai-kasurinen) wrote :

(and this bug is duplicate of bug 1849888)

Ubuntu 19.10 has poppler 0.80.0-0ubuntu1

I guess evince snaps has same poppler as on Ubuntu 18.04:
https://gitlab.gnome.org/GNOME/evince/-/blob/master/build-aux/snap/snapcraft.yaml
https://gitlab.gnome.org/GNOME/evince/-/commit/bffb76a3a9ccdcd5126f57867e941b50f0969dd3

Revision history for this message
Erik Auerswald (auerswal) wrote :

The tested snaps indeed use the same libpoppler version as found in 18.04.

I have created a 20.04 boot medium and tested evince using the "try Ubuntu without installation". This did indeed work, so I stand corrected that the bug is fixed in current Ubuntu releases.

The evince version in 20.04 is 3.36.0 (older than the latest/candidate snap), libpoppler and poppler-utils are version 0.86.1 (newer than in the snaps, or in Debian). So this does look like a poppler rather than evince problem.

Thanks.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@Erik, thanks for confirming it's fixed for you on focal. We should get the poppler version in the evince snap updated

Changed in poppler (Debian):
status: New → Confirmed
Changed in poppler (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.