What glibc version do you have?

I have glibc 2.12.1-3.
I have tried a pacman -S glibc, and it worked. I have glibc 2.12.1-4 now.

The problem is due to the orc package (a friend of mine helped me to find it out). Everything works well, except when i want to upgrade this package. The orc package which is installed is "extra/orc 0.4.7-1", and i tried to upgrade it to "extra/orc 0.4.11-1", unsuccesfully, leading me to a segfault. I also tried to use another mirror (from archlinux.fr to archlinux.org), but it didn't change a thing.
And I don't know if it can be usefull, but my ArchLinux ran into a virtual machine (virtualbox).

Could you try to get a backtrace in gdb ?

https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

I have exactly the same problem. Pacman crashes when run with -Syu. It works fine, when I run -S somepkg.
Here is my gdb trace, but only without debugging symbols:

Starting program: /usr/bin/pacman -Syu
[Thread debugging using libthread_db enabled]
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78d8d66 in strcmp () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78d8d66 in strcmp () from /lib/libc.so.6
#1 0x00007ffff7bd4b7f in alpm_trans_prepare () from /usr/lib/libalpm.so.5
#2 0x000000000040a47d in ?? ()
#3 0x0000000000407137 in ?? ()
#4 0x00007ffff787dc4d in __libc_start_main () from /lib/libc.so.6
#5 0x00000000004041c9 in ?? ()
#6 0x00007fffffffea68 in ?? ()
#7 0x000000000000001c in ?? ()
#8 0x0000000000000002 in ?? ()
#9 0x00007fffffffecc9 in ?? ()
#10 0x00007fffffffecd9 in ?? ()
#11 0x0000000000000000 in ?? ()
(gdb) quit

It seems the package has been reported. I can close the ticket i think (if i can ?).

Sounds like we are leaking a NULL string through somewhere? We should probably still fix/check this, if someone can keep the bad package and database around that would be good.

If you could send us a copy of the broken package and a broken database (just tar up whole /var/lib/pacman/ so that both sync and local db are covered), it would indeed be helpful.

In my case, these package are corrupted:
http://blema.cz/temp/pacman.corrupted

Here you can find corresponding /var/lib/pacman:
http://blema.cz/temp/var.lib.pacman.tbz

WTF happened here?
dmcgee@galway /tmp/var/lib/pacman/sync/core/coreutils-8.7-1
$ cat desc
P1010250a.JPGP1010255a.JPGP1010260a.JPGP1010341a.JPGP1010344a.JPGP1010345a.JPGP1010348a.JPGP1010349a.JPGP1010365a.JPGP1010370a.JPGP1010372a.JPGP1010439a.JPGP1010442a.JPGP1010445a.JPGP1010447a.JPGP1010450a.JPGP1010453a.JPGP1010455a.JPGP1010461a.JPGP1010469a.JPGP1010476a.JPGP1010479a.JPGL��u/home/civ/kb-klic
stare certifikatyČÍŽEK_VÍTĚZSLAV.p12L��u/h

That is not cool at all. I'm also not sure how this is related to the original report that seemed to point at extra/orc being busted. And what the heck was reported, is this some other ticket in our tracker?

Also of note: the core sync folder is missing letters g-m, only has 128 folders. Compare that to the 179 that are currently in core. I'm sure the others are messed up too.
$ ./src/pacman/pacman --dbpath /tmp/var/lib/pacman/ -Si kernel26
error: package 'kernel26' was not found

I can reproduce (using pacman-maint branch):
$ fakeroot ./src/pacman/pacman --dbpath /tmp/var/lib/pacman/ -Su
:: Starting full system upgrade...
:: Replace python-numpy with extra/python2-numpy? [Y/n] y
error: segmentation fault
Internal pacman error: Segmentation fault.
Please submit a full bug report with --debug if appropriate.

With GDB:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff603bd66 in strcmp () from /lib/libc.so.6
(gdb) bt full
#0 0x00007ffff603bd66 in strcmp () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff79c9ec7 in check_arch (data=0x7fffffffde30) at trans.c:110
pkg = 0x722a50
pkgarch = 0x6852f0 "x86_64"
i = 0x85a510
invalid = <value optimized out>
arch = 0x616920 "x86_64"
#2 alpm_trans_prepare (data=0x7fffffffde30) at trans.c:148
trans = 0x65ace0
__func__ = "alpm_trans_prepare"
invalid = 0x0

Which is actually a lie if you add a printf; turns out pkgarch is null and we die, not surprising since we did 0 sanity checks on the values here. Adding a null check to pkgarch fixes the problem (we already checked if arch was null outside the loop). Patch going to the ML.

Eh, the g-m in core missing is my mistake. Here's correct tarball:
http://blema.cz/temp/var.lib.pacman.g-m.tbz

I deleted them, when trying to search for corrupted package.

An additional corrupted package is here core/linux-firmware.

Your database is screwed., there is no way we can fix that, as I have no idea what happened to get the contents you have in there. With that said, we can at least keep from segfaulting, which is what my patch will fix.