I'm having two problems running Netscape under NetBSD/SPARC 1.0.

The first problem is trivial; I'm finding that a lot of the time, clicking
on something in Netscape that causes a helper app to be spawned off causes
Netscape to hang.  It's as if it never sees that the helper app finished
its job or something.  Anyone else ever see this?  Interestingly, the SunOS
Mosaic 2.6 binary doesn't seem to have this problem.  No idea why.

The other one is more involved.

The new 2.0beta1 4.1.3_U1 netscape_dns binary has Java applet support.  The
released binaries have a problem (under SunOS) in that it tries to do a

	mmap(0x40000000, 0x100000, READ|WRITE|EXEC, PRIVATE|FIXED, 17, 0)

In comp.lang.java, Casper Dik pointed out that this is an unportable
construct; i.e. one can't depend on using MAP_FIXED at a particular address
across all architectures.

I developed an adb patch that changes the above mmap() call to just use
MAP_PRIVATE instead of MAP_PRIVATE|MAP_FIXED.  This works like a charm, and
now on SunOS I have Java applets working with the binary this way.  The
mmap() may ask for 0x40000000, but it gets back something different because
it's not FIXED anymore.  And things work.

So I copied this newly-patched binary over to my desktop NetBSD/SPARC 1.0 box,
hoping maybe I'd get lucky.  Well, I tried to run a Java applet and it crashed
in exactly the same way as the unpatched binary.  I ran it under "ktrace"
and this revealed:

  5692 netscape-2.0beta1        CALL  open(0x37d280,0x2,0x7)
  5692 netscape-2.0beta1        NAMI  "/dev/zero"
  5692 netscape-2.0beta1        RET   open 20/0x14
  5692 netscape-2.0beta1        CALL  old.mmap(0x40000000,0x100000,0x7,\
0x80000002,0x14,0)
  5692 netscape-2.0beta1        RET   old.mmap 1073741824/0x40000000
  5692 netscape-2.0beta1        PSIG  SIGBUS SIG_DFL
  5692 netscape-2.0beta1        NAMI  "netscape-2.0beta.core"

I went poking through /usr/src/sys/vm/vm_mmap.c and noticed that ommap()
(now compat_43_mmap()) only sets MAP_FIXED before calling mmap() if, indeed,
the OMAP_FIXED flag is set.  Given that it isn't (0x80000002 effectively ==
0x2, here?), I'm surprised that (the 1.0) internal mmap() is returning
the same formerly-desired-to-be-fixed address.  (Of course, I realize it *is*
a "hint", and maybe NetBSD is friendlier about taking a hint  (-: )

Is there any chance - given that I see changes in the -current mmap() to do
page boundary alignment - that I'm actually running into that instead?
On the other hand, the above kdump shows that it returned the hint/requested
0x40000000 - and that looks about as page-aligned as you can get  :-)

But if I whack the Netscape binary further to provide a 0 in place of the
0x40000000 at mmap() call time, it works (!!!).  Go figure ...

(I'm on a SPARCstation 2 with a Weitek PowerUp chip now, if that matters.)

	- Greg

P.S. A tar file with the working ("working" == i.e. Java applets work)
     binary is available from:

	ftp://elroy.jpl.nasa.gov/pub/netscape-2.0beta1.netbsd_sparc.tar

     No guarantees about whether it runs under -current, though  :-)