Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Andreas Beckmann]

Followup-For: Bug #969907
Control: tag -1 patch

https://salsa.debian.org/freedesktop-team/poppler/-/merge_requests/14
https://salsa.debian.org/multimedia-team/inkscape/-/merge_requests/4

Andreas

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Andreas Beckmann]

What about this solution:

In src:poppler provide a virtual package

Package: libpoppler-glibYY
Provides: libpopplerXX-glibYY (= ${binary:Version})

(where XX and YY are the sonames of the respective packages)

and in src:inkscape (and maybe others) add some sed
manipulation to d/rules:

# generate a virtual package dependency to ensure inkscape uses
# matching versions of libpopplerXX and libpoppler-glibYY
# #969907
execute_after_dh_shlibdeps:
sed -ri -e '/shlibs:Depends=/ s/$$/, POPPLER-GLIB/' \
-e 's/(libpoppler[0-9]+)(.*)POPPLER/\1\2\1/' \
-e 's/libpoppler-(glib[0-9]+)(.*)GLIB/\1\2\1/' \
debian/inkscape.substvars

Just tried that and it generated:
Depends: ..., libpoppler-glib8 (>= 0.18.0), libpoppler123 (>= 22.08.0), ..., 
libpoppler123-glib8

This should ensure inkscape depends on libpopplerXX and
libpoppler-glibYY with matching versions (something that
cannot be expressed easily in regular shared library
package dependencies) without unneccessarily tightening
poppler dependencies in packages that use only one of
these libraries.

(This will intentionally generate an unsatisfiable meta
dependency once inkscape no longer links to both
libpopplerXX and libpoppler-glibYY.)


Andreas

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Mattia Rizzolo]

On Sun, Jun 13, 2021 at 05:14:31PM +0200, Francesco Poli wrote:
> Hello,
> is there any progress on this [bug]?

I kinda lost track of it after I handled it in inkscape (since it's not
effectively out of my concerns).

Are there any other affected packages?  If so, they probably ought to
tighten their dependencies.

(though I still think poppler should do something to fix this issue, but
as Ivo said, it's too late for bullseye).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Francesco Poli]

Hello,
is there any progress on this [bug]?

I've just re-read all the bug log, and I acknowledge that the issue is
not easy to deal with.
But, whatever the decision, I think that the bug should be somehow
fixed, in the poppler packages, or in the other packages depending on
the library.

Please let me know, thanks for your time!


[bug]: 

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp8UTFTvR49s.pgp
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Ivo De Decker]

Hi Mattia,

On 4/14/21 8:18 PM, Mattia Rizzolo wrote:

On Wed, Apr 14, 2021 at 02:22:54PM +0200, Ivo De Decker wrote:

So, if that's what you think, should I upload an inkscape with a manual
dependency on libpoppler-glib8 >= 20.09.0?


Yes, that would be useful.


I've just uploaded a new inkscape with this as its only change.
https://salsa.debian.org/multimedia-team/inkscape/-/commit/0a6972eebee178f90109c96e568cdce51b7b0276
And I've confirmed with a binary debdiff that the final Depends line in
the .deb is as expected.


Thanks!


It's probably a good idea if you could age the upload so it doesn't wait
20 days, and unblock it (since it's a key package).


I added a hint.

Ivo

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Mattia Rizzolo]

On Wed, Apr 14, 2021 at 02:22:54PM +0200, Ivo De Decker wrote:
> > So, if that's what you think, should I upload an inkscape with a manual
> > dependency on libpoppler-glib8 >= 20.09.0?
> 
> Yes, that would be useful.

I've just uploaded a new inkscape with this as its only change.
https://salsa.debian.org/multimedia-team/inkscape/-/commit/0a6972eebee178f90109c96e568cdce51b7b0276
And I've confirmed with a binary debdiff that the final Depends line in
the .deb is as expected.

