Subject: port-sparc64/23473: kdump dumps core on sparc64/compat_svr4
To: None <gnats-bugs@gnats.netbsd.org>
From: None <dmcmahill@netbsd.org>
List: netbsd-bugs
Date: 11/17/2003 21:37:44
>Number:         23473
>Category:       port-sparc64
>Synopsis:       kdump dumps core on sparc64/compat_svr4
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 18 04:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Dan McMahill
>Release:        NetBSD 1.6ZF
>Organization:
	
>Environment:
	
	
System: NetBSD mudshark 1.6ZF NetBSD 1.6ZF (MUDSHARK) #0: Mon Nov 17 07:45:39 EST 2003 root@mudshark:/usr/cvs/src/sys/arch/sparc64/compile/MUDSHARK sparc64
Architecture: sparc64
Machine: sparc64
>Description:
I started to investigate why some solaris binaries I wanted to run weren't running
(bad syscall) so I tried to ktrace the program.  What I've found is that kdump segfaults
every time I try to look at the results.  This happens for even the simplest program
and even for programs which run just fine under compat_svr4.

	
>How-To-Repeat:

Download http://www-mtl.mit.edu/~mcmahill/netbsd/hello (the statically compiled program).
The source is:
#include <stdio.h>
int main(int argc, char **argv) {
      printf("Hello, world!\n");
      return 0;
}

The binary was built on solaris-2.6/sparc with:
  gcc -static -o hello hello.c

Now do:


ktrace ./hello
ktrace -C
kdump ktrace.out

and see a segfault.

In this example, the top part of the kdump output (before it dies) is:

   522 ktrace   EMUL  "netbsd"
   522 ktrace   RET   ktrace 0
   522 ktrace   CALL  execve(0xffffffffffffdad7,0xffffffffffffd950,0xffffffffffffd960)
   522 ktrace   NAMI  "./hello"
   522 hello    EMUL  "svr4_32"
   522 hello    RET   execve JUSTRETURN
   522 hello    CALL  ioctl(0x1,_IOWR('<D9>',0x50),0xffffffffffffd960,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0x202020353232206b,0x7472616365202020,0x45
[snip]

then lots and lots of more numbers ending with

33333333333,0x3333332c30783333,0x3333333333333333,0x3333333333332c30,0x7833323336333332,0x6333303738333333,0x332c307833333330,0x3333333733333338,0x333236332c307833,0x3333303337333833,0x333333326333302c,0x3078373833333333,0x3333333333333333,0x33332c3078333333,0x3333333333333333,0x33333333332c3078,0x3333326333303738,0x3333333333333333,0x2c30783333333633,0x3333333333333233,0x3333362c30783333,Segmentation fault (core dumped)

On some other program, like less(1) from solaris 9, I see the same thing but its on a call to open(), but again, just
a few lines after the EMUL "svr4_32" line.


	
>Fix:

no idea.
	
>Release-Note:
>Audit-Trail:
>Unformatted: