> That should at least tell if the syscall code matches getpid(2) or chown(2),
> i.e. if the syscall number is passed correctly to kernel or not.

Here is what I get (I wrote the corresponding Linux syscall next to the
code). Netscape (or at last glibc) really calls chown with setgid's
arguments.

syscall: code=45        brk
syscall: code=45        brk
syscall: code=45        brk
syscall: code=47        getgid
syscall: code=181       chown   <<< should be setgid (46)
syscall: code=24        getuid
syscall: code=23        setuid
syscall: code=42        pipe
syscall: code=42        pipe
syscall: code=2         fork

I digged a bit deeper, and there are other problems like this one later
in the kernel trace
mprotect turns into sethostname (we really don't expect Netscape to it)
gettimeofday turns into sysinfo (what's this system call anyway? I don't
have a man page on it)

Then Netscape gets a SIGSEGV, but it is a normal consequence: sysinfo
must return a struct longer than the one used by gettimeofday, it
overwrite some data on the stack, and when Netscape try to access them,
it gets a SIGSEGV.

An idea: Linux RT signals are likely to be broken for now. I have not
been able to find some documentation about rt_sigaction and friends,
therefore I did not make any test program on it yet. In the source, I
labeled linux_sys_rt_sigreturn as "XXX not tested". Netscape makes an
intensive use of RT signals.

I wonder if stack corruption in linux_sys_rt_sigreturn could not lead to
these strange problems?

-- 
Emmanuel Dreyfus.  
Hiroshima 45. Tchernobyl 86. Windows 95. 
p99dreyf@criens.u-psud.fr