On Tue, 19 Nov 1996, Wolfgang Solfrank wrote:

> The first thing to consider in tracing the bug is looking at the instruction
> the processor was about to execute (most likely the jmp to cerror immediately
> preceding the _execve label).  Assuming that this has indeed the correct
> instruction (which it at least had at the return from the first call to execl),
> I don't have a good idea off hand why this would result in a segmentation
> violation :-(.  And I'm not sure whether this is related to the new bug you
> are seeing where there are some arguments missing in the new process.

> PS: One thing however that comes to mind with regard to i386 machines: Are
> you sure your memory is OK?
> --
> ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800
> 

Thanks for your reply, Wolfgang. It's made how this stuff works a
whole lot clearer for me. I spent ages looking for an 'execv.c' file. :-)

It's not likely the memory, since I just figured out how to reprooduce
on that other 1.2 machine: I removed the symlink /usr/ucb/rsh (which
pointed to ssh). Cpio does about four execvl() calls in a row, and
/usr/ucb/rsh is the first program that it tries. When the first
execvl() works, everything's fine. If it doesn't work, it blows up
trying to do the second and third. This is reproducable on both of
my i386/1.2 systems and my i386/1.1 system as well. I suspect that
this was in 1.0 as well, because why else would I have put /usr/ucb/rsh
on that 1.2 system back when it was a 1.0 system? However, I cannot
reproduce this on my i386/current machine.

So this could be a bug in the execvl() library routine, in the
execv() syscall, or in the dynamic linking. Hmm.

Fortunately I've a Sparc and an i386 at home both running 1.2 at this
time, so if I can replicate it on the i386 at home, I'll see if the
Sparc has the same problem.

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.