Subject: Re: Netscape 2.0 beta 2 binary crashing with SIGILL?
To: None <davem@caip.rutgers.edu>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
List: port-sparc
Date: 11/09/1995 19:01:34
>      1108 netscape-2.0beta^->o0!W[ CALL  obs_4.2(0x45d158)
>      1108 netscape-2.0beta^->o0!W[ PSIG  SIGALRM caught handler=0x4400c28 mask=0
> x0 code=0x0
> 
> Looks like a call to sleep(xxx); in SunOS libc... I could be wrong...
> 
>      1108 netscape-2.0beta^->o0!W[ NAMI  "netscape-2.0beta.core"
> 
> Appears as if it dies before returning from the sigalarm handler in
> user space.  I would bet any amount of money the sigill happened
> within the userland signal trampoline code.  With the output of:
> 
> bash$ adb /path/to/netscape/bin/netscape ./core
> $c
> 0xXXXXXXXX,20?ai

The SunOS system doesn't recognize the core as being a valid core.  Not
surprising, but then what exactly is a core file produced from a SunOS
binary under NetBSD?  NetBSD doesn't recognize it as one, either.

netbsd4me:1:89 % ls -ls netscape-2.0beta.core
 864 -rw-r--r--  1 earle  wheel  872960 Nov  9 17:41 netscape-2.0beta.core
netbsd4me:1:90 % cksum -o 1 netscape-2.0beta.core
4522 853 netscape-2.0beta.core
netbsd4me:1:91 % file netscape-2.0beta.core
netscape-2.0beta.core: data

Meanwhile:

elroy:1:24 [/tmp] % uname -a
SunOS elroy 4.1.4 2 sun4m
elroy:1:25 [/tmp] % sum netscape-2.0beta.core
04522   853

Checksums match OK ...

elroy:1:26 [/tmp] % mv netscape-2.0beta.core core
elroy:1:27 [/tmp] % file core
core:           data
elroy:1:28 [/tmp] % adb /usr/local/bin/netscape-2.0beta2
not core file = core

One further note: If I move /sun/lib/libc.so.1.9 (yes, still running 1.0)
out of the way and use libc.so.1.8 instead, it still croaks the same way:

netbsd4me:1:99 % netscape-2.0beta2
ld.so: warning: /sun/lib/libc.so.1.8 has older revision than expected 9
face black-i
face black-r
Illegal instruction

Still curious to know if anyone on 1.1-Alpha can run this binary successfully.

(And still curious to know how one can debug this problem.  Surely when the
 SunOS emulation code was being done, there were SunOS binaries that tossed
 their cookies under NetBSD.  Somehow someone had to determine what was dying
 and why ... )

	- Greg