apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2023-02-28T10:19:45Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10876apk.static: --initdb without adding a package?2023-02-28T10:19:45ZKasper Kapk.static: --initdb without adding a package?unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk f...unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk fix`, `apk update` or `apk upgrade` help in this case. there is no top-level command to "(re-)initialize the apk environment idempotently" either.
so if we wanted to use `search`, `fetch`, `cache` or any other command _before_ the first `add`, it is simply not possible(!?). the workaround is wasteful: `add` some random package with `--initdb`, then perform the desired action. otherwise, depending on the command, we are either greeted with:
```
ERROR: Unable to lock database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
```
or
```
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/main: cache not available
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/community: cache not available
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10872Command apk add needs its time to return a non zero exit code2023-01-21T20:04:34ZPantelis KaramolegkosCommand apk add needs its time to return a non zero exit code`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/key...`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.32-r0/glibc-2.32-r0.apk
apk add glibc-2.32-r0.apk
sleep 1
```
`docker build -t test-image . --no-cache --progress=plain` will succeed.
If however one comments out `sleep 1` it will fail.
The error is always there in the `docker build` logs
```
#8 5.418 ERROR: glibc-2.32-r0: trying to overwrite etc/nsswitch.conf owned by alpine-baselayout-data-3.2.0-r23.
#8 5.490 1 error; 15 MiB in 15 packages
#8 DONE 6.6s
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10871[apk-tools] apk search [-d] is case sensitive by default2023-10-12T10:08:44ZJustin[apk-tools] apk search [-d] is case sensitive by defaultapk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.apk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10869Support for faster TCP/HTTP timeout on stale network2023-10-12T14:50:17ZCarlo DéSupport for faster TCP/HTTP timeout on stale networkHello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible t...Hello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible to add a "--timeout" option, would it be at least possible to set a decent internal timeout (< 5min)? As is, when the system's automatically upgraded during the boot, you end with a de facto frozen box.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10866Sort upgrade package list2023-02-14T13:05:31ZJustinSort upgrade package list```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-lib...```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-libclang kpipewire kpipewire-lang plasma-pa plasma-pa-lang
```
This is not that nice to try read if you're looking to see if a specific package has an upgrade available.
A sorted list would be better like
```
abuild
appstream
appstream-lang
appstream-qt
clang15-libclang
cryptsetup
cryptsetup-libs
cryptsetup-openrc
discover
discover-backend-apk
discover-lang
kpipewire
kpipewire-lang
libpng
libpng-dev
llvm15-libs
plasma-pa
plasma-pa-lang
tzdata
wavpack
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10864apk-tool sort results of search2023-10-12T10:08:44ZJustinapk-tool sort results of searchapk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.apk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10863On two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) `apk info` will...2022-12-21T19:19:35ZEllieOn two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) `apk info` will just display nothingOn two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) on postmarketOS, `apk info` and `apk policy` will just display nothing:
```
$ sudo apk info gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk+3.0-9999_git20210602-r2
$ sudo a...On two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) on postmarketOS, `apk info` and `apk policy` will just display nothing:
```
$ sudo apk info gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk4.0-9999-r2
$ sudo apk info gtk4.0-9999-r2
$
```
I'm not sure what exactly it's meant to output, but probably something other than nothing. This is the affected apk version:
```
$ apk --version
apk-tools 2.12.9, compiled for aarch64.
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10860Implement an option for never running apk interactively regardless of whether...2022-12-20T13:41:18ZNewbyteImplement an option for never running apk interactively regardless of whether /etc/apk/interactive existsIn postmarketOS, we have decided to do the inverse of what Alpine does with regards to interactiveness of apk and ship `/etc/apk/interactive` by default and let users delete it if they don't want it. We do this using a post-install trigg...In postmarketOS, we have decided to do the inverse of what Alpine does with regards to interactiveness of apk and ship `/etc/apk/interactive` by default and let users delete it if they don't want it. We do this using a post-install trigger for our base OS package. This is great for us as it makes postmarketOS more familiar to users coming from distributions that don't use apk (which probably applies to most of our users), and also since it allows users to manually audit transactions for unexpected changes before they run them.
However, this has caused problems for our tooling as in some situations this means apk will prompt the user to confirm transactions when they're run in a context where apk is meant to be run non-interactively. One possible solution to this would be to temporarily remove and re-add `/etc/apk/interactive` as necessary, but I think this sounds hacky and error-prone. As such, I would like to see some way of forcing apk to ignore checking for `/etc/apk/interactive` and always run non-interactively. Does this sound like a reasonable proposal?
Related: https://gitlab.com/postmarketOS/pmaports/-/issues/1770https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10859apk3: handle xattrs2023-10-15T16:38:22ZDaniel Kolesaapk3: handle xattrsIt seems adb does not handle those at all yet (even though the other layers support them).It seems adb does not handle those at all yet (even though the other layers support them).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10857`apk cache clean` doesn't remove package downloads in /var/cache/apk/2023-10-12T10:08:43ZEllie`apk cache clean` doesn't remove package downloads in /var/cache/apk/`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritati...`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritating with apk getting stuck on a corrupted download, somehow not being smart enough to do anything about it even on retrying install, and then `apk cache clean` just does nothing of use. Very confusing!v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10855apk3: adb can't handle more than 8000 files per directory2023-09-18T07:35:48ZDaniel Kolesaapk3: adb can't handle more than 8000 files per directoryI have run into this bottleneck today (the `include/config` directory in Linux kernel development headers). Trying to create a package with more than 8000 files per directory will trigger an assertion failure (or an adb header failure at...I have run into this bottleneck today (the `include/config` directory in Linux kernel development headers). Trying to create a package with more than 8000 files per directory will trigger an assertion failure (or an adb header failure at a later point if apk is compiled with assertions off) through `adb_wa_append_obj` (because `.num_fields` is initialized to `APK_MAX_MANIFEST_FILES`, which is 8000).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10854apk3: making --no-chown more useful?2022-12-22T14:13:42ZDaniel Kolesaapk3: making --no-chown more useful?In my build system, I thought I could possibly use `--no-chown` to be able to use `apk add` to create a root filesystem for a user namespace without needing `fakeroot` (in the namespace I don't really care about ownership since it's unpr...In my build system, I thought I could possibly use `--no-chown` to be able to use `apk add` to create a root filesystem for a user namespace without needing `fakeroot` (in the namespace I don't really care about ownership since it's unprivileged and restricted to a single UID). However, this does not seem to work, because while `--no-chown` will indeed prevent the `fchownat` calls from taking place, I am still getting `EPERM` during `renameat` in the commit step.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10853apk3: apk-new files are always created for symlinks2022-08-17T18:14:05ZDaniel Kolesaapk3: apk-new files are always created for symlinksIt seems that apk3 will backup all symlinks in protected directories as .apk-new, even if they point to the same location.It seems that apk3 will backup all symlinks in protected directories as .apk-new, even if they point to the same location.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10852dependency conflict coreutils 9.0 and ucspi-tcp6 1.0.52022-08-05T12:49:24ZTherminoel.kuntze@thermi.consultingdependency conflict coreutils 9.0 and ucspi-tcp6 1.0.5```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: cor...```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: coreutils-9.0-r2[cmd:date] coreutils-9.0-r2[cmd:who]
satisfies: world[ucspi-tcp6]
```
Root cause is this:
```
/ # apk --no-network info -e -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
/ # apk --no-network info -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
cmd:who=9.0-r2
cmd:whoami=9.0-r2
/ # apk --no-network info -a ucspi-tcp6 | grep who
cmd:who
usr/bin/who@
cmd:who=1.05-r0
```
The `provides` part of the package for ucspi-tcp6 contains the one for `who`, although it packages `who@`.
The problem occurs because coreutils 9.0 package "who" in a specific version now.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10849`apk info ...` doesn't show what is actually installed2022-06-26T02:47:29ZEllie`apk info ...` doesn't show what is actually installed```
$ apk info man-pages
man-pages-5.13-r1 description:
Linux man pages
man-pages-5.13-r1 webpage:
https://www.kernel.org/doc/man-pages/
man-pages-5.13-r1 installed size:
10 MiB
$ sudo apk add man-pages
fetch http://mirror.postmarketo...```
$ apk info man-pages
man-pages-5.13-r1 description:
Linux man pages
man-pages-5.13-r1 webpage:
https://www.kernel.org/doc/man-pages/
man-pages-5.13-r1 installed size:
10 MiB
$ sudo apk add man-pages
fetch http://mirror.postmarketos.org/postmarketos/v22.06/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.16/main/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.16/community/aarch64/APKINDEX.tar.gz
(1/1) Installing man-pages (5.13-r1)
█████████████████████████████████████OK: 2864 MiB in 952 packages
$ apk info man-pages
man-pages-5.13-r1 description:
Linux man pages
man-pages-5.13-r1 webpage:
https://www.kernel.org/doc/man-pages/
man-pages-5.13-r1 installed size:
10 MiB
```
As you can see, absolutely nothing in the `apk info man-pages` output indicates that it wasn't previously installed or that it is installed after. This is particularly a problem with packages like networkmanager which looks to me like it has multiple variations/flavors, where it is impossible for me to tell which one I actually have installed:
```
$ apk info networkmanager
networkmanager-1.38.2-r0 description:
Network Management daemon
networkmanager-1.38.2-r0 webpage:
https://wiki.gnome.org/Projects/NetworkManager
networkmanager-1.38.2-r0 installed size:
2888 KiB
networkmanager-elogind-1.38.2-r0 description:
networkmanager (with elogind hibernation support)
networkmanager-elogind-1.38.2-r0 webpage:
https://wiki.gnome.org/Projects/NetworkManager
networkmanager-elogind-1.38.2-r0 installed size:
2888 KiB
```
apk version: `apk-tools 2.12.9, compiled for aarch64.` (as currently shipped by postmarketOS which is based on Alpine)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10848Ignore empty package names2024-02-14T15:36:58ZMarcin KielarIgnore empty package names# Context
We use a sh/bash _trick_ to embed inline comments when we upgrade packages to fix vulnerabilities in our Docker Images. The _trick_ looks like this:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade...# Context
We use a sh/bash _trick_ to embed inline comments when we upgrade packages to fix vulnerabilities in our Docker Images. The _trick_ looks like this:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade \
some-package "$(: 'Fixes CVE-1234')" \
&& ...some more commands...
```
This keeps our Docker Image nice and tidy (just one layer to install all dependencies). We use that with `yum` and `apt-get`, as we have images build from AmazonLinux2 and Ubuntu, and the trick works nicely there.
We also have images built from Alpine, though, which is where the _trick_ doesnt work.
# Example
Consider following `Dockerfile`:
```dockerfile
FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS base-build
#hadolint ignore=DL3013,DL3018
RUN apk add --no-cache \
jq \
curl \
python3 \
py3-pip \
&& apk add --no-cache --upgrade \
pcre2>10.40-r0 "$(: 'Fixes https://security.snyk.io/vuln/SNYK-ALPINE315-PCRE2-2869384')" \
&& pip3 install --no-cache-dir --upgrade \
pip \
&& pip3 install --no-cache-dir \
awscli \
&& rm -rf /var/cache/apk/*
```
When building this, the `apk add --no-cache --upgrade pcre2...` command fails. This is because `apk` is given two strings which it interprets as package names:
- the `"pcre2>10.40-r0"` which properly identifies what we want to install
- the `""` which is a result of the _inline comment trick_ we use.
The error message is:
```
#5 1.223 ERROR: unable to select packages:
#5 1.273 (no such package):
#5 1.273 required by: world[]
```
# Feature request
Make `apk` ignore empty-string package names. This way it will work the same way as `apt-get` and `yum`.
# Existing workarounds
Removing the double quotes from the _inline comment trick_ works:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade \
some-package $(: 'Fixes CVE-1234') \
&& ...some more commands...
```
However, this additionally triggers a `hadolint` warning:
```
Dockerfile:4 SC2046 warning: Quote this to prevent word splitting.
```
We can add an ignore for the warning, but we'd much rather have `apk` just ignore empty strings.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10847upgrade to 2.12.10 breakage2022-12-20T20:55:20ZNatanael Copaupgrade to 2.12.10 breakageThe upgrade to 2.12.10 didn't go as planned and resulted in a 'unfixable' state:
```
ncopa-desktop:~/Projects/abuild (master)$ doas apk upgrade -U -a
doas (ncopa@ncopa-desktop) password:
fetch http://dl-cdn.alpinelinux.org/alpine/edge/...The upgrade to 2.12.10 didn't go as planned and resulted in a 'unfixable' state:
```
ncopa-desktop:~/Projects/abuild (master)$ doas apk upgrade -U -a
doas (ncopa@ncopa-desktop) password:
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://dl-master.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://dl-master.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
Upgrading critical system libraries and apk-tools:
(1/1) Upgrading apk-tools (2.12.9-r3 -> 2.12.10-r0)
Executing busybox-1.35.0-r13.trigger
Continuing the upgrade transaction with new apk-tools:
ERROR: unable to select packages:
cmd:kyua (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: kyua
required by: world[cmd:kyua]
ninja (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: samurai
required by: world[ninja]
ncopa-desktop:~/Projects/abuild (master)$ doas apk del cmd:kyua
ERROR: unable to select packages:
ninja (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: samurai
required by: world[ninja]
ncopa-desktop:~/Projects/abuild (master)$ doas apk del ninja
ERROR: unable to select packages:
cmd:kyua (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: kyua
required by: world[cmd:kyua]
ncopa-desktop:~/Projects/abuild (master)$ doas apk del ninja cmd:kyua
ERROR: unable to select packages:
Huh? Error reporter did not find the broken constraints.
```
I believe this was introduced by:
https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/3b013f458225c2ad8a0d96ec3eb3dde2533e0312
I suppose I can manually delete those from `/etc/apk/world`, but this seems a bit unfortunate for upgraders?Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10843solver bug resulting in "Huh? Error reporter did not find the broken constrai...2022-12-22T19:18:25ZOliver Smithsolver bug resulting in "Huh? Error reporter did not find the broken constraints."Reproduced with apk versions:
* 2.12.7
* 2.12.9
* master (ff7c8f6ee9dfa2add57b88dc271f6711030e72a0)
Here's a bit of an obscure bug... with current postmarketOS v21.12 repository, when installing two specific packages apk fails without s...Reproduced with apk versions:
* 2.12.7
* 2.12.9
* master (ff7c8f6ee9dfa2add57b88dc271f6711030e72a0)
Here's a bit of an obscure bug... with current postmarketOS v21.12 repository, when installing two specific packages apk fails without showing the actual error:
```
# apk add -s device-qemu-amd64 postmarketos-ui-sxmo-de-sway
ERROR: unable to select packages:
Huh? Error reporter did not find the broken constraints.
```
It must be related to the `device-qemu-amd64-sway` subpackage that has an install_if:
```sh
sway() {
install_if="$pkgname=$pkgver-r$pkgrel sway"
depends="postmarketos-ui-sway-logo-key-alt"
mkdir "$subpkgdir"
}
```
If I install that first, then apk runs through without complaining.
```
# apk add device-qemu-amd64-sway
# apk add postmarketos-ui-sxmo-de-sway
```
I've looked at it a bit but don't see the error right away, it's somewhere in the solver. I built apk with debug prints and got the following errors (in the much larger output, attached below):
```
# grep ERROR apk-bug.log
ERROR PKG: postmarketos-ui-sway-logo-key-alt: broken package / tag not ok
ERROR PKG: polkit-elogind: broken package / tag not ok
ERROR PKG: polkit: conflict: same name provided
ERROR PKG: polkit-elogind-libs: broken package / tag not ok
ERROR PKG: polkit-libs: conflict: same name provided
ERROR PKG: polkit-common: propagation up
ERROR PKG: libmm-glib: propagation up
ERROR PKG: geoclue: propagation up
ERROR PKG: sxmo-common: propagation up
ERROR PKG: mmsd-tng: propagation up
ERROR PKG: modemmanager: propagation up
ERROR PKG: networkmanager: propagation up
ERROR PKG: sxmo-common-qt_tweaks: propagation up
ERROR PKG: vvmd: propagation up
ERROR PKG: postmarketos-ui-sxmo-de-sway: propagation up
ERROR: unable to select packages:
```
It says broken package, but not sure how the package is broken / it can be installed if I don't try to install them with one command?
Attachments:
* [apk-bug.log](/uploads/8bbd13cd3bf81a67f3d6a2c03df6c9b4/apk-bug.log): full debug output of apk 2.12.7
* [APKINDEX.tar.gz](/uploads/178bd2819fd2f0b18f35b19ca02e3cbf/APKINDEX.tar.gz): the index of the repository where it fails
I'll probably not be able to look further into this, but documenting for future reference.
CC: @fabled who looked into somewhat related #7586https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10841jfrog - file format error2022-12-21T19:20:07ZJiri Kastnerjfrog - file format errorapk still reports 'file format error' with [jfrog](https://www.jfrog.com/jira/browse/RTFACT-26821) repositories.
adding [merge request](https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/100) for reference.
[aports related...apk still reports 'file format error' with [jfrog](https://www.jfrog.com/jira/browse/RTFACT-26821) repositories.
adding [merge request](https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/100) for reference.
[aports related issue](https://gitlab.alpinelinux.org/alpine/aports/-/issues/13852)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10840Segmentation fault in on_sigint2022-12-22T13:14:48ZDominika LiberdaSegmentation fault in on_sigintSteps to reproduce:
1. run `apk add`
2. pass SIGINT (well, ctrl+c) right after it prints the package db info, but before it quits. Takes a few tries, but I can quite reliably trigger it now.
3. it segfaults
For triggering it in GDB, yo...Steps to reproduce:
1. run `apk add`
2. pass SIGINT (well, ctrl+c) right after it prints the package db info, but before it quits. Takes a few tries, but I can quite reliably trigger it now.
3. it segfaults
For triggering it in GDB, you additionally need to pass `handle SIGINT noprint nostop pass`, because we don't want a break on SIGINT.
Backtrace:
```
#0 0x00007ffff7f8a933 in ?? () from /lib/ld-musl-x86_64.so.1
#1 0x00007ffff7f8acab in ?? () from /lib/ld-musl-x86_64.so.1
#2 0x00007ffff7f9d5cd in munmap () from /lib/ld-musl-x86_64.so.1
#3 0x0000555555566198 in db ()
#4 0x0000555555565880 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x0000000000000030 in ?? ()
#7 0x00005555555661f8 in db ()
#8 0x00007ffff7cc67a0 in ?? () from /lib/libapk.so.3.12.0
#9 0x00007ffff782a210 in ?? ()
#10 0x00007ffff7ca739c in apk_db_close (db=0x555555565880 <db>) at src/database.c:1830
#11 0x0000555555558fc4 in on_sigint (s=2) at src/apk.c:424
#12 <signal handler called>
#13 0x00007ffff7f9d5cd in munmap () from /lib/ld-musl-x86_64.so.1
#14 0x00007ffff7ffdb7c in ?? () from /lib/ld-musl-x86_64.so.1
#15 0x0000000000002000 in ?? ()
#16 0x00007ffff7f8ae2a in ?? () from /lib/ld-musl-x86_64.so.1
#17 0x000000040000007f in ?? ()
#18 0x00007ffff7f8accc in ?? () from /lib/ld-musl-x86_64.so.1
#19 0x0000001d7fffffff in ?? ()
#20 0x00007ffff6b470a8 in ?? ()
#21 0x00007ffff6b47090 in ?? ()
#22 0x00005555555661c8 in db ()
#23 0x0000000000000000 in ?? ()
```v3.0