#326762 ypserv segfaults at startup on sparc

Package:
ypserv
Source:
ypserv
Description:
Server daemon for working with Network Information System (NIS)
Submitter:
Ralph Rößner
Date:
2021-01-24 15:45:03 UTC
Severity:
important
#326762#5
Date:
2005-09-05 14:37:41 UTC
From:
To:
After upgrading them, the NIS daemons (ypserv, ypxfrd, yppasswdd) all
segfault when they are started. ypbind is not affected. The sparc
platform ist affected, the same version on i386 is not.

Running "/etc/init.d/nis start" on a NIS server results in:

Starting NIS services: ypserv /etc/init.d/nis: line 98: 14020 Segmentation fault      start-stop-daemon --start --quiet --pidfile /var/run/ypserv.pid --exec ${NET}/ypserv -- ${YPSERVARGS}
yppasswdd /etc/init.d/nis: line 98: 14021 Segmentation fault start-stop-daemon --start --quiet --exec ${NET}/rpc.yppasswdd -- $YPPWDDIRARGS $E $YPPASSWDDARGS
ypxfrd /etc/init.d/nis: line 98: 14022 Segmentation fault start-stop-daemon --start --quiet --exec ${NET}/rpc.ypxfrd -- $YPXFRDARGS
ypbind [binding to YP server .......... backgrounded]

Starting /usr/sbin/ypserv manually and strace'ing the process shows that
after loading its shared libraries (libresolv.so.2 is the last one
loaded) and before accessing any data or configuration files, the ypserv
process receives a SIGSEGV not inside any system call. The excerpt looks
like this:

access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libresolv.so.2", O_RDONLY)   = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0-\224"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=62368, ...}) = 0
mmap(NULL, 136440, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x701f8000
mmap(0x70208000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x70208000
mmap(0x70218000, 5368, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x70218000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x70012000
munmap(0x7000c000, 21727)               = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

So this behaviour does not depend on a particular configuration or data set.

System and version information:

  Host is a SUN Enterprise 250.
  Architecture: sparc
  Kernel (uname -a): Linux interceptor 2.4.27-2-sparc64-smp #1 SMP Sun Apr 3 04:38:39 UTC 2005 sparc64 GNU/Linux
  Dependency package versions:
    libc6: 2.3.2.ds1-22
    libgdbm3: 1.8.3-2
    libslp1: 1.2.1-2
    netbase: 4.21
    make: 3.80-9
    portmap: 5-15
    sysvinit: 2.86.ds1-1

The NIS server ran fine with an older version (unfortunately I don't
know which one exactly) before the upgrade.

#326762#10
Date:
2005-09-11 12:35:33 UTC
From:
To:
Could you please generate a backtrace with gdb?
#326762#15
Date:
2005-09-15 10:18:45 UTC
From:
To:
I just see that I forgot to send my reply to the bug tracker also, so
for the sake of completeness, here it is:
----- Forwarded message ----- (gdb) run Starting program: /usr/sbin/ypserv Program received signal SIGSEGV, Segmentation fault. 0x00000464 in ?? () (gdb) where #0 0x00000464 in ?? () #1 0x700c4e18 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) ----- End forwarded message -----
#326762#20
Date:
2005-09-26 21:40:53 UTC
From:
To:
Hrm.  I don't think this is a NIS bug - ypserv should be linked against
far more libraries than that so ld.so hasn't finished running when the
segfault happens.

I've also got a SPARC sitting ready to install with I think all the bits
I need so I'll hopefully be able to try to reproduce this over the
weekend.

#326762#25
Date:
2005-09-30 14:42:26 UTC
From:
To:
[...]

What I sent were only the last few lines of the trace. ld.so actually
loads all the libraries ldd lists, so I assume that it is indeed
finished when the segfault happens. Sorry to have caused confusion.

The only thing I can read from the stack trace so far is that the
0x7... address is within the text segment of libc.so . I don't have a
debug libc ready, though, so I don't know which function that is.

I really hope so - I really hate running afoul of problems that nobody
else seems to have ;-)