Arch Linux

"Please submit a full bug report with --debug if appropriate."
I would like to ask you to do so.

Well, given he said it is not reproducible, I don't think he can submit the debug information...

So can we track this down at all? It was in the middle of a (very slow) download so what could this have hit?

Oh, I missed the steps to reproduce part. Maybe his internet connection has broken. I can't reproduce this situation, the download part don't want to give up after "poff" ;-)

Yeah my guess would be network issues. This was done on a spotty wireless connection, which could very well have had a hiccup during the transfer. Seems like a good place to start, anyway.

Apologies for not including this info in the first place.

These type of unreproducible bugs are no fun, and we have seen issues during downloads before. If I had to guess I'd point the finger at some null pointer dereference in libdownload, but I don't know that for sure. Someone really needs to get a core dump or backtrace on this for us to have a chance at fixing it.

That said, I don't think it is high severity as it isn't leaving a package half-installed or anything, and it is easy to work around.

 FS#11100  provided a partial backtrace for this bug, but otherwise contains no new information. Please post all relevant info on this bug as that one will be closed as a dupe.

Not during package download, but during repository update. Reproducible: always. Note that this only happens when using the Dutch mirrors surfnet.nl or nluug.nl. Also memtest does not give any errors after running 48 hours non-stop.

debug: using 'community.db.tar.gz' for download progress
debug: existing file found, using it
debug: HTTP_PROXY: (null)
debug: http_proxy: (null)
debug: FTP_PROXY: (null)
debug: ftp_proxy: (null)
debug: connected to ftp.surfnet.nl successfully
downloading community.db.tar.gz...

Program received signal SIGSEGV, Segmentation fault.
0x00007f732d63cddb in mempcpy () from /lib/libc.so.6

#0 0x00007f732d63cddb in mempcpy () from /lib/libc.so.6
#1 0x00007f732d631553 in _IO_default_xsgetn_internal () from /lib/libc.so.6
#2 0x00007f732d62415f in fread () from /lib/libc.so.6
#3 0x00007f732e58f451 in download_internal () from /usr/lib/libalpm.so.3
#4 0x00007f732e58fcdf in _alpm_download_single_file () from /usr/lib/libalpm.so.3
#5 0x00007f732e58967d in alpm_db_update () from /usr/lib/libalpm.so.3
#6 0x0000000000409727 in pacman_sync ()
#7 0x0000000000407104 in main ()

I reinstalled 3.2.2 just to check, and I definitely cannot reproduce this issue. Can anyone else reproduce?
If you feel motivated, you could try out pacman-git which also uses a more recent version of the download library. You will have to install libfetch from the testing repo :
ftp://ftp.archlinux.org/testing/os/i686/libfetch-2.20-1-i686.pkg.tar.gz
Then you can add dan's repo :
[pacman-git]
Server = http://dev.archlinux.org/~dan/pacman-git/

Then install pacman-git, and see if it solves the issue. Otherwise, post again the gdb backtrace, this version should have debug symbols so it could be more helpful.

Happened to me today:

