Pamac Segmentation fault (core dumped)

Hello everyone I have a issue

When I check for updates in pamac it crashes with a segmentation fault error

Segmentation fault (core dumped)

I tried reinstalling all the pamac packages

pamac-cli, pamac-common and pamac-gtk

as well as pamac-flatpak-plugin and pamac-snap-plugin

even tho I don’t think it would do anything but didn’t change anything.

Than I Tried removing all the packages including the dependencies and doing sudo pacman -Scc and sudo paccache -r to clear any cached packages but it still does it.

Anyone know how to fix the issue?

1 Like

Have you tried to use pacman?

sudo pacman-mirrors -f && sudo pacman -Syyu

Yes and Pamac still crashes when I click on updates

Then use pacman until this is fixed…

Here is a gif of the issue and I will be until it’s fixed.

Just some thoughts.

  • If you run pamac-manager from a console, are there any errors.

  • Any meaningful errors in /var/log/pacman.log. pamac has a View History.

  • Delete anything in /tmp dealing with pamac and try pamac update.

  • Backup/delete or rename ~/.config/pamac. I’m assuming pamac will recreate it. If not, restore it.

  • Anything meaningful when you do

    coredumpctl
    coredumpctl info PID        # pamac PID from the above command

No errors no until I click on updates and than it will crash with a Segmentation fault (core dumped)

error

I deleted the pamac folder in .config so it would be reset but still the same error and no errors in /var/log/pacman.log either

I do see this error for pamac manager so I already knew it was a issue with Pamac.

[corey@Corey-PC ~]$ coredumpctl info
           PID: 14881 (pamac-manager)
           UID: 1000 (corey)
           GID: 1001 (corey)
        Signal: 11 (SEGV)
     Timestamp: Sat 2021-01-30 23:26:29 AEST (1min 33s ago)
  Command Line: pamac-manager
    Executable: /usr/bin/pamac-manager
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (corey)
       Boot ID: 172b41ac4da243978b515544999daa65
    Machine ID: 290bb56a57f84bfd8883f345c6db0e1b
      Hostname: Corey-PC
       Storage: /var/lib/systemd/coredump/core.pamac-manager.1000.172b41ac4da243978b515544999daa65.>
       Message: Process 14881 (pamac-manager) of user 1000 dumped core.
                
                Stack trace of thread 14888:
                #0  0x00007fb224307a10 g_str_hash (libglib-2.0.so.0 + 0x35a10)
                #1  0x00007fb224308b9b g_hash_table_contains (libglib-2.0.so.0 + 0x36b9b)
                #2  0x00007fb224f3de17 pamac_database_get_aur_updates_real (libpamac.so + 0x3be17)
                #3  0x00007fb224f4718f pamac_database_get_updates_real (libpamac.so + 0x4518f)
                #4  0x00007fb224f4776c ___lambda35_ (libpamac.so + 0x4576c)
                #5  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #6  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #7  0x00007fb224169293 __clone (libc.so.6 + 0x100293)
 ESCOC
































 33s ago)


n-2.scope







ac-manager.1000.172b41ac4da243978b515544999daa65.14881.1612013189000000.zst
ser 1000 dumped core.


(libglib-2.0.so.0 + 0x35a10)
e_contains (libglib-2.0.so.0 + 0x36b9b)
ase_get_aur_updates_real (libpamac.so + 0x3be17)
ase_get_updates_real (libpamac.so + 0x4518f)
_ (libpamac.so + 0x4576c)
b-2.0.so.0 + 0x7fec1)
d (libpthread.so.0 + 0x93e9)
bc.so.6 + 0x100293)

 ESCOD
           UID: 1000 (corey)
           GID: 1001 (corey)
        Signal: 11 (SEGV)
     Timestamp: Sat 2021-01-30 23:26:29 AEST (1min 33s ago)
  Command Line: pamac-manager
    Executable: /usr/bin/pamac-manager
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (corey)
       Boot ID: 172b41ac4da243978b515544999daa65
    Machine ID: 290bb56a57f84bfd8883f345c6db0e1b
      Hostname: Corey-PC
       Storage: /var/lib/systemd/coredump/core.pamac-manager.1000.172b41ac4da243978b515544999daa65.>
       Message: Process 14881 (pamac-manager) of user 1000 dumped core.
                
                Stack trace of thread 14888:
                #0  0x00007fb224307a10 g_str_hash (libglib-2.0.so.0 + 0x35a10)
                #1  0x00007fb224308b9b g_hash_table_contains (libglib-2.0.so.0 + 0x36b9b)
                #2  0x00007fb224f3de17 pamac_database_get_aur_updates_real (libpamac.so + 0x3be17)
                #3  0x00007fb224f4718f pamac_database_get_updates_real (libpamac.so + 0x4518f)
                #4  0x00007fb224f4776c ___lambda35_ (libpamac.so + 0x4576c)
                #5  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #6  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #7  0x00007fb224169293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 14891:
                #0  0x00007fb224163d5d syscall (libc.so.6 + 0xfad5d)
                #1  0x00007fb224371a9b g_cond_wait_until (libglib-2.0.so.0 + 0x9fa9b)
                #2  0x00007fb2242f4853 n/a (libglib-2.0.so.0 + 0x22853)
                #3  0x00007fb224354ecb n/a (libglib-2.0.so.0 + 0x82ecb)
                #4  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #5  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #6  0x00007fb224169293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 14881:
                #0  0x00007fb22415e46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007fb22437893f n/a (libglib-2.0.so.0 + 0xa693f)
                #2  0x00007fb2243232b1 g_main_context_iteration (libglib-2.0.so.0 + 0x512b1)
                #3  0x00007fb22452cd1e g_application_run (libgio-2.0.so.0 + 0xccd1e)
                #4  0x000055f68f177c54 _vala_main (pamac-manager + 0x34c54)
                #5  0x00007fb224091152 __libc_start_main (libc.so.6 + 0x28152)
                #6  0x000055f68f14f09e _start (pamac-manager + 0xc09e)
                
                Stack trace of thread 14883:
                #0  0x00007fb22415e46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007fb22437893f n/a (libglib-2.0.so.0 + 0xa693f)
                #2  0x00007fb224323fd3 g_main_loop_run (libglib-2.0.so.0 + 0x51fd3)
                #3  0x00007fb224561fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
                #4  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #5  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #6  0x00007fb224169293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 14882:
                #0  0x00007fb22415e46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007fb22437893f n/a (libglib-2.0.so.0 + 0xa693f)
                #2  0x00007fb2243232b1 g_main_context_iteration (libglib-2.0.so.0 + 0x512b1)
                #3  0x00007fb224323302 n/a (libglib-2.0.so.0 + 0x51302)
                #4  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #5  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #6  0x00007fb224169293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 14890:
                #0  0x00007fb22415e46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007fb22437893f n/a (libglib-2.0.so.0 + 0xa693f)
                #2  0x00007fb2243232b1 g_main_context_iteration (libglib-2.0.so.0 + 0x512b1)
                #3  0x00007fb21ec18c0e n/a (libdconfsettings.so + 0x5c0e)
                #4  0x00007fb224351ec1 n/a (libglib-2.0.so.0 + 0x7fec1)
                #5  0x00007fb223e353e9 start_thread (libpthread.so.0 + 0x93e9)
                #6  0x00007fb224169293 __clone (libc.so.6 + 0x100293)

