Can anyone explain this one?  The program's called backend, it acts
as a remote backup/restore procedure, mostly to provide setuid
behaviour kind of safely and to interface to cpio.  It could have
been a shell script, but I wanted a bit of a tighter control, so
I wrote it in 'C'.

Of note, it is installed in /usr/local/bin, which is mounted read only
from another host, of almost identical vintage.  The following may be
self explanatory:

$ su root -c 'exec su admin'
Password:
$ backend
Segmentation fault
$ gdb /usr/local/bin/backend
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386--netbsd"...
(gdb) run
Starting program: /usr/local/bin/backend
usage: backend [-h] [-d <dir>]... [-i <id>] [-R] [-v] <destination>

Program exited with code 02.
(gdb) quit
$ backend
usage: backend [-h] [-d <dir>]... [-i <id>] [-R] [-v] <destination>
$ uname -a
NetBSD grin 1.4.2 NetBSD 1.4.2 (GRIN) #2: Sun Sep 24 12:11:29 SAST 2000     lucio@giggle:/export/src/NetBSD-1.4.2/sys/arch/i386/compile/GRIN i386
$

After this, backend behaves acceptably evermore (nearly).

On the NFS server host, I have never seen the segmentation error.  I
was hoping for some freakiness I would not have to deal with, but I
rebooted the NFS client host and the problem resurfaced.  I presume it
will now stay away until I reboot next :-(

What it is that GDB does to fix the problem, I can't imagine, even
remotely.  Something that merely executing the program as root, myself
or "admin" (a role account for backup purposes) certainly does not.

I would dearly like some help on this score, I can't feel exactly
comfortable knowing that my backup procedures are at the mercy of some
gremlin that only GDB seems to be able to exorcise.

++L