If an older program version (no longer shipped in Debian) segfaults with
an updated version of a library package (with the same SONAME, etc.),
but continues to work fine with an older version of that library, is
that considered a bug in the new version of the library package?
I have a case of that happening, with a program that matters quite a lot
to me, and I'm trying to assess whether it would be potentially worth
the trouble for me to report the segfault as a bug against the library
package involved, vs. focusing my effort on trying to find ways to work
around the problem.
That's partly a matter of principle (if libraries break backward
compatibility, shouldn't they have to change SONAME or similar?), partly
a matter of maintainer opinions/attitudes (how open is the maintainer to problems with applications and versions not shipped in Debian?), and
partly a matter of how practical it would or wouldn't be to get it fixed
(with no debug symbols in the program, there might not be any useful way
to diagnose the problem, even if it *is* with the library proper).

The library at hand is libfontconfig1. The program at hand (which I
still run as an older version intentionally) is Icedove, Debian's former rebranded variant of Mozilla Thunderbird. The question being asked is
*NOT* about Icedove/Thunderbird or libfontconfig1 specifically,
however; it is about the more general considerations outlined above.
I recently had to restart my computer due to a power outage. After the
boot-up, Icedove involved failed to launch. Running it from a terminal
showed that it segfaults. Running it under gdb showed that the segfault
is inside a function call from libfontconfig1; as this build of Icedove
does not have debug information available, I don't have any ready way to
take it any further than that (although see below).
That was with libfontconfig1 installed at version 2.17.1-3, from current testing. With some difficulty (because of version-match requirements
among various other library packages), I downgraded libfontconfig1 to
version 2.15.0-2.3 (from current stable); after that, the program again launched without issues.
I can very probably reproduce the issue on demand by upgrading the
library packages again, but I am hesitant to do so without a specific
intention in mind, because downgrading again could be a pain (and if I
don't successfully downgrade, I lose E-mail access until such time as I
can find a solution by other means).

...While writing the above it occurred to me that if I install the
-dbgsym package for libfontconfig1 (and any other library packages that
turn out to be in the call chain), I might be able to get a more useful
stack trace out of gdb. If I do get to the point of reproducing the
issue, that may very well be worth the attempt.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Wanderer (HE12026-02-09):

If an older program version (no longer shipped in Debian) segfaults with
an updated version of a library package (with the same SONAME, etc.),
but continues to work fine with an older version of that library, is
that considered a bug in the new version of the library package?

Not necessarily, that could be a bug in the older program.

That's partly a matter of principle (if libraries break backward compatibility, shouldn't they have to change SONAME or similar?)

Indeed, but that only applies to normal calls to the API. A library is
free to alter how it reacts to improper calls of its API without bumping
the SONAME.

It is perfectly possible that Icedove used to call fontconfig
incorrectly in a way that was not visible but now causes a crash.

Regards,

--
Nicolas George

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

At Mon, 09 Feb 2026 09:09:18 -0500 The Wanderer <wanderer@fastmail.fm> wrote:

If an older program version (no longer shipped in Debian) segfaults with
an updated version of a library package (with the same SONAME, etc.),
but continues to work fine with an older version of that library, is
that considered a bug in the new version of the library package?

Shared libraries should be versioned and programs should specify the version they have been linked with.

I have a case of that happening, with a program that matters quite a lot
to me, and I'm trying to assess whether it would be potentially worth
the trouble for me to report the segfault as a bug against the library package involved, vs. focusing my effort on trying to find ways to work around the problem.

It is not actually a bug, assuming that the library is using proper versioning. OTOH, if the program is NOT properly specifying the library version it expect to use, then that is a bug in the *program*. (If you are playing games with symlinks to fake things, that is on you.)

That's partly a matter of principle (if libraries break backward compatibility, shouldn't they have to change SONAME or similar?), partly
a matter of maintainer opinions/attitudes (how open is the maintainer to problems with applications and versions not shipped in Debian?), and
partly a matter of how practical it would or wouldn't be to get it fixed (with no debug symbols in the program, there might not be any useful way
to diagnose the problem, even if it *is* with the library proper).

They change the version numbers. And programs should code the expected version numbers at link time.

The library at hand is libfontconfig1. The program at hand (which I
still run as an older version intentionally) is Icedove, Debian's former rebranded variant of Mozilla Thunderbird. The question being asked is
*NOT* about Icedove/Thunderbird or libfontconfig1 specifically,
however; it is about the more general considerations outlined above.

I recently had to restart my computer due to a power outage. After the boot-up, Icedove involved failed to launch. Running it from a terminal
showed that it segfaults. Running it under gdb showed that the segfault
is inside a function call from libfontconfig1; as this build of Icedove
does not have debug information available, I don't have any ready way to
take it any further than that (although see below).

That was with libfontconfig1 installed at version 2.17.1-3, from current testing. With some difficulty (because of version-match requirements
among various other library packages), I downgraded libfontconfig1 to
version 2.15.0-2.3 (from current stable); after that, the program again launched without issues.

OK, if you are using *unstable* versions (eg "testing") you can expect problems and should then report them. This *sounds* like such a case.

I can very probably reproduce the issue on demand by upgrading the
library packages again, but I am hesitant to do so without a specific intention in mind, because downgrading again could be a pain (and if I
don't successfully downgrade, I lose E-mail access until such time as I
can find a solution by other means).

You could create a VM just for testing this issue...

...While writing the above it occurred to me that if I install the
-dbgsym package for libfontconfig1 (and any other library packages that
turn out to be in the call chain), I might be able to get a more useful
stack trace out of gdb. If I do get to the point of reproducing the
issue, that may very well be worth the attempt.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services


--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2/9/26 8:41 AM, Robert Heller wrote:

[ *SNIP* ]

I can very probably reproduce the issue on demand by upgrading the
library packages again, but I am hesitant to do so without a specific
intention in mind, because downgrading again could be a pain (and if I
don't successfully downgrade, I lose E-mail access until such time as I
can find a solution by other means).

You could create a VM just for testing this issue...

Or, If you are uncomfortable with VMs and have adequate disk space,
consider dual booting to an appropriate OS version with target
application. Back in days of Squeeze I found that a workable approach
[have forgotten what the instigating problem was ;]
YMMV!

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)