Segfault at src/lib/misc.c:1193 in 3.0.4 (3.0.11 looks very similar)

[riki]

---- Mike Ely wrote ----

> On 10/03/2016 01:23 PM, Rasto Rickardt wrote:
> > I wanted to ask almost the same. What are compiler options?
> >
> > Possibly this:
> >
> > https://github.com/rust-lang/rust/issues/2078
> >
> > r.
> >
> >
> > On 10/03/2016 10:21 PM, Alan DeKok wrote:
> >> On Oct 3, 2016, at 4:15 PM, Mike Ely <me at mikeely.org> wrote:
> >>>
> >>> Maybe an arch problem? We get the same problem on both hosts (a/b configuration) so it's unlikely they both have failed sticks of RAM.
> >>>
> >>> They are running with Atom D525 processors. Here's /proc/cpuinfo (2 sockets, total 4 cores):
> >>
> >>   They're x86 machines.  Which means they should work.
> >>
> >>   Maybe it's a compiler bug...
> 
> Not (from a glance anyhow) the same problem as the rust-lang people were 
> seeing, but from another thread it's possible it needs built with 
> -mcpu=atom. Here are the options for the segfaulting version:
> 
> # rpm -q --queryformat="%{NAME}: %{OPTFLAGS}\n" freeradius
> freeradius: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic
> 
> This looks interesting (linked from Rasto's thread):
> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/112078
> 
> Thoughts?

I guess that Atom is missing something, L2/L3 cache or some instructions, so the generic  option might not be the right one, as it changes with every gcc release. -mtune native or atom you suggested might help.

I might even go to core2 as it was the first architecture with 64bit features.

r.