Solaris 8 X11 binaries generate segmentation violations on NetBSD

Question

All,

Recently, I've been trying to get the Solaris 8 versions of xterm and xauth working on NetBSD from an ssh client with X11 forwarding, but both binaries seem to generate segmentation violations immediately. I ran a ktrace on both programs to try to figure out what happened, and the last few lines of output for both programs look like this:

...
   571      1 xclock   compat_20_getfsstat(0xedefa018, 0xefffede4) Err#2 ENOENT
   571      1 xclock   compat_50_getrusage(0xedefa000, 0x1000) = 0
   571      1 xclock   #115 (obsolete vtrace)(0, 0x1000, 0x7, 0x80000102, 0xffffffff, 0) = -303063040
   571      1 xclock   compat_50_getrusage(0xedee4000, 0x1000) = 0
   571      1 xclock   break(0x25850)              = 0
   571      1 xclock   break(0x27850)              = 0
   571      1 xclock   break(0x27850)              = 0
   571      1 xclock   break(0x29850)              = 0
   571      1 xclock   break(0x29850)              = 0
   571      1 xclock   break(0x2b850)              = 0
   571      1 xclock   compat_43_otruncate(0x5, 0xeffff3a0) = 0
   571      1 xclock   shmdt(0x2, 0x2, 0)          = 3
   571      1 xclock   modctl(0x3, 0x6, 0x1, 0xeffff39c, 0x4) = 0
   571      1 xclock   modctl(0x3, 0xffff, 0x8, 0xeffff398, 0x4) = 0
   571      1 xclock   break(0x2b850)              = 0
   571      1 xclock   break(0x2d850)              = 0
   571      1 xclock   open("/emul/svr4/etc/netconfig", 0, 0x1b6) = 4
   571      1 xclock   #217 (unimplemented)(0x4, 0xefffebb0) = 0
   571      1 xclock   ioctl(0x4, _IO('T',0x1,0), 0xefffeb3c) Err#-4
   571      1 xclock   read(0x4, 0x2b9a4, 0x400)   = 1024
       "#pragma ident\t"@(#)netconfig\t1.16\t99/10/25 SMI"\n#\n# The "Network Configuration" File.\n#\n# Each entry is of the form:\n#\n#       <network_id> <semantics> <fl"
   571      1 xclock   SIGSEGV SIG_DFL

I noticed that the ioctl call is failing; could this be a reason for failure here?

I also ran ktrace on the NetBSD versions of xclock and xterm to see if there were any similarities, and the most similar samples of output I could find were the following:

...
   604      1 xclock   __stat50("/etc/nsswitch.conf", 0xefffeed8) = 0
   604      1 xclock   open("/etc/nsswitch.conf", 0x400000, 0x1b6) = 3
   604      1 xclock   __fstat50(0x3, 0xefffeb70)  = 0
   604      1 xclock   read(0x3, 0xed61d000, 0x4000) = 621
       "#\t$NetBSD: nsswitch.conf,v 1.6 2009/10/25 00:17:06 tsarna Exp $\n#\n# nsswitch.conf(5) -\n#\tname service switch configuration file\n#\n\n\n# These are the default"
   604      1 xclock   read(0x3, 0xed61d000, 0x4000) = 0
...
   604      1 xclock   open("/etc/hosts", 0x400000, 0x1b6) = 3
   604      1 xclock   __fstat50(0x3, 0xefffcc38)  = 0
   604      1 xclock   read(0x3, 0xed61d000, 0x4000) = 831
       "#\t$NetBSD: hosts,v 1.9 2013/11/24 07:20:01 dholland Exp $\n#\n# Host name database.\n#\n# This file contains addresses and aliases for local hosts whose names\n# n"
   604      1 xclock   read(0x3, 0xed61d000, 0x4000) = 0
       ""
   604      1 xclock   close(0x3)                  = 0

Because of this, I suspect the reason might lie in some of the Solaris 8 files that I copied over to the NetBSD virtual machine (e.g. /etc/netconfig), but I'm unsure. Could these files be the reason why none of the Solaris 8 X11 binaries function correctly on NetBSD?

Answer 1

The failing ioctl() is probably irrelevant given that the file it is attempted on (FD#4) is eventually read from successfully.

There is also a call to an unimplemented system call, also on FD#4, just above that which would appear to be fstat64(), probably to find the size of the file. Again this may be irrelevant as the file appears to have been read successfully.

Both of these calls are likely being made in the Solaris libc, via the STDIO functions, via setnetconfig(), also in libc.

So assuming the file you put in /emul/svr4/etc/netconfig on the NetBSD test host is unchanged from a valid working Solaris 8 copy of /etc/netconfig, I would further doubt that anything seen in the ktrace output gives any real clue as to the problem.

The next step might be to try some much simpler programs, e.g. cat or /bin/echo, and even /bin/true and /bin/false, to see if they run successfully.

The real answer will likely only come if an unstripped version of the code, built from source on Solaris, can be run under a source-level debugger under emulation on NetBSD, to see exactly where it is crashing.