The messge below is one that I sent to JT nearly a year ago. I
never did track this down; I just changed a couple of things in
cpio and never got back to it.

However, I think this or something similar has come back to bite
me again in 1.2. On one of the two i386 machines running 1.2 that
I have here, execl seems to be loosing arguments on the second or
third time around. It eventually does execute /usr/bin/rsh, but
I get only argv[0], "rsh", and system (and perhaps login) are not
set. The other i386 machine works fine, and this also works fine
on my one i386 running current.

I've never seen this on anything but the i386 port, but given that
some machines seem to do it and some don't, this might be happening
on other ports, too.

Has anyone seen anything like this happen? This looks as if it's going
to be nasty to track down....

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.

---------- Forwarded message ----------
Date: Mon, 4 Dec 1995 21:27:23 -0800 (PST)
From: Curt Sampson <curt@portal.ca>
To: jtc@netbsd.org
Subject: Bug in i386 execl

J.T.,

I don't know if you're the right person to talk to about this, but
I thought I'd try this out with you before I post to the lists and
look like a moron.

I seem to have tracked down a bug somewhere in the 1.1/i386 execl
system call. It started when I tried to archive some files on a
1.1 system to a 1.0 system using cpio's rmt facilities. The 1.1
system never actually contacts the 1.0 system: cpio just says
"Input/Output Error".  Here's a command that fails:

    cpio -itv -H crc -C 65536 -F userid@somehost:/dev/rst0

It turns out that what's failing is cpio's attempt in rtapelib.c
to have a child exec a copy of rsh. The code, starting at line 375
looks like this:

          execl ("/usr/ucb/rsh", "rsh", system, "-l", login,
                 "/etc/rmt", (char *) 0);
          execl ("/usr/bin/remsh", "remsh", system, "-l", login,
                 "/etc/rmt", (char *) 0);
          execl ("/usr/bin/rsh", "rsh", system, "-l", login,
                 "/etc/rmt", (char *) 0);
          execl ("/usr/bsd/rsh", "rsh", system, "-l", login,
                 "/etc/rmt", (char *) 0);
          execl ("/usr/bin/nsh", "nsh", system, "-l", login,
                 "/etc/rmt", (char *) 0);

The third execl is normally the one that is successful, and this
works fine on NetBSD 1.0/i386. However, under NetBSD 1.1/i386 the
first execl returns and sets errno to 2 (ENOENT, no such file or
directory), but the second one never returns. Instead, the child
process of cpio core dumps with a segmentation fault. Here's a
backtrace of that dump:

#0  0x100434b8 in fnmatch ()
#1  0x10043500 in execl ()
#2  0x942c in __rmt_open (path=0xf7bfd7b4 "tape", oflag=0, mode=438, bias=128)
    at rtapelib.c:377
#3  0x7fb3 in open_archive (file=0xf7bfda7b "tape@kefron:/dev/rst0")
    at util.c:721
#4  0x68c2 in process_args (argc=8, argv=0xf7bfda00) at main.c:404
#5  0x69da in main (argc=8, argv=0xf7bfda00) at main.c:469

Unfortunately, here I'm a bit stuck, since execl() in
/usr/src/lib/libc/gen/exec.c. doesn't call fnmatch. I must be
missing something somewhere. Can you clue me in so I can try to
track this down further? I'd like to get a bit more information on
this if I can before submitting a bug report.

Any idea whether or not this fails on systems other than the i386?

Also, if you've got some general clues for a newbie on debugging
library routines and system calls, I'd like to hear them. My current
thought for debugging something like this would be to compile a
copy of fnmatch with debugging information and link it in with the
program, overriding the copy in the shared library. Will this work?
Is it sensible?

cjs

Curt Sampson    curt@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.