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#20243 - Pacman -Sy fails: segmentation fault

Attached to Project: Pacman
Opened by Daniele Stanzani (stanzani) - Wednesday, 21 July 2010, 07:28 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 18 August 2010, 15:06 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version 3.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

When launching pacman -Sy it segfaults.
This is the output of pacman -Sy --debug

debug: config: attempting to read file /etc/pacman.conf
debug: config: new section 'options'
debug: config: HoldPkg: pacman
debug: config: HoldPkg: glibc
debug: config: SyncFirst: pacman
debug: config: architecture: x86_64
debug: config: new section 'core'
debug: registering sync database 'core'
debug: config file /etc/pacman.conf, line 66: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'core': ftp://mi.mirror.garr.it/mirrors/archlinux/core/os/x86_64
debug: setlibpaths() called
debug: option 'cachedir' = /var/cache/pacman/pkg/
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: new section 'extra'
debug: registering sync database 'extra'
debug: config file /etc/pacman.conf, line 70: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'extra': ftp://mi.mirror.garr.it/mirrors/archlinux/extra/os/x86_64
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: new section 'community'
debug: registering sync database 'community'
debug: config file /etc/pacman.conf, line 78: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'community': ftp://mi.mirror.garr.it/mirrors/archlinux/community/os/x86_64
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: finished parsing /etc/pacman.conf
debug: registering local database
:: Synchronizing package databases...
debug: no file found matching criteria, starting from scratch
debug: using 'core.db.tar.gz' for download progress
debug: HTTP_PROXY: (null)
debug: http_proxy: (null)
debug: FTP_PROXY: (null)
debug: ftp_proxy: (null)
error: segmentation fault
Internal pacman error: Segmentation fault.
Please submit a full bug report with --debug if appropriate.

Steps to Reproduce:
Just launch pacman -Sy
This task depends upon

Closed by  Dan McGee (toofishes)
Wednesday, 18 August 2010, 15:06 GMT
Reason for closing:  Upstream
Additional comments about closing:  Glibc issue, see comments
Comment by Daniele Stanzani (stanzani) - Wednesday, 21 July 2010, 09:01 GMT
It seems that this issue occurs only when using ftp based repositories.
I personally use ftp://mi.mirror.garr.it/mirrors/archlinux/
When i switch to the http one, the error does not occur.
Comment by Dan McGee (toofishes) - Wednesday, 21 July 2010, 13:55 GMT
A gdb backtrace would be most helpful here. You will probably need to recompile libfetch and pacman/libalpm with debug symbols however...

Also, what architecture?
Comment by Daniele Stanzani (stanzani) - Thursday, 22 July 2010, 10:55 GMT
Architecture:
Linux 2.6.34-ARCH #1 SMP PREEMPT x86_64 AMD Phenom(tm) II X4 920 Processor AuthenticAMD GNU/Linux

My personal belief is that those errors happened because the ftp connection had a high latency due to high outgoing internet traffic in my office (i am looking thorugh it today). Maybe this is why using a http repository pacman didn't segfault. It seemed to me that a broken connection or a high latency connection over ftp protocol cause pacman to crash.
This is not a great issue as i thought yesterday, but I tried and tried to make pacman work (I had no output to understand what was going on) and finally I made a mistake and broke my installation. The progam shouldn't segfault in my opinion, it must end gracefully.

Actually, and for what I explained above, I do not know how to reproduce my low-latency connection or a broken connection.

Any suggestion?
Comment by Allan McRae (Allan) - Thursday, 22 July 2010, 12:25 GMT
I seem to remember another bug with weak wifi signals causing crashes. This sounds like the same thing.
Comment by Daniele Stanzani (stanzani) - Monday, 26 July 2010, 07:14 GMT
Ok i got it, i have recompiled pacman with debugging symbols i think, I hope this can help.