It's probably a good idea if you could age the upload so it doesn't wait
20 days, and unblock it (since it's a key package).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Ivo De Decker]

Hi,

On Tue, Apr 13, 2021 at 06:53:55PM +0200, Mattia Rizzolo wrote:
> On Sun, Apr 11, 2021 at 08:02:20PM +0200, Ivo De Decker wrote:
> > There is a theoretical and a practical aspect to this issue. From a
> > theoretical point of view, the dependency relations should not be stricter
> > than necessary, to allow partial upgrades and to avoid complicating
> > migration to testing of library transitions.
> 
> Then again, I believe the project at large is moving towards
> stricter-than-necessary dependencies (see the implied dh_makeshlibs -V
> in dh compat 12, lintian nagging about the Build-Depends-Package in
> .symbols files, etc).

We'll need to find a middle ground here. The impact will depends on the way
the issue is fixed. I guess that's something for bookworm.

The main concerns (from my POV) are:
- making sure we don't inadvertently create some dependency loop that makes
  upgrades more difficult (or impossible)
- avoiding turning the library transition into a non-smooth one, where all
  packages have to migrate at the same time

> I also don't believe a stricter dependency between libpoppler102 and
> libpoppler-glib8 would have any of the issue you mention.

I suspect tightening the dependencies between libpoppler-glibX and libpopplerX
will cause a lot less issues than artificially bumping the version for all
symbols.

> > It would create the desired dependency, but I'm not sure if this is better
> > than just manually adding it to the 2 remaining packages we are aware of
> > (especially at this stage of the freeze).
> 
> > For now, though (and especially for bullseye), I think we should accept
> > that we aren't going to solve this issue in general. The best we can do, is
> > to try to fix obvious cases where we are aware of the issue. In other cases,
> > we'll probably need to advise our users to do a full upgrade instead of a
> > partial one.
> 
> So, if that's what you think, should I upload an inkscape with a manual
> dependency on libpoppler-glib8 >= 20.09.0?

Yes, that would be useful.

> (mhh, is there a way to do this without writing it in d/control?).

There probably is, but writing it in d/control will be the easiest by far.

Thanks,

Ivo

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Mattia Rizzolo]

On Sun, Apr 11, 2021 at 08:02:20PM +0200, Ivo De Decker wrote:
> There is a theoretical and a practical aspect to this issue. From a
> theoretical point of view, the dependency relations should not be stricter
> than necessary, to allow partial upgrades and to avoid complicating
> migration to testing of library transitions.

Then again, I believe the project at large is moving towards
stricter-than-necessary dependencies (see the implied dh_makeshlibs -V
in dh compat 12, lintian nagging about the Build-Depends-Package in
.symbols files, etc).

I also don't believe a stricter dependency between libpoppler102 and
libpoppler-glib8 would have any of the issue you mention.

> It would create the desired dependency, but I'm not sure if this is better
> than just manually adding it to the 2 remaining packages we are aware of
> (especially at this stage of the freeze).

> For now, though (and especially for bullseye), I think we should accept
> that we aren't going to solve this issue in general. The best we can do, is
> to try to fix obvious cases where we are aware of the issue. In other cases,
> we'll probably need to advise our users to do a full upgrade instead of a
> partial one.

So, if that's what you think, should I upload an inkscape with a manual
dependency on libpoppler-glib8 >= 20.09.0?  (mhh, is there a way to do
this without writing it in d/control?).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Ivo De Decker]

Hi Simon,

There is a theoretical and a practical aspect to this issue. From a 
theoretical point of view, the dependency relations should not be 
stricter than necessary, to allow partial upgrades and to avoid 
complicating migration to testing of library transitions.


On 4/11/21 12:37 PM, Simon McVittie wrote:

A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
have an elegant way to handle this automatically at build time to make sure
the dependencies are correct, without having to add them manually.


Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
that version was the first one to have the libpoppler102 SONAME? That
would ensure that the bad partial upgrade you describe can't happen,
because if a dependent package uses libpoppler102 ABI directly, and
also uses libpoppler indirectly via libpoppler-glib8, then it's the
same libpoppler.


The issue only happens if the same package depends on both libpoppler 
and libpoppler-glib, so forcing libpoppler and libpoppler-glib to be 
upgraded at the same time, is more strict than is theoretically needed. 
Also, I wonder if this would still allow the reverse issue to happen:


If an old inkscape is linked against the old libpoppler-glib8 and 
libpoppler95, installing libpoppler102 would force libpoppler-glib8 to 
be upgraded, and the old inkscape would link against the old libpoppler 
and the new libpoppler-glib, causing the same issue (I didn't test if 
this happens in practice).



Or, would this work?

* in src:poppler libpoppler-glib8.symbols.in, bump the version on every
   symbol to at least 20.08.0-1~ (the version that had the most recent
   SONAME bump) and upload to unstable


