Investigating SIGABRT problems on Debian

3 days ago, after a Debian(squeeze/sid) upgrade on my laptop some programs started not to open. Specifically, pidgin and google-chrome were crashing while trying to open them. When I started them from a terminal the output was this:

kargig@laptop:~%pidgin
[1]    3853 abort      pidgin
kargig@laptop:~%google-chrome
[1]    3882 abort      google-chrome

The first thing I checked was the updated packages, whether there was some culprit.
The upgraded packages included among others:

[UPGRADE] libk5crypto3 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libkrb5-3 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libkrb5support0 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libnspr4-0d 4.8.4-2 -> 4.8.6-1
[UPGRADE] libnss3-1d 3.12.6-3 -> 3.12.8-1
[UPGRADE] linux-base 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-headers-2.6.32-5-686-bigmem 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-headers-2.6.32-5-common 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-image-2.6.32-5-686-bigmem 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-libc-dev 2.6.32-23 -> 2.6.32-25
[UPGRADE] xserver-xorg-video-intel 2:2.9.1-4 -> 2:2.12.0+shadow-2

My first point of checking was the xserver-xorg-video package. I started searching the Debian bug tracking system for references of crashes with abort. Nothing. Then I tried to check the other “suspicious” packages with abort crash reports on the bug tracker…still nothing.
It was time for strace.

kargig@laptop:~%strace pidgin
...
[snip]
...
open("/usr/lib/nss/libfreebl3.so", O_RDONLY) = 14
read(14, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\30\0\0004\0\0\0"..., 512) = 512
fstat64(14, {st_mode=S_IFREG|0644, st_size=253328, ...}) = 0
mmap2(NULL, 268988, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 14, 0) = 0xb58e3000
mmap2(0xb5920000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 14, 0x3d) = 0xb5920000
mmap2(0xb5921000, 15036, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb5921000
close(14)                               = 0
open("/etc/ld.so.cache", O_RDONLY)      = 14
fstat64(14, {st_mode=S_IFREG|0644, st_size=79200, ...}) = 0
mmap2(NULL, 79200, PROT_READ, MAP_PRIVATE, 14, 0) = 0xb5ab7000
close(14)                               = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/swiftfox/libnspr4.so", O_RDONLY) = 14
read(14, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\227\0\0004\0\0\0"..., 512) = 512
fstat64(14, {st_mode=S_IFREG|0755, st_size=251136, ...}) = 0
close(14)                               = 0
munmap(0xb5ab7000, 79200)               = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(4027, 4027, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
[1]    4026 abort      strace pidgin

What immediately caught my eye was this line inside the output:
open("/usr/lib/swiftfox/libnspr4.so", O_RDONLY) = 14
I have a 3rd party package called swiftfox installed, but why was pidgin trying to use this package’s library instead of the system one ?

# ldconfig -p | grep nspr4
ldconfig -p | grep nspr4
  libnspr4.so.0d (libc6) => /usr/lib/libnspr4.so.0d
  libnspr4.so (libc6) => /usr/lib/swiftfox/libnspr4.so
  libnspr4.so (libc6) => /usr/lib/libnspr4.so

So the system package libnspr4-0d has installed its files in /usr/lib/libnspr4.so.0d and has also placed a symlink from /usr/lib/libnspr4.so to /usr/lib/libnspr4.so.0d. For some reason though the /usr/lib/swiftfox/libnspr4.so appears before /usr/lib/libnspr4.so in the cache output for the libnspr4.so library.
Checking out /etc/ld.so.conf.d/ directory, there was a moz.conf file containing the path “/usr/lib/swiftfox/“.
An “ldconfig -v” confirmed the finding:

/usr/local/lib:
/usr/lib/swiftfox:
        libnssckbi.so -> libnssckbi.so
        libssl3.so -> libssl3.so
        libsqlite3.so -> libsqlite3.so
        libnssutil3.so -> libnssutil3.so
        libnss3.so -> libnss3.so
        libnspr4.so -> libnspr4.so
        libsmime3.so -> libsmime3.so
        libmozjs.so -> libmozjs.so
        libsoftokn3.so -> libsoftokn3.so
        libplc4.so -> libplc4.so
        libxul.so -> libxul.so
        libplds4.so -> libplds4.so
        libxpcom.so -> libxpcom.so
        libnssdbm3.so -> libnssdbm3.so
        libfreebl3.so -> libfreebl3.so
/lib:
        libnss_compat.so.2 -> libnss_compat-2.11.2.so
        libselinux.so.1 -> libselinux.so.1
...
[snip]
...

Moving /usr/lib/swiftfox/libnspr4.so to some other location allowed applications like pidgin and google-chrome to start normally (and swiftfox still runs properly).

I guess that was my punishment for using 3rd party packages on Debian…

*UPDATE 23/11/2010*
Google chrome was crashing with some https:// sites with SIGABRT. After further investigation I had to delete /usr/lib/swiftfox/libnssutil3.so as well.

Awesome Tech Support by Seagate

This post is about a friend who had a faulty (firmware bug) hard disk replaced by Seagate…

A few months ago she bought a Seagate Barracuda 7200.11 500 GB loaded with firmware SD15. This specific firmware is known to be buggy and Seagate has provided a firmware upgrade for them, but of course she had no idea about that bug. Everything was OK until one day, suddenly, the BIOS couldn’t detect the disk. It didn’t take her long to find out the cause of the problem…

After several failed attempts to upgrade her firmware following the instructions placed at Seagate’s site she decided to send her disk to Greek companies that specialized on data recovery. One of them broke the seals of her disk but failed(!!) to do anything else. The other companies, asked a serious amount of money, 200-1000 Euros(!!!) in order to handle her case/take a preliminary look at the disk.

Fed up with those companies she finally decided to contact Seagate herself and she was given instructions via telephone to complete the online application form for technical support and data recovery.

The very next day, a courier took her disk, delivered it to Seagate Labs at Amsterdam and within a week, she had her disk brought back, totally repaired, with all her data intact(!!). Everything was free and her data was saved.

So the next time you have a hard disk problem, especially if it is a Seagate disk, contact Seagate before contacting these “specialized data recovery companies”. sigh.