# gdb pacman
(gdb) run -Sy
Starting program: /usr/bin/pacman -Sy
[Thread debugging using libthread_db enabled]
:: Synchronizing package databases...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5956068 in ?? () from /lib/libnss_files.so.2
(gdb) backtrace
#0 0x00007ffff5956068 in ?? () from /lib/libnss_files.so.2
#1 0x00007ffff5956531 in _nss_files_getpwuid_r () from /lib/libnss_files.so.2
#2 0x00007ffff78f5ebd in getpwuid_r () from /lib/libc.so.6
#3 0x00007ffff78f826a in ?? () from /lib/libc.so.6
#4 0x00007ffff78f7f45 in getlogin () from /lib/libc.so.6
#5 0x00007ffff764eb15 in ?? () from /usr/lib/libfetch.so
#6 0x00007ffff764fd20 in ftp_request () from /usr/lib/libfetch.so
#7 0xff007ffff76507ce in ?? ()
#8 0x0000000000000048 in ?? ()
#9 0x00007fffffffe720 in ?? ()
#10 0x0000000000404210 in alpm_list_free@plt ()
#11 0x00007ffff7bc7949 in download_internal (url=0x7ffff78f7f45 "\205\300u\017H\215\005\360\177+", localpath=0x61b8e0 "\006", force=0) at dload.c:182
#12 0x0000000000000000 in ?? ()
Comment by Allan McRae (Allan) - Monday, 26 July 2010, 07:27 GMT
Any chance you could also compile libfetch with debug symbols?
Comment by Daniele Stanzani (stanzani) - Monday, 26 July 2010, 07:34 GMT
Ooops sorry :) here it comes with libfetch recompiled with debugging symbols

# gdb pacman
(gdb) run -Sy
Starting program: /usr/bin/pacman -Sy
[Thread debugging using libthread_db enabled]
:: Synchronizing package databases...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5956068 in ?? () from /lib/libnss_files.so.2
(gdb) backtrace
#0 0x00007ffff5956068 in ?? () from /lib/libnss_files.so.2
#1 0x00007ffff5956531 in _nss_files_getpwuid_r () from /lib/libnss_files.so.2
#2 0x00007ffff78f5ebd in getpwuid_r () from /lib/libc.so.6
#3 0x00007ffff78f826a in ?? () from /lib/libc.so.6
#4 0x00007ffff78f7f45 in getlogin () from /lib/libc.so.6
#5 0x00007ffff764eb15 in ftp_authenticate (conn=0x61b8e0, url=0x619880, purl=<value optimized out>) at ftp.c:1004
#6 0x00007ffff764fd20 in ftp_connect (url=0x619880, op=0x7ffff7653489 "STAT", op_arg=0x0, us=0x7fffffffe3a0, purl=0x0, flags=0x7ffff7bd7944 "") at ftp.c:1078
#7 ftp_request (url=0x619880, op=0x7ffff7653489 "STAT", op_arg=0x0, us=0x7fffffffe3a0, purl=0x0, flags=0x7ffff7bd7944 "") at ftp.c:1151
#8 0xff007ffff76507ce in ?? ()
#9 0x0000000000000048 in ?? ()
#10 0x00007fffffffe720 in ?? ()
#11 0x0000000000404210 in alpm_list_free@plt ()
#12 0x00007ffff7bc7949 in download_internal (url=0x7ffff78f7f45 "\205\300u\017H\215\005\360\177+", localpath=0x61b8e0 "\006", force=0) at dload.c:182
#13 0x0000000000000000 in ?? ()
Comment by Daniele Stanzani (stanzani) - Wednesday, 18 August 2010, 09:07 GMT
Thanks to Caleb on #archlinux (freenode.net) i have found that the issue happened on my system because of a misconfigured samba Windows AD authentication.
Properly removing in /etc/nsswitch.conf the authentication entries that uses samba (for users and groups) made things work (obviuosly a proper samba configuration make things work too).

I think that glibc (the segfaults happens in the glibc package) should not crash this way, but it is not an Archlinux issue :) .

Thank you all guys

Loading...