man-db exits return code 139 and seg faults

Bug #200831 reported by Marcus Wells
36
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdbm (Ubuntu)
Invalid
Undecided
Unassigned
man-db (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: man-db

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

I think it is this package (it's the man-db script run form cron.daily and cron.weekly that is causing the problem)
man-db:
  Installed: 2.4.4-3
  Candidate: 2.4.4-3
  Version table:
 *** 2.4.4-3 0
        500 http://nz.archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status

I'm getting dialy messages from cron as the man-db job is exexuted from cron.daily. They started with:

"/etc/cron.daily/man-db:
mandb: bad fetch on multi key intro 3
mandb: index cache /var/cache/man/6428 corrupt
run-parts: /etc/cron.daily/man-db exited with return code 2"

since jan 20th i've been getting:

"/etc/cron.daily/man-db:
Segmentation fault (core dumped)
run-parts: /etc/cron.daily/man-db exited with return code 139"

Please let me know if I can provide the more useful info!

Thanks

Marcus

ProblemType: Bug
Architecture: amd64
Date: Tue Mar 11 15:08:35 2008
DistroRelease: Ubuntu 7.10
NonfreeKernelModules: nvidia
Package: man-db 2.4.4-3
PackageArchitecture: amd64
SourcePackage: man-db
Uname: Linux ubuntu 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux

Tags: apport-bug
Revision history for this message
Marcus Wells (marcus-wells) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :
Download full text (7.8 KiB)

Manual retrace of core dump:

#0 0x00002b2be6eaa593 in ?? () from /usr/lib/libgdbm.so.3
#1 0x00002b2be6eaaa64 in _gdbm_alloc () from /usr/lib/libgdbm.so.3
#2 0x00002b2be6ea932c in gdbm_store () from /usr/lib/libgdbm.so.3
#3 0x000000000040cebb in dbstore (in=0x7fffc3c32140, basename=0x689940 "") at db_store.c:186
        ret = <value optimized out>
        oldkey = {dptr = 0x689920 "", dsize = 5}
        oldcont = {dptr = 0x689a10 "\tA\t-\t-\tgz\tATI Rage 128 video driver", dsize = 52}
#4 0x0000000000408dc0 in store_descriptions (head=<value optimized out>, info=0x7fffc3c32140, base_name=0x626784 "r128") at descriptions_store.c:90
        desc = (const struct page_description *) 0x689790
        save_id = 65 'A'
#5 0x00000000004082c6 in test_manfile (file=0x6894a0 "128 video driver", path=0x621660 "/usr/share/man") at check_mandirs.c:307
        physical = {st_dev = 140736477732976, st_ino = 47467557643432, st_nlink = 21, st_mode = 0, st_uid = 2, st_gid = 24, pad0 = 11051, st_rdev = 47467563235712, st_size = 0, st_blksize = 1,
  st_blocks = 6427792, st_atim = {tv_sec = 30, tv_nsec = 48}, st_mtim = {tv_sec = 47467560216953, tv_nsec = 48}, st_ctim = {tv_sec = 47467560209955, tv_nsec = 140736477733200}, __unused = {47467563235712, 21,
    0}}
        abs_filename = <value optimized out>
        base_name = 0x626784 "r128"
        ult = 0x6894d0 "an4/r128.4.gz"
        lg = {type = 0, whatis = 0x689620 "128 video driver", filters = 0x6897f0 ""}
        manpage = 0x626770 "/usr/share/man/man4"
        info = {next = 0x0, addr = 0x0, name = 0x0, ext = 0x626789 "4", sec = 0x626782 "4", id = 65 'A', pointer = 0x41959b "-", comp = 0x413004 "gz", filter = 0x6897f0 "", whatis = 0x689bc0 "eo driver",
  _st_mtime = 1191860216}
        exists = <value optimized out>
        buf = {st_dev = 2065, st_ino = 1234013, st_nlink = 1, st_mode = 33188, st_uid = 0, st_gid = 0, pad0 = 0, st_rdev = 0, st_size = 2216, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1204706395,
    tv_nsec = 0}, st_mtim = {tv_sec = 1191860216, tv_nsec = 0}, st_ctim = {tv_sec = 1200006860, tv_nsec = 0}, __unused = {0, 0, 0}}
        len = <value optimized out>
#6 0x00000000004085fe in testmandirs (path=0x621660 "/usr/share/man", last=1195066122) at check_mandirs.c:354
        dir = (DIR *) 0x6226d0
        mandir = <value optimized out>
        stbuf = {st_dev = 2065, st_ino = 1234000, st_nlink = 2, st_mode = 16877, st_uid = 0, st_gid = 0, pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {
    tv_sec = 1204708582, tv_nsec = 0}, st_mtim = {tv_sec = 1203445212, tv_nsec = 0}, st_ctim = {tv_sec = 1203445212, tv_nsec = 0}, __unused = {0, 0, 0}}
        amount = 0
#7 0x0000000000408a28 in update_db (manpath=0x621660 "/usr/share/man") at check_mandirs.c:563
        key = {dptr = 0x68a340 "", dsize = 8}
        content = {dptr = 0x68a380 "", dsize = 11}
        new = <value optimized out>
#8 0x000000000040306b in mandb (catpath=<value optimized out>, manpath=0x621660 "/usr/share/man") at mandb.c:325
        amount = <value optimized out>
        pid = "6615\000\000\000\000▒\024b", '\0' <repeats 11 times>
        amount = -7840
        dbname = 0x62...

Read more...

Changed in man-db:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Unfortunately I am a little puzzled here; I can see where it's failing, but the program state doesn't make as much sense as I'd like, and it looks like there may have been some memory corruption interfering with my ability to track down what's wrong. Could you please send me a little bit of extra information so that I can try to recreate this?

  * attach the file /var/cache/man/index.db to this bug
  * attach the output of 'dpkg-query -W' to this bug

Changed in man-db:
assignee: nobody → kamion
status: Confirmed → Incomplete
Revision history for this message
Marcus Wells (marcus-wells) wrote :

Hi Colin

Output of dpkg-query -W attached (dpkg_query)

Revision history for this message
Marcus Wells (marcus-wells) wrote :

Thanks for your time Colin!

/var/cache/man/index.db attached

Revision history for this message
Colin Watson (cjwatson) wrote :

Thanks. This database is corrupt; accessdb can't open it, and gdb indicates that the hash bucket storage is confused beyond words.

There are (at least) two bugs here. The first is that gdbm_store segfaults when trying to insert a new entry into this database, rather than exiting cleanly; I've created a new bug task for this. The second is that, at least before gdbm started segfaulting, mandb should have fallen back to creating the database from scratch. I'll see if I can at least address the latter bug.

The possible third bug is why the database became corrupt in the first place, but I doubt we can answer that now; it could have been filesystem corruption due to e.g. a power failure.

In the meantime, run 'sudo -u man mandb --create --quiet' and that should clear things up for you.

Colin Watson (cjwatson)
Changed in man-db:
assignee: kamion → nobody
importance: High → Medium
status: Incomplete → Confirmed
status: Confirmed → Triaged
Changed in gdbm (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.