this is rather unusual - this would be very difficult to diagnose unless the bug is reproducible; but i doubt if anyone can reproduce it - if this was a general problem with pacman, many people would have complained about it already

does the same thing happen repeatedly? - if so, you can post a crash dump - also your log does not show which repos you have enabled - it is best to show the complete --debug output - you deleted large swaths of it

the output of `pacman -Qm` may also be interesting

so this is the offending code:

int _alpm_download(alpm_handle_t *handle,
    alpm_list_t *payloads /* struct dload_payload */,
    const char *localpath)
{
  if(handle->fetchcb == NULL) {
....
  } else {
    alpm_list_t *p;
    int updated = 0;
    for(p = payloads; p; p = p->next) {
      struct dload_payload *payload = p->data;
      alpm_list_t *s;
      int ret = -1;

      if(payload->fileurl) {
....
      } else {
        for(s = payload->cache_servers; s && ret == -1; s = s->next) {
          ret = payload_download_fetchcb(payload, s->data, localpath);
        }
        for(s = payload->servers; s && ret == -1; s = s->next) {
          ret = payload_download_fetchcb(payload, s->data, localpath);
        }

        if (ret != -1 && payload->download_signature) {
          /* Download signature if requested */
          char *sig_fileurl;
          size_t sig_len = strlen(s->data) + strlen(payload->filepath) + 6; // <-- LOC 1045

without digging any deeper, it looks that the server URL is borked (presumably, one of s->data or payload->filepath is NULL) - i would check /etc/pacman.d/mirrorlist and /etc/pacman.conf very closely if you have modified them, merging any .pacnew files, etc

just FWIW, i noticed that the latest code on the upstream master branch has a change in this code - maybe that is important

        for(s = payload->cache_servers; s; s = s->next) {
          ret = payload_download_fetchcb(payload, s->data, localpath);
          if (ret != -1) {
            goto download_signature;
          }
        }
        for(s = payload->servers; s; s = s->next) {
          ret = payload_download_fetchcb(payload, s->data, localpath);
          if (ret != -1) {
            goto download_signature;
          }
        }
download_signature:
        if (ret != -1 && payload->download_signature) {

could be ....
https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/152
https://gitlab.archlinux.org/pacman/pacman/-/commit/eb5bf6913835e7553433ef82bdf0a456528f9b50

so also check if you have an 'XferCommand' defined in your /etc/pacman.conf, or if you have only one enabled remote repository URL

Required and relevant files (except mirrorlist) may contain sensetive data. I will upload them and new core in encrypted form. I suggest to use "age" for this purpose. Otherwise I will modify them (if possible) before upload, but do not complain me then about missing some parts.

you do not need to send anything more - i mentioned only pacman.conf and mirrorlist - neither of those would contain anything private; but i did not ask to see them, only that you should inspect them and merge any changes from .pacnew files - that is routine maintenance which every parabola user should know how to do

the most informative thing you could do now, is to ensure that your pacman.conf and mirrorlist are exactly the ones in the current 'pacman' and 'pacman-mirrorlist' packages, then try pacman again - if that makes the problem go away, then i can make a new pacman package applying the arch-MR152.patch, and ask you to try it with your customized pacman.conf and mirrorlist

Relevant *.pacnew does not exists.

unless you are prepared to debug this yourself, the only informative thing you could do now, is to ensure that your pacman.conf and mirrorlist are exactly the ones in the current 'pacman' and 'pacman-mirrorlist' packages - that is, pacman.conf and mirrorlist are not modified in any way - then try `pacman -Sw mc` again - if that downloads 'mc' properly, then i can make a new pacman package applying the arch-MR152.patch, and ask you to try it with your customized pacman.conf and mirrorlist

note that strlen does not show up in the stack trace -- the fault occurs directly in libalpm. So either the strlen code was inlined completely (which is possible) or there might be an issue with the linkage of the C library.

this kind of issue could be triggered by a partial upgrade -- when was the last time you ran `pacman -Syu`? If you upgraded pacman manually without the rest of the system, then this could be the underlying issue.

i noticed that too; but if 's' is NULL, the NULL pointer de-reference would happen in the outer scope while setting up the stack frame for strlen - if 's' was valid and 's->data' was NULL, NULL would be passed into strlen and the NULL pointer de-reference would happen in strlen, presuming that it was not in-lined

also note 'xfercommand' in the --debug log, which is a requisite for the upstream bug - so it is likely that da hit that bug

I have discover that the bug can be reproduced ONLY when XferCommand option enabled. Even with default pacman.conf file.

Last system upgrade, including pacman, was at 2024-04-15. Usually I upgrade entire system, except a few irrelevant pieces listed in the IgnorePkg.

da - plz try this pacman package with your XferCommand; and let us know if it works

# pacman -U https://repo.parabola.nu/pool/parabola/pacman-6.1.0-3.parabola2-x86_64.pkg.tar.zst

Segmentation fault is gone.