For quite a while I have been using Mozilla compiled natively from 
pkgsrc, with a native build of Java 1.3.1, and I have been rather 
satisfied. This is on a ThinkPad which I bought in january 2005 and 
which originally ran NetBSD 2.0.x. However, when I switched to NetBSD 3 
about a year ago and installed the mplayer plugin and Java plugin (again 
a native Java 1.4 I compiled from sources) I started getting weird 
situations (not necessarily related to these plugins) where the browser 
would try to connect to a webserver and just lock up - windows no longer 
refreshed, and all you could do was kill it. Entering the same page that 
locked it then usually always worked the next time. I lived OK with that 
for a year, but now I have upgraded again. I now run
able:~ $ uname -a
NetBSD able.toft-hp.dk 4.99.4 NetBSD 4.99.4 (GENERIC) #0: Fri Nov 24 
11:47:02 UTC 2006  
builds@b3.netbsd.org:/home/builds/ab/HEAD/i386/200611240000Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC 
i386

and have compiled seamonkey-1.0.6 (and mplayer-plugin-seamonkey-2.70) 
for this from pkgsrc-current (around Nov 30). Java plugin isn't 
installed yet. Now, instead of occasional lock-ups, it crashes and dies 
promptly with a segfault. And the frequency with which this happens, 
seems to be just slightly greater than the lockups I had become used to. 
This is of course going in the wrong direction.

I wonder whether there are other NetBSD users who use native seamonkey 
on their machine, and who recognize this behaviour? A look in GDB (I'm 
not really a debugging kind of guy, typing bt is about my limit) shows this:

Core was generated by `seamonkey-bin'.
Program terminated with signal 11, Segmentation fault.
#0  0xbb1beeff in kill () from /usr/lib/libc.so.12
(gdb) bt
#0  0xbb1beeff in kill () from /usr/lib/libc.so.12
#1  0xbb1e304c in raise () from /usr/lib/libc.so.12
#2  0xb7a34e6f in nsProfileLock::FatalSignalHandler () from 
/usr/pkg/lib/seamonkey/components/libprofile.so
#3  0xbb281d3b in pthread_sigmask () from /usr/lib/libpthread.so.0
#4  0xbb1e0788 in swapcontext () from /usr/lib/libc.so.12
(gdb) q

I consider various options for dealing with this situation:
- revert to Mozilla 1.7.3 to get back the slightly less frequent 
freezing behaviour. :-)
- wait and see, hope with time and new, improved (hmm?) versions of 
everything, it stabilizes
- switch to a different native browser (but I prefer Java and movies, so 
only likely candidates are Firefox and perhaps Galeon, and Firefox seems 
to have the same problem with crashes, I'm afraid. Don't know about Galeon.)
- switch to Linux-binary emulated version. (But how well does that 
perform? Last time I used Linux-emul I was annoyed by it because I would 
always somehow end up in the /emul directory when saving etc.)
- install Xen and a Linux VM, running Linux Seamonkey in a separate VM. 
(But how well will that perform, and how often does Seamonkey crash on 
Linux?)

So to summarize, I'm fishing for advice on which option I should take 
(or other options I have missed), and opinions and experiences from 
other users using a setup more or less similar to mine. A solution that 
would work right out of pkgsrc (-wip?) is of course preferable.

(I really just wish I could have Seamonkey run each browser window as a 
separate process, then a crash wouldn't take out everything else I was 
doing at the time. An idea for a new browser, perhaps?)

-Lasse