[root@xxxxxxxx xxxx]# pacman -Syu
:: Synchronizing package databases...
error: segmentation fault 10.0K 0.3K/s 00:01:06 [#############----------------------------] 31%
Internal pacman error: Segmentation fault.
Please submit a full bug report with --debug if appropriate.
[root@xxxxxxxx xxxx]#

Again after rm /var/lib/pacman/db.lck

[root@xxxxxxxx xxxx]# pacman -Syu --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: IgnorePkg: brasero
debug: config: IgnorePkg: libbeagle
debug: config: IgnorePkg: kernel26
debug: config: IgnorePkg: splix
debug: config: new section 'core'
debug: setlibpaths() called
debug: option 'cachedir' = /var/cache/pacman/pkg/
debug: registering sync database 'core'
debug: opening database 'core'
debug: opening database from path '/var/lib/pacman/sync/core/'
debug: config: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'core': ftp://mirror.cs.vt.edu/pub/ArchLinux/core/os/x86_64
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: new section 'extra'
debug: registering sync database 'extra'
debug: opening database 'extra'
debug: opening database from path '/var/lib/pacman/sync/extra/'
debug: config: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'extra': ftp://mirror.cs.vt.edu/pub/ArchLinux/extra/os/x86_64
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: new section 'community'
debug: registering sync database 'community'
debug: opening database 'community'
debug: opening database from path '/var/lib/pacman/sync/community/'
debug: config: including /etc/pacman.d/mirrorlist
debug: config: attempting to read file /etc/pacman.d/mirrorlist
debug: adding new server URL to database 'community': ftp://mirror.cs.vt.edu/pub/ArchLinux/community/os/x86_64
debug: config: finished parsing /etc/pacman.d/mirrorlist
debug: config: finished parsing /etc/pacman.conf
debug: registering local database
debug: opening database 'local'
debug: opening database from path '/var/lib/pacman/local/'
:: Synchronizing package databases...
debug: using 'core.db.tar.gz' for download progress
debug: existing file found, using it
debug: HTTP_PROXY: (null)
debug: http_proxy: (null)
debug: FTP_PROXY: (null)
debug: ftp_proxy: (null)
debug: connected to mirror.cs.vt.edu successfully
downloading core.db.tar.gz...
error: segmentation fault
Internal pacman error: Segmentation fault.
Please submit a full bug report with --debug if appropriate.
[root@xxxxxxxx xxxx]#

I switched the mirror to ftp.archlinux.org and all is well...

Sorry, I forget some info:

Last -Syu:
[2009-02-15 00:57] starting full system upgrade

[root@xxxxxxxx xxxx]# pacman -Q glibc kernel26 pacman
glibc 2.9-4
kernel26 2.6.28.6-1
pacman 3.2.2-1

Sorry, I forget some info:

Last -Syu:
[2009-02-15 00:57] starting full system upgrade

[root@xxxxxxxx xxxx]# pacman -Q glibc kernel26 pacman
glibc 2.9-4
kernel26 2.6.28.6-1
pacman 3.2.2-1

Without a backtrace we really can't do anything here, and I have a hunch this is a bug in libdownload that hopefully doesn't exist in libfetch.

Well I had this segfault constantly today when trying to update at the uni library. The wireless is always a bit flaky, but a segfault is unaceptable.
It seems to be working fine now at home.

If I can reproduce this segfault tomorrow I would be glad to help out and do a backtrace (I'll need instructions though).

can you try with pacman 3.3 and libfetch?

i686 :
pacman -U ftp://ftp.archlinux.org/testing/os/i686/libfetch-2.23-1-i686.pkg.tar.gz
add dan's repo :
[pacman-git]
Server = http://dev.archlinux.org/~dan/pacman-git/

x86-64 :
pacman -U ftp://ftp.archlinux.org/testing/os/x86_64/libfetch-2.23-1-x86_64.pkg.tar.gz
add dan's repo :
[pacman-git-64]
Server = http://dev.archlinux.org/~dan/pacman-git/


Then pacman -S pacman-git

The same bug - segfault while downloading new packages. pacman 3.3.0-3. I attached log with --debug switch. Any other debug info is needed? It occurs every time I try upgrade my system.

May be it'll be helpful. Sometimes even in normal mode pacman fails with backtrace. I attached it.

what do you mean with normal mode? not during download?

Konstantin, the segment fault occurs during download, I mean, when the download progressbar shows, say, 60%?

Normal mode = NOT debug mode. I don't understand why, but backtrace outputs only in some cases. Second log is pacman launch not in debug mode but with backtrace. First - in debug mode, but without backtrace.

Yes, segmentation fault occurs during download. Pacman can download 1-2 packages correctly and crash on the 3rd. Or it can crash on the first package. Always on downloading. Now I have more than 10 packages for update, so on my system this bug is reproducable :-)) I see segfault every time I launch pacman. Tell me what debug tools I should use and I'll send you detailed info.

attached libfetch and pacman pkgbuild to get debug symbols
libfetch : source PKGBUILD && mksource && makepkg -i
pacman : makepkg -i

gdb pacman
(gdb) run -S foo
...
(gdb) bt full

I have libfetch-2.23-1 installed - and it is up-to-date according [core] repository. May be that's why I have error while building of libfetch:
... a screen of cvs output ...
==> Making package: libfetch 2.24-1 i686 (Fri Aug 7 22:36:19 NOVST 2009)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
-> Found Makefile in build dir
-> Found libfetch-2.24.tar.gz in build dir
==> Validating source files with md5sums...
Makefile ... Passed
libfetch-2.24.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!

I fixed version number in PKGBUILD to 2.23-1 and receive the same error. Should I enable [testing] repos for libfetch?

no, its just me who bumped to 2.24, which is the latest release.
I didnt know which one to test first, the current 2.23 version arch is using or the new 2.24
to use 2.23 : just use the source from ftp.archlinux.org and fix the integrity check
to use 2.24 : you have to create the source with : source PKGBUILD && mksource

I install libfetch-2.24-1. Backtrace in attach. I hope it will helpful.

I've been having this issue with pacman 3.3.0-3 these last few days on x86_64. It's quite annoying.

We (Xavier and I) know the issue and have been in contact with the upstream libfetch developer. We have a fix.

http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/net/libfetch/files/ftp.c
"libfetch-2.24:
Fix a bug in the line reading optimisation, which could get confused if
the byte following the new line is a NUL. Adresses Arch Linux problem
report #15845."

Actually when I compared the code of libdownload and libfetch, one of the main difference I saw was this line optimisation stuff. But well this code was not trivial so I never found the bug :)

However, the bad news is that this original bug was reported against libdownload, so it should have been a different issue. But maybe this issue no longer exists with libfetch.

So I will close this bug because I think it's too old and no longer valid. The current discussion follows in  FS#15845 , we will push a new libfetch package with a fix.