andrewgregory / pacutils

Helper library for libalpm based programs.
MIT License
107 stars 17 forks source link

pacfile dumps core ("corrupted size vs. prev_size in fastbins") #43

Closed dvzrv closed 3 years ago

dvzrv commented 3 years ago

Hi! :)

When using pacfile, it dumps core on some files

$ pacfile /usr/bin/pacfile
file:   usr/bin/pacfile
owner:  pacutils
backup: no
mode:   755
type:   file
mtime:  2020-05-10 21:54:48
owner:  0/root
group:  0/root
size:   22.11 K
sha256: 23bf71e637d4fd18a790903abc4da69530ad02775d5262d1ef0f4def19fe55ef
md5sum: c820842dfc8b0fe0dec035292ee3ab1f
corrupted size vs. prev_size in fastbins
[1]    3227903 abort (core dumped)  pacfile /usr/bin/pacfile

This is the plain coredump for the above (without debug symbols):

           PID: 3227903 (pacfile)
           UID: 1000 (dave)
           GID: 1000 (dave)
        Signal: 6 (ABRT)
     Timestamp: Fri 2021-04-09 10:28:43 CEST (2min 35s ago)
  Command Line: pacfile /usr/bin/pacfile
    Executable: /usr/bin/pacfile
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/tmux.service
          Unit: user@1000.service
     User Unit: tmux.service
         Slice: user-1000.slice
     Owner UID: 1000 (dave)
       Boot ID: 1c56cd1e7e664169826ca228e5528714
    Machine ID: a5640b7a4f7946aa8d2d075962e96526
      Hostname: hmbx
       Storage: /var/lib/systemd/coredump/core.pacfile.1000.1c56cd1e7e664169826ca228e5528714.3227903.1617956923000000.zst (present)
     Disk Size: 8.1M
       Message: Process 3227903 (pacfile) of user 1000 dumped core.

                Stack trace of thread 3227903:
                #0  0x00006ace3a4baef5 raise (libc.so.6 + 0x3cef5)
                #1  0x00006ace3a4a4862 abort (libc.so.6 + 0x26862)
                #2  0x00006ace3a4fcf38 __libc_message (libc.so.6 + 0x7ef38)
                #3  0x00006ace3a504bea malloc_printerr (libc.so.6 + 0x86bea)
                #4  0x00006ace3a505ca4 malloc_consolidate (libc.so.6 + 0x87ca4)
                #5  0x00006ace3a5064a0 _int_free (libc.so.6 + 0x884a0)
                #6  0x00006ace3a509ca8 __libc_free (libc.so.6 + 0x8bca8)
                #7  0x00006ace38efe0b3 n/a (libp11-kit.so.0 + 0x290b3)
                #8  0x00006ace3a7a123b _dl_fini (ld-linux-x86-64.so.2 + 0x1023b)
                #9  0x00006ace3a4bd697 __run_exit_handlers (libc.so.6 + 0x3f697)
                #10 0x00006ace3a4bd83e exit (libc.so.6 + 0x3f83e)
                #11 0x00006ace3a4a5b2c __libc_start_main (libc.so.6 + 0x27b2c)
                #12 0x00000c58dd3d771e n/a (pacfile + 0x271e)

However, it works for others:

$ pacfile /usr/bin/bsdtar
file:   usr/bin/bsdtar
owner:  libarchive
backup: no
mode:   755
type:   file
mtime:  2020-12-26 19:52:02
owner:  0/root
group:  0/root
size:   69.97 K
sha256: 1b2fdae7235c8a17b8a18c98ac5c882ae5941b05b7c0a1f02887c3bc3b09abc2
md5sum: e5df19584cc182a93568e80c0a3cfbc5

Is this by any chance related to corruption in the .files sync database?

andrewgregory commented 3 years ago

Just a boring double free.