Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#23750 - Pacman segfaults when installing telepathy from testing

Attached to Project: Pacman
Opened by accountkiller (rekado) - Wednesday, 13 April 2011, 14:29 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 01 June 2011, 21:39 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture i686
Severity Low
Priority Normal
Reported Version 3.5.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
pacman segfaults when installing telepathy from testing after repeatedly failing to download libpurple from different Chinese mirrors.

Steps to Reproduce:
1) Enable testing repository.
2) pacman -Syu
3) reboot
4) pacman -S telepathy

Attached is the output of --debug which I'm afraid is pretty worthless in this case. I will reproduce the segfault again and attach a core file if possible.
   pacman.segfault.log (65.2 KiB)
This task depends upon

Closed by  Dan McGee (toofishes)
Wednesday, 01 June 2011, 21:39 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Upstream issue with libfetch; switching to libcurl in next major release of pacman. Workaround: xfercommand for now.
Comment by accountkiller (rekado) - Wednesday, 13 April 2011, 14:36 GMT
Weird. Still segfaults, but no core is dumped, despite ulimit -c being ulimited.
Comment by Dan McGee (toofishes) - Wednesday, 13 April 2011, 14:44 GMT
Can you try running under gdb and get a backtrace? e.g. something like
sudo gdb --args pacman -S telepathy

And then do "bt full" when it segfaults.
Comment by Xavier (shining) - Wednesday, 13 April 2011, 14:55 GMT
Is it normal that the error segfault line is not the last one in that log ?

Does the segfault always occur when downloading from mirrors.sohu.com ? If yes, also if you put only that mirror in the mirror list ?
Comment by accountkiller (rekado) - Wednesday, 13 April 2011, 15:27 GMT
Meh. I haven't changed anything, but now I cannot get pacman to segfault again. I commented all mirrors but mirrors.sohu.com, yet I only get "error: failed retrieving file ... from mirrors.sohu.com".

Of course there is the chance that this is a hardware fault, though I find it interesting that this has happened right after I enabled testing and rebooted.
Comment by accountkiller (rekado) - Wednesday, 13 April 2011, 15:48 GMT
Segfaulted again after I removed all of telepathy and tried to reinstall it again (with all previously commented mirrors re-enabled). The attached backtrace is not very helpful, I guess, because pacman is not built with debugging symbols.
   gdb.txt (1 KiB)
Comment by Dan McGee (toofishes) - Wednesday, 13 April 2011, 16:01 GMT
#0 0xb7eadb2a in strcmp () from /lib/libc.so.6
#1 0xb7e2d64e in fetch_cache_put () from /usr/lib/libfetch.so
#2 0xb7e32bee in ?? () from /usr/lib/libfetch.so
#3 0xb7e2e968 in fetchIO_close () from /usr/lib/libfetch.so

This part is plenty helpful; we know the issue takes case in libfetch code and not ours, and is something to do with connection caching.

It has to be this line in fetch_cache_put():
if (strcmp(conn->cache_url->host, iter->cache_url->host) == 0)

Which means one of those is likely a null pointer, so getting to the root of that is important. It looks like we blow up on HTTP since the mirror name goes by twice in your first debug output, so the ?? function in the stack trace would be http_closefn().

Something a tad worrying to me is the following...

$ grep 'ust.size' pacman.segfault.log
debug: ust.size: 5366144 local_size: 91130 compare: -5275014
debug: ust.size: 5366144 local_size: 3985886 compare: -1380258
debug: ust.size: 5366144 local_size: 1205 compare: -5364939
debug: ust.size: 5366144 local_size: 1402 compare: -5364742
Comment by accountkiller (rekado) - Wednesday, 18 May 2011, 15:01 GMT
Happened again while attempting to retrieve linux-firmware-20110512 via wireless connection. This seems to happen when the reception is poor. Should I rather file a bug with the maintainers of libfetch since the segfault happens not in the pacman code?
Comment by Dan McGee (toofishes) - Thursday, 19 May 2011, 21:21 GMT
If you want; they haven't responded to a bug I filed 2-3 months ago though so it seems things are up in the air upstream at NetBSD. We're moving to libcurl with the next major version of libalpm so this problem will likely go away all on its own by then. Until then you might just have to work around this by restarting the download or using XferCommand if it happens a lot.

Loading...