FS#16210 - pacman causes glibc corruption on ctrl+c

Attached to Project: Pacman
Opened by Anish Bhatt (anish) - Tuesday, 15 September 2009, 19:19 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 05:08 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.3.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: interrupted pacman search with ctrl+c, resulted in this dump
could not reproduce problem.

Additional info:
pacman 3.3.0-3

trace :
bash-4.0# pacman -Ss flash
extra/flashplugin 10.0.32.18-1.1
Adobe Flash Player
extra/gnash-common 0.8.5-4
A GNU Flash movie player
extra/gnash-gtk 0.8.5-2
A GNU Flash movie player (gtk)
extra/kdeedu-kwordquiz 4.3.1-1 (kde kdeedu)
A flashcard and vocabulary learning program
extra/libflashsupport 9.0.21.78-5
Macromedia flash plugin support lib (OSS SSL)
extra/swfdec 0.8.4-1
free library for decoding and rendering Flash animations
^C
Interrupt signal received

*** glibc detected *** pacman: double free or corruption (out): 0x090f21d0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c249b1]
/lib/libc.so.6[0xb7c260b2]
/lib/libc.so.6(cfree+0x6d)[0xb7c2917d]
/usr/lib/libalpm.so.4[0xb7ef9cb9]
/usr/lib/libalpm.so.4(alpm_list_free_inner+0x27)[0xb7eebef7]
/usr/lib/libalpm.so.4[0xb7ef08a2]
/usr/lib/libalpm.so.4[0xb7ef2b0e]
/usr/lib/libalpm.so.4[0xb7ef2bb2]
/usr/lib/libalpm.so.4(alpm_db_unregister_all+0x4f)[0xb7ef2c0f]
/usr/lib/libalpm.so.4(alpm_release+0x28)[0xb7eebd78]
pacman[0x804d73e]
[0xb7f14400]
/usr/lib/libalpm.so.4(alpm_list_free_inner+0x27)[0xb7eebef7]
/usr/lib/libalpm.so.4[0xb7ef08a2]
/usr/lib/libalpm.so.4[0xb7ef2b0e]
/usr/lib/libalpm.so.4[0xb7ef2bb2]
/usr/lib/libalpm.so.4(alpm_db_unregister_all+0x4f)[0xb7ef2c0f]
/usr/lib/libalpm.so.4(alpm_release+0x28)[0xb7eebd78]
pacman[0x804d73e]
pacman[0x804e70d]
/lib/libc.so.6(__libc_start_main+0xe6)[0xb7bcfa36]
pacman[0x804b4b1]
======= Memory map: ========
08048000-08058000 r-xp 00000000 08:03 138608 /usr/bin/pacman
08058000-08059000 rwxp 00010000 08:03 138608 /usr/bin/pacman
08ef4000-091c9000 rwxp 00000000 00:00 0 [heap]
b7800000-b7821000 rwxp 00000000 00:00 0
b7821000-b7900000 ---p 00000000 00:00 0
b79a9000-b79c6000 r-xp 00000000 08:03 133924 /usr/lib/libgcc_s.so.1
b79c6000-b79c7000 rwxp 0001c000 08:03 133924 /usr/lib/libgcc_s.so.1
b79d3000-b7b54000 r-xp 00000000 08:03 143787 /usr/lib/locale/locale-archive
b7b54000-b7b55000 rwxp 00000000 00:00 0
b7b55000-b7b69000 r-xp 00000000 08:03 842135 /lib/libpthread-2.10.1.so
b7b69000-b7b6a000 ---p 00014000 08:03 842135 /lib/libpthread-2.10.1.so
b7b6a000-b7b6b000 r-xp 00014000 08:03 842135 /lib/libpthread-2.10.1.so
b7b6b000-b7b6c000 rwxp 00015000 08:03 842135 /lib/libpthread-2.10.1.so
b7b6c000-b7b6e000 rwxp 00000000 00:00 0
b7b6e000-b7b70000 r-xp 00000000 08:03 842132 /lib/libdl-2.10.1.so
b7b70000-b7b71000 r-xp 00001000 08:03 842132 /lib/libdl-2.10.1.so
b7b71000-b7b72000 rwxp 00002000 08:03 842132 /lib/libdl-2.10.1.so
b7b72000-b7b73000 rwxp 00000000 00:00 0
b7b73000-b7bb5000 r-xp 00000000 08:03 135947 /usr/lib/libssl.so.0.9.8
b7bb5000-b7bb9000 rwxp 00041000 08:03 135947 /usr/lib/libssl.so.0.9.8
b7bb9000-b7cf9000 r-xp 00000000 08:03 842152 /lib/libc-2.10.1.so
b7cf9000-b7cfb000 r-xp 00140000 08:03 842152 /lib/libc-2.10.1.so
b7cfb000-b7cfc000 rwxp 00142000 08:03 842152 /lib/libc-2.10.1.so
b7cfc000-b7cff000 rwxp 00000000 00:00 0
b7cff000-b7d12000 r-xp 00000000 08:03 133865 /usr/lib/libz.so.1.2.3.3
b7d12000-b7d13000 rwxp 00012000 08:03 133865 /usr/lib/libz.so.1.2.3.3
b7d13000-b7d22000 r-xp 00000000 08:03 842189 /lib/libbz2.so.1.0.4
b7d22000-b7d23000 rwxp 0000f000 08:03 842189 /lib/libbz2.so.1.0.4
b7d23000-b7d43000 r-xp 00000000 08:03 134978 /usr/lib/liblzma.so.0.0.0
b7d43000-b7d44000 rwxp 0001f000 08:03 134978 /usr/lib/liblzma.so.0.0.0
b7d44000-b7d45000 rwxp 00000000 00:00 0
b7d45000-b7e7e000 r-xp 00000000 08:03 135945 /usr/lib/libcrypto.so.0.9.8
b7e7e000-b7e94000 rwxp 00139000 08:03 135945 /usr/lib/libcrypto.so.0.9.8
b7e94000-b7e97000 rwxp 00000000 00:00 0
b7e97000-b7e9b000 r-xp 00000000 08:03 842175 /lib/libattr.so.1.1.0
b7e9b000-b7e9c000 rwxp 00003000 08:03 842175 /lib/libattr.so.1.1.0
b7e9c000-b7ea2000 r-xp 00000000 08:03 842176 /lib/libacl.so.1.1.0
b7ea2000-b7ea3000 rwxp 00005000 08:03 842176 /lib/libacl.so.1.1.0
b7ea3000-b7ed4000 r-xp 00000000 08:03 135962 /usr/lib/libarchive.so.2.7.0
b7ed4000-b7ed5000 rwxp 00031000 08:03 135962 /usr/lib/libarchive.so.2.7.0
b7ed5000-b7ed6000 rwxp 00000000 00:00 0
b7ed6000-b7ee3000 r-xp 00000000 08:03 135967 /usr/lib/libfetch.so
b7ee3000-b7ee4000 rwxp 0000c000 08:03 135967 /usr/lib/libfetch.so
b7ee4000-b7ee5000 rwxp 00000000 00:00 0
b7ee5000-b7f06000 r-xp 00000000 08:03 138614 /usr/lib/libalpm.so.4.0.0
b7f06000-b7f07000 rwxp 00020000 08:03 138614 /usr/lib/libalpm.so.4.0.0
b7f07000-b7f08000 rwxp 00000000 00:00 0
b7f13000-b7f14000 rwxp 00000000 00:00 0
b7f14000-b7f15000 r-xp 00000000 00:00 0 [vdso]
b7f15000-b7f31000 r-xp 00000000 08:03 842151 /lib/ld-2.10.1.so
b7f31000-b7f32000 r-xp 0001b000 08:03 842151 /lib/ld-2.10.1.so
b7f32000-b7f33000 rwxp 0001c000 08:03 842151 /lib/ld-2.10.1.so
bf9c4000-bf9d9000 rw-p 00000000 00:00 0 [stack]
Aborted