As I see it, Manjaro, as Arch offspring, have no control of anything, just roll on Arch’s back. There is no encouragement for users to go report things upstream, as shown in this example by moderator @Wollie.
Just ignore problem until Arch fixes it, let them do dirty work, or in this case - very weird, because pamac is Manjaro project and bugs should be reported to Manjaro’s Pamac GitLab! Link: Issues · Applications / pamac · GitLab

This worries me, as my daily forum read consists 75% of things being broken, users lamenting and nothing is being done about it.

I’m going to also report this to pamac’s Gitlab

Also notice it crashes when refreshing databases…

1 Like

Any fix happening? no one has looked at my report either…

It’s odd. I don’t have any issues on my install.

So maybe it’s a mirror issue, so try:
sudo pacman-mirrors -f5 && sudo pacman -Syyu

Yeah I know right, none of my clients or family member have the issue either but I did the command you suggested and everything looks fine but sadly it still crashes when checking for updates

[corey@Corey-PC ~]$ sudo pacman-mirrors -f5 && sudo pacman -Syyu
[sudo] password for corey: 
::INFO Downloading mirrors from repo.manjaro.org
::INFO Using default mirror file
::INFO Querying mirrors - This may take some time
  1.937 Austria        : http://mirror.easyname.at/manjaro/
  ..... Austria        : ftp://mirror.easyname.at/manjaro/
  2.096 Chile          : https://mirror1.cl.netactuate.com/manjaro/
  1.658 Chile          : http://mirror1.cl.netactuate.com/manjaro/
  ..... Chile          : ftp://mirror1.cl.netactuate.com/manjaro/
  3.032 Netherlands    : https://ftp.nluug.nl/pub/os/Linux/distr/manjaro/
  ..... Netherlands    : ftp://ftp.nluug.nl/pub/os/Linux/distr/manjaro/
  1.632 United_States  : https://mirrors.ocf.berkeley.edu/manjaro/
  2.043 Costa_Rica     : https://mirrors.ucr.ac.cr/manjaro/
::INFO Writing mirror list
::United_States   : https://mirrors.ocf.berkeley.edu/manjaro/stable
::Costa_Rica      : https://mirrors.ucr.ac.cr/manjaro/stable
::Chile           : https://mirror1.cl.netactuate.com/manjaro/stable
::Austria         : http://mirror.easyname.at/manjaro/stable
::Netherlands     : https://ftp.nluug.nl/pub/os/Linux/distr/manjaro/stable
::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist
:: Synchronizing package databases...
 core                            167.6 KiB   292 KiB/s 00:01 [################################] 100%
 extra                          1993.3 KiB  2.21 MiB/s 00:01 [################################] 100%
 community                         6.4 MiB  3.56 MiB/s 00:02 [################################] 100%
 multilib                        181.8 KiB  2.69 MiB/s 00:00 [################################] 100%
:: Starting full system upgrade...
 there is nothing to do

I hope if anyone runs into this they can figure it out, I reinstalled to fix this issue and to see if it would fix another issue I have posted about which was to do with Steam proton but please don’t close this as we really should investigate what happened so we can work together to fix it :grin:

In pamac-manager, if you Refresh databases before selecting Updates, does it make any difference.

In Preferences > AUR, do you have Check for updates set. If so, try the above once with it unchecked.

You were correct in creating a bug report according to this thread.

pacman and pamac have their own sync database (/var/lib/pacman/sync vs /tmp/pamac).

There’s also another program called checkupdates. If there are no updates, there is no other feedback other than an exit status/return code of 2. But otherwise it’ll list the packages, their current version and new version. pacman-mirrors will show the current status of your mirrors, same as https://repo.manjaro.org/.

Thanks for the update

No refreshing the database with pacman -Syyu for example since that was my only way to do it did not fix it but I did a fresh install so I cant test to see if disabling the AUR will work now but that could of been the issue