This would cause every package that links against libpoppler-glib8, but 
not (directly) against libpoppler to depend on the newer version of 
libpoppler-glib8, even if that's not necessary. In practice, this would 
severely reduce the usefulness of using the symbols file. And make 
partial upgrades (for users) and smooth updates (for library transitions 
to testing) much harder.



* binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
   and inkscape

That way, the binNMU'd versions of the dependent packages would have:

 Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)

and the bad partial upgrade you describe could not happen, because the
dependent package (inkscape in your example) would pull in the new
libpoppler-glib8 in addition to the new libpoppler102.


It would create the desired dependency, but I'm not sure if this is 
better than just manually adding it to the 2 remaining packages we are 
aware of (especially at this stage of the freeze).



For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
since they could suffer from the same bug if an application calls into
libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
although I don't know whether that happens in practice.


Well, I suspect there are actually quite a lot of these issue a our 
packages, but that many of them are not usually detected. Doing partial 
upgrades might result in binaries being (transitively) linked to 
different (incompatible) version of the same library. Even when that 
happens, it's not always immediately obvious. In the inkscape example, 
the issue only shows up when you try to open a pdf, not when you just 
start the program. So the fact that the programs runs successfully in 
some cases, doesn't guarantee that the issue isn't present.


This issue reminds me of https://bugs.debian.org/962320, which is 
somewhat similar, because multiple versions of the same boost library 
are linked into the same binary. In that case, this was detected because 
some of the packages weren't rebuilt yet, but I suspect it might be 
possible to trigger a similar issue by doing a partial upgrade of a 
package that (transitively) pulls in a number of boost libraries.


This brings me to the practical aspect of this issue: we try to support 
partial upgrades, and generate the correct dependency relation to make 
sure that unsupported combinations of packages can't be installed at the 
same time. However, we currently don't have a way to generate these 
dependencies when multiple interdependent libraries are involved. I'm 
unsure how we could handle this in general, but it certainly would be 
nice to have a way to do so. For now, though (and especially for 
bullseye), I think we should accept that we aren't going to solve this 
issue in general. The best we can do, is to try to fix obvious cases 
where we are aware of the issue. In other cases, we'll probably need to 
advise our users to do a full upgrade instead of a partial one.


Cheers,

Ivo

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

Control: retitle -1 inkscape, etc. crashing with mismatched libpoppler102 and 
libpoppler-glib8

On Sat, 10 Apr 2021 at 22:13:13 +0200, Ivo De Decker wrote:
> Install inkscape on a buster system. The pdf David attached can be opened
> without issue. Upgrade only inkscape to bullseye (letting apt pull in the
> dependencies, which include libpoppler102 but not the newer libpoppler-glib8).
> When opening the pdf inkscape closes with an error, and the kernel reports:
> inkscape[9032]: segfault at 9 ip 7fad9e3e1d3e sp 7fff5127ae30 error 4 
> in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000]
> 
> Installing the new libpoppler-glib8 fixes the issue.
> 
> A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
> well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
> have an elegant way to handle this automatically at build time to make sure
> the dependencies are correct, without having to add them manually.

Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
that version was the first one to have the libpoppler102 SONAME? That
would ensure that the bad partial upgrade you describe can't happen,
because if a dependent package uses libpoppler102 ABI directly, and
also uses libpoppler indirectly via libpoppler-glib8, then it's the
same libpoppler.

Or, would this work?

* in src:poppler libpoppler-glib8.symbols.in, bump the version on every
  symbol to at least 20.08.0-1~ (the version that had the most recent
  SONAME bump) and upload to unstable
* binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
  and inkscape

That way, the binNMU'd versions of the dependent packages would have:

Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)

and the bad partial upgrade you describe could not happen, because the
dependent package (inkscape in your example) would pull in the new
libpoppler-glib8 in addition to the new libpoppler102.

For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
since they could suffer from the same bug if an application calls into
libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
although I don't know whether that happens in practice.

smcv

Processed: Re: Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 inkscape, etc. crashing with mismatched libpoppler102 and 
> libpoppler-glib8
Bug #969907 [libpoppler-glib8] epdfinfo crashing with mismatched libpoppler102 
and libpoppler-glib8
Changed Bug title to 'inkscape, etc. crashing with mismatched libpoppler102 and 
libpoppler-glib8' from 'epdfinfo crashing with mismatched libpoppler102 and 
libpoppler-glib8'.

-- 
969907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969907
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems