Re: large binary immediately SEGV's redux!
From: Kurt (kurt_at_noemail.com)
Date: Sat, 28 Feb 2004 20:59:59 +1100
"Jeff" <firstname.lastname@example.org> wrote in message
> I'm starting a new thread. Catch up on what's happened so far here:
> So I now have a very small test case that you can try at home
> Compile and run the following program:
> #include <stdio.h>
> #define BIG 100362657 // crashes
> // #define BIG 100362656 // works
> char big[BIG];
> main(int argc,char* argv)
> int i;
> for(i=0; i<BIG; i++) big[i] = 0;
> return 0;
> This will SEGV before it gets to main() on our RH7.2 machines with
> 2.4.7-10 machines with the BigMem patch. Stock gcc. No NFS. Nothing
Nothing like patching the redhat system with patches released by Redhat ?
I bet not.
Redhat use their own *special* version of GCC, in fact they used a
not-tested snapshot and very alpha patches , and did minimal testing before
releasing it into the wild.
And so you should get the updates for redhat ...
> Now comment out the line that says "crashes" and uncomment the line
> that says "works." Recompile and re-run. Now program runs fine for us.
> We can also take the "crashes" a.out and run it on a newer kernel and
> it also works fine. But the newer kernel also doesn't have the BigMem
> 1) Is this a known bug in the kernel that's been fixed?
> 2) Is this crash caused by the BigMem patch?
> 3) What's the earliest version of the kernel where this has been
> 4) Can we do anything to 2.4.7-10 make it work?
> Any insight that people could be provide would be great.
I think it was a bug to do with the odd size of the array.
I recall such a bug with gcc from redhat.
Simple solution, install the patched gcc, or the other version that came
with redhat 7.2
Use gcc3 instead of gcc
Or grab gcc binaries from www.gnu.org or something.