Steps to reproduce:
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 09 February 2013, 05:08 GMT
Reason for closing:  Works for me
Additional comments about closing:  Old crash that can not be replicated...
Comment by Xavier (shining) - Wednesday, 16 September 2009, 16:47 GMT
that looks interesting.

seems like alpm_release was called twice in parallel or something ?
Comment by Xavier (shining) - Wednesday, 16 September 2009, 17:15 GMT
btw, while trying to reproduce the problem (doing exactly what you did), I caused a deadlock. pacman was just stuck and would never end.

attaching gdb showed the following trace :

#0 0xb7fa6424 in __kernel_vsyscall ()
#1 0xb7d0fb23 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0xb7ca64ff in _L_lock_7246 () from /lib/libc.so.6
#3 0xb7ca4d46 in free () from /lib/libc.so.6
#4 0xb7f729da in _alpm_db_free (db=0x9f74be0) at db.c:350
#5 0xb7f72a6d in _alpm_db_unregister (db=0x9f74be0) at db.c:90
#6 0xb7f72aed in alpm_db_unregister_all () at db.c:108
#7 0xb7f6a9f6 in alpm_release () at alpm.c:69
#8 0x0804db99 in cleanup (ret=2) at pacman.c:218
#9 <signal handler called>
#10 0xb7ca29c4 in _int_malloc () from /lib/libc.so.6
#11 0xb7ca4e1f in malloc () from /lib/libc.so.6
#12 0xb7ca8290 in strdup () from /lib/libc.so.6
#13 0xb7f6deca in _alpm_db_read (db=0x9f74758, info=0xa184738,
inforeq=INFRQ_DESC) at be_files.c:552
#14 0xb7f7ccf9 in alpm_pkg_get_desc (pkg=0xa184738) at package.c:139
#15 0xb7f7268b in _alpm_db_search (db=0x9f74758, needles=0x9f73c08) at db.c:392
#16 0x080520cb in pacman_sync (targets=0x9f73c08) at sync.c:288
#17 0x0804ef15 in main (argc=3, argv=0xbf94ce34) at pacman.c:1123
Comment by Xavier (shining) - Wednesday, 16 September 2009, 17:54 GMT
I was also able to reproduce the original problem.
This seems to be a case of http://cwe.mitre.org/data/definitions/364.html

It seems we are doing exactly what is not recommended : doing a lot of stuff in signal handler, probably including calling non reentrant functions (libalpm?)

Dan, help ! :)
Comment by Dan McGee (toofishes) - Wednesday, 16 September 2009, 23:03 GMT
So I attempted to fix some of this a long time ago with commit 30851a, http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=30851a24ff68b00898565a1144926d83c623e6bf. Obviously I did not complete the job.

We have a few things left to tackle to make this all OK. Basically we still call the following functions from the signal handler, and we need to make them async-safe as well or find a better way to handle this madness:
* alpm_trans_interrupt()
* alpm_trans_release() (ha, good luck)
* cleanup() (also good luck, it calls alpm_release)

No way we are going to get this in 3.3.1. :)
Comment by Nagy Gabor (combo) - Thursday, 17 September 2009, 14:31 GMT
Yesterday I got the following, when I pressed ctrl-c during "pacman -Si" (pacman-git):
---
Leírás : An open-source, cross-platform software development library
for reading, writing, and manipulating
ID.pkg.tarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr55555555gvBelanger
<er156984
---
I cannot reproduce this, usually pacman runs into infinite loop.
Comment by Allan McRae (Allan) - Saturday, 09 February 2013, 05:07 GMT
So much has changed since this report - and I spent ages not trying to replicate without finding an issue. Closing...

Loading...