[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Segfault aufter dist-upgrade on woody

Dear List,

at the beginning of September I did an "apt-get update" and "apt-get
upgrade" on a Woody installation. The upgraded packages were (IIRC)
libpng2/3 and rsync. Exactly on that day tripwire stopped working, i.e. it
delivers a segmentation fault. The rest of the system seemed to work fine
at first, until I discovered recently that also dpkg creates a segfault.

The system was setup by two CS students at our university, so I don't know
all the details of the installation. I know that they have compiled their
own kernel (2.4.19). They claim to have added two extra drivers (as
modules) (via-rhine.c:v1.10-LK1.1.14 and sundance.c:v1.01b 17-Jan-2002).
But aren't these part of the 2.4.19 source??

The tripwire package is also compiled from sources (version, as
is the samba suite (version 2.2.9). All the rest is standard Woody, as far
as I know.

I have done an strace of a call to tripwire and dpkg, they end with the
following lines:

strace of tripwire

read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40076000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
write(2, "Software interrupt forced exit: "..., 51) = 51
munmap(0x40077000, 4096)                = 0
_exit(8)                                = ?

strace of dpkg

mremap(0x4018f000, 1007616, 1011712, MREMAP_MAYMOVE) = 0x4018f000
mremap(0x4018f000, 1011712, 1015808, MREMAP_MAYMOVE) = 0x4018f000
mremap(0x4018f000, 1015808, 1019904, MREMAP_MAYMOVE) = 0x4018f000
mremap(0x4018f000, 1019904, 1024000, MREMAP_MAYMOVE) = 0x402b2000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

I have run memcheck for around 3 hours (6 passes) with no errors. I have
also done an fsck on all partitions (except swap).

Any ideas where to look? How would I further analyse the problem?

Best regards and thanks to everyone willing to help,
Stefan (debian @ goessling . de)

Reply to: