evince crashes when highlighting text at line end

Created an attachment (id=4864)
File on which the behavior is easily duplicated

This file allows you to duplicate this bug pretty easily. I have so far failed
to duplicate this bug with other PDF files (I've tried about 3), so maybe this
file is just h4xed.

The irony is delicious...

Thanks for your bug. It's known upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=4481

that may be fixed with poppler 0.4.3/dapper

Still crashes with 0.5.1, see bug #41661 for another document which causes the issue, as well as a valgrind dump (just showing that it's a font which was cleared by Gfx::popResources when still present in the state instance variable, I think).

evince/poppler seems happier with this patch applied. It's not completely rigorous w.r.t. not having any font references when the refcount goes to zero, but it might be Good Enough.

This should also fix bug #36747, I think. Remove the change in TextOutputDev.cc, try selecting lots of text, and soon the crash seen in that bug wil be found.

The change in poppler-page.cc is a random addition which hasn't been proven to kill any kittens yet, but it IS a mismatched new[]/delete bug. This change could be removed though.

 poppler (0.5.1-0ubuntu7) dapper; urgency=low
 .
   * Add debian/patches/003_refcount.patch: Fix reference counting. Thanks to
     Gary Coady for the patch! Closes: LP#24970

I just want to say that this patch scares me.

You also have to bump the SONAME, because you've changed
the size of GfxFont.

I just prompted the Debian maintainer to tell upstream to bump the SOVER, which he's done here:

https://bugs.freedesktop.org/show_bug.cgi?id=7054

It's probably too late for us to do so, so the hideous hack of just rebuilding everything that depends on libpoppler1 (thankfully, we only shipped it in dapper, not breezy) will probably have to do for us.

Why is rebuilding the deps a hack?

If there's something fragile about it, couldn't we just back out the 003_refcount patch for Dapper, and issue an update later? I assume libpoppler will need several security updates throughout Dapper's support period. Won't some of these break ABI? Is there a mechanism in place to distribute re-built dependencies for such updates?

Is there a more appropriate forum for such questions?

because the lib soname should change if the ABI changed. Dropping the patch would mean having that crasher back and would require rebuilding packages which built with the new version

An appropriate forum would be an user list probably

From Kristian Høgsberg (upstream):

The only ABI/API guarantees provided by poppler are for the glib and qt
bindings. We can not guarantee any kind of stabilty for the core xpdf API,
since any bugfix or security fix will touch some class and add or remove member
variables. The problem is that xpdf was never designed with a library / app
split, so we're basically exposing the entire implementation. This is why we've
chosen to write the wrappers - they provide a minimal, opaque API that we can
control and audit easily. The xpdf headers are only installed as an option, and
are provided under "use-at-your-own-risk" terms.

What I'll commit to CVS, though, is a change to the poppler-glib.pc file that
will list poppler as a Requires.private dependency so that evince and other apps
using the glib bindings wont be linking directly to a library that break ABI.
With that it should be possible to bump the libpoppler.so soname without
affecting poppler-glib users, but I'm reluctant to commit to even that.
Basically any change in the poppler core will affect ABI, so we'd be bumping the
soname with almost every commit.

Oh one more reason for not bumping soname on libpoppler.so abi breakages: since
libtool is braindead and actively defeats clever linking (it expands all
dependencies of a library) I don't want to break poppler-glib user because of an
ABI change in a library they don't use directly.