Running aptitude without arguments in a ssh session to a remote
host I see the "loading cache" message as usual, but then it dies
with

	Ouch!  Got SIGSEGV, dying..
	Segmentation fault

aptitude update, upgrade etc work without problems, AFAICT.

I can reproduce this on several remote hosts running Bullseye or
Testing, so it must be related to my environment somehow (Testing
on a desktop PC), but it doesn't tell.


Regards

Harri

Hi Harald,

Harald Dunkel wrote:

I assume this happens primarily as root on the remote host.

Marking as found in 0.8.13-3 then.

Ack. Doesn't look like a repo issue. Except maybe, if there's a common
non-debian APT repo involved.

Oh, and since about when is this happening? I assume this showed up
only recently, not for years. :-)

		Regards, Axel

Hi Axel,

For testing I scanned all additional repositories in my sources.list.d.
It dies about

deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com bookworm main

see https://www.hashicorp.com/official-packaging-guide.


I don't know who is to blame here, but I hope this helps

Harri

aptitude stumbles over this for only a few weeks. No problems with
"aptitude upgrade" and other, non-interactive commands.


Regards

Harri

Hi Harald,

Harald Dunkel wrote:

Thanks for figuring out that. Will see if I can figure out more.

I currently asssume that there is some field unset in their repo meta
data, which aptitude's GUI (and only the GUI) expects to be set
unconditionally. I guess stracing will reveal some more details.

		Regards, Axel

Hi Harald,

Harald Dunkel wrote:

Sorry to bother you again, but while this looked very good as
potential cause (or actually still does), I can't reproduce it inside
a Sid pbuilder chroot. So I assume there's another detail which is
required, too, to reproduce it.

Some more ideas to check:

* Do you have any custom settings for settings influencing aptitude's
  package display like "Aptitude::UI::Package-Display-Format" or
  "Aptitude::UI::Default-Grouping"?

* Under which locale settings does it happen for you?

If you neither use any of these settings nor use a non-english locale,
is there any chance that you can install these packages (for
bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the
debian-goodies package) on one of the affected machines:

strace aptitude-dbgsym libapt-pkg6.0-dbgsym
libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg
libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym
libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym
liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym
libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym
libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym
zlib1g-dbgsym

And then run "strace -o aptitude-1035976.strace aptitude" and send me
that file? (Probably best in compressed form.)

Because that's what I just wanted to do if I would have been able to
reproduce it. :-)

		Regards, Axel

Hi Axel,

apparently it is not sufficient to just add the entry to sources.list.d.
I had to update the local cache to make aptitude die.

No, I just have

	# cat .aptitude/config
	aptitude "";
	aptitude::Keep-Unused-Pattern "";
	aptitude::Delete-Unused-Pattern "";
	aptitude::UI "";
	aptitude::UI::Prompt-On-Exit "false";
	aptitude::UI::Advance-On-Action "true";
	APT "";
	APT::Install-Recommends "false";

On some systems I have set LANG=C or LANG=en_US.UTF-8, but I can reproduce
this using

	# locale
	LANG=
	LANGUAGE=
	LC_CTYPE="POSIX"
	LC_NUMERIC="POSIX"
	LC_TIME="POSIX"
	LC_COLLATE="POSIX"
	LC_MONETARY="POSIX"
	LC_MESSAGES="POSIX"
	LC_PAPER="POSIX"
	LC_NAME="POSIX"
	LC_ADDRESS="POSIX"
	LC_TELEPHONE="POSIX"
	LC_MEASUREMENT="POSIX"
	LC_IDENTIFICATION="POSIX"
	LC_ALL=

I doubt that this is related to the locale.

libelogind0? This breaks systemd.


Regards
Harri

Hi Harald,

Harald Dunkel wrote:

Ok, another try:

# pbuilder update --autocleanaptcache
# pbuilder login
## apt install aptitude wget gpg ca-certificates
## wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg
## echo "deb https://apt.releases.hashicorp.com bookworm main" > /etc/apt/sources.list.d/hashicorp.list
## apt update
Hit:1 http://debian.ethz.ch/debian sid InRelease
Get:2 https://apt.releases.hashicorp.com bookworm InRelease [12.9 kB]
Get:3 https://apt.releases.hashicorp.com bookworm/main amd64 Packages [84.4 kB]
## aptitude

TUI comes up. No crash.

Looks harmless indeed.

Thanks. I indeed think we can rule that out, too.

Then again, I'm out of ideas now, except for looking with strace where
the crash happens.

Ah, sorry, didn'y notice that.

Wanted to avoid that you need to install debian-goodies for
find-dbgsym-packages so I ran "find-dbgsym-packages --all aptitude" on
one of my systems. Seems as if the output actually depends on which
alternatives have been chosen on the local system. Of course
libsystemd0-dbgsym is fine as well if you have libsystemd0 installed.

(I also doubt that all of these are really necessary. Probably
"aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym
libcwidget4-dbgsym libgcc-s1-dbgsym libncursesw6-dbgsym
libsigc++-2.0-0v5-dbgsym libxapian30-dbgsym" already suffice to cover
everything which might be involved in such a crash, especially since
it does not happen when downloading or accessing the package lists.)

		Regards, Axel

I had sent you the strace output in private mail.

Since this morning I got the SIGSEGV also with my own repository,
but only for 3 hosts of about 400. No other repos except for

    deb http://deb.debian.org/debian/ buster main contrib non-free
    deb-src http://deb.debian.org/debian/ buster main contrib non-free
    deb http://security.debian.org/ buster/updates main contrib non-free
    deb-src http://security.debian.org/ buster/updates main contrib non-free

are in sources.list of these 3 hosts.

This started pretty weird: Using clusterssh I had upgraded about 30
Debian hosts (Buster and Bullseye, real hardware and LXC containers) in
parallel, including these 3 containers. All succeeded. When I pressed 'f'
and entered no pattern these 3 hosts died with a SIGSEGV for the first
time. Reproducible. Restarting aptitude did not help, they died on 'f'
again.

I ran

    aptitude forget-new

on the command line. This succeeded. Since then these 3 hosts die
immediately on running aptitude, not waiting for 'f' or any other
input.

Hope this helps

Regards
Harri

Any news? Could you read something from the strace output?


Regards

Harri