Re: Bug#1508: Segmentation fault while installing...
Karl Ferguson writes ("Bug#1508: Segmentation fault while installing..."):
> [...]
> [root@stargate:2:/pub/linux/debian/debian-0.93/binary/base] dpkg -i adduser-
> 1.94-1.deb
> (Reading database ... 6380 files and directories currently installed.)
> Preparing to replace adduser (using adduser-1.94-1.deb) ...
> Unpacking replacement adduser ...
> Segmentation fault (core dumped)
> [root@stargate:2:/pub/linux/debian/debian-0.93/binary/base]
You're running NIS, aren't you ? Read on ...
> This happened on BOTH my machines which currently run Debian 0.93R5. I
> wondered if is was adduser itself, so I tried installing acct again from the
> admin directory - same error. It couldn't possibly be something wrong
> hardware wise becuase it's happening on both my PCs...
I asked Karl for a copy of the coredump, which he kindly sent me:
chiark:d> gdb ../../things/debian/dpkg-0.93.77/main/dpkg core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (i486-debian-linux), Copyright 1995 Free Software Foundation, Inc...
warning: exec file is newer than core file.
Core was generated by `dpkg'.
#0 0x60014516 in end ()
(gdb) where
#0 0x60014516 in end ()
#1 0x76b00 in end ()
#2 0x60014361 in end ()
#3 0x1767f in DecodeTarHeader (block=0xbffff670 "", d=0xbffff64c)
at tarfn.c:61
#4 0x179be in TarExtractor (userData=0x24294, functions=0x7354) at tarfn.c:110
#5 0x8ffa in process_archive (
filename=0xbffffeb8 "/pub/linux/debian/debian-0.93/binary/base/adduser-1.94-1.deb") at processarc.c:481
#6 0x723f in archivefiles (argv=0xbffffe78) at archives.c:556
#7 0x251d in main (argc=3, argv=0xbffffe78) at main.c:293
(gdb) up
#1 0x76b00 in end ()
(gdb) up
#2 0x60014361 in end ()
(gdb) up
#3 0x1767f in DecodeTarHeader (block=0xbffff670 "", d=0xbffff64c)
at tarfn.c:61
61 struct group * group = getgrnam(h->GroupName);
(gdb) print h
$1 = (TarHeader *) 0xbffff670
(gdb) print *h
$2 = {Name = '\000' <repeats 99 times>, Mode = "\000\000\000\000\000\000\000",
UserID = "\000\000\000\000\000\000\000",
GroupID = "\000\000\000\000\000\000\000", Size = '\000' <repeats 11 times>,
ModificationTime = '\000' <repeats 11 times>,
Checksum = "\000\000\000\000\000\000\000", LinkFlag = 0 '\000',
LinkName = '\000' <repeats 99 times>,
MagicNumber = "\000\000\000\000\000\000\000",
UserName = '\000' <repeats 31 times>, GroupName = '\000' <repeats 31 times>,
MajorDevice = "\000\000\000\000\000\000\000",
MinorDevice = "\000\000\000\000\000\000\000"}
(gdb) quit
chiark:d>
I think this is another user who has been bitten by Bug#1278: getgrnam
dumps core if you are using NIS and feed it an empty string (NB, not a
null pointer, an empty string).
Can the libc maintainer please fix this ? Pretty please ?
This bug probably makes dpkg well-nigh unuseable on systems using NIS.
Karl, the solution is to take the `+' out of your group or passwd file
(I don't know whether you have to take it out of just one or out of
both) and then to try it again.
If you're *not* running NIS please let me know, as then I have more
investigating to do.
I'm closing this bug report, as I think it's a duplicate of #1278.
Ian.
Reply to: