Subject: Re: port-sparc/14180: random segfault on IPC with -current
To: None <port-sparc@netbsd.org>
From: Volker Borchert <bt@insiders-fs.com>
List: port-sparc
Date: 10/08/2001 13:05:30
In message <20011007193021.A2576@nitric.net> you write:

|> > Does anyone else see these random coredumps?
|> > 
|> > My SS1+ has been annoyed by this problem since I updated the kernel
|> > from 1.5_ALPHA to 1.5K (or 1.5L). 1.5-release kernel had no problem.
|> > I tried to track this problem for long time, but got no clue..
|> > 
|> > There were some reports that IPX and SS1 had the same problem.
|> > (sun4c only problem?)
|> 
|> Yes, I'm seeing them too. Also on a sun4c (claims to be a SS1)
|> It has 16 megs of ram, it seemed fine with 1.5.1.

I have seen no cc1 or other unclear segfaults on one 4/75 (64 MB) and
two 4/60 (16 MB each) so far with both 1.5 and 1.5.1 releases. I have
not been using these really heavily though, especially not "make -j 2",
since their main purpose is to be a testbed for GNU util betas whose
autoconf/automake stuff is not concurrency proof.

|> cc: Internal compiler error: program cc1 got fatal signal 11

Maybe totally unrelated, but...

I'm seeing cc1 segfault trying to compile textutils-2.0.16/src/sort.c
on a 3/80 (sun3x) with 16 MB real + 33 MB swap running 1.4.2 using a
homebuilt gcc-2.95.2 -O2. top says there is no memory shortage. With
-O only it does not segfault.

The difference to your observations is that this one seems to be
reproducible.

But I think it could be worthwhile to try a different compiler version
and/or less optimization to rule out compiler bugs.

	Volker Borchert