Re: Segmentation fault

From: Gerald Richter (
Date: 09/14/01

George Greer wrote:
> On Fri, 14 Sep 2001, Gerald Richter wrote:
> >George Greer wrote:
> >> That is a typical symptom of random memory corruption.  The
> >> differing compiler and/or library can cause subtle changes in
> >> what gets trashed.  It could also just be the compiler
> >> miscompiling your code but that's not likely unless you're
> >> pushing its capabilities.
> >
> >Heh. As I said, it's a redhat quirk.
> I meant YOUR code is likely broken.  The different code alignment
> between the compilers (due to optimization differences not
> brokenness) would make your code overwrite your own memory in your
> own random places for each. When the compiler takes liberties with
> C code that it is allowed to, that's not its fault.

My code? Not possible as I hadn't made changes to the compile I am
talking about, however the gentleman that started this thread may have
forgotten a change as one of the other contributors to this thread
mentioned. My equipment? Wouldn't surprise me. As i've said, I got this
with stock bpl17 fresh outta the tarball on rh7. However, it seems the
problems that caused it way back when I first compiled on RH7 have gone
away because I just tried it again while writing this and stock is
working fine on my RH7 server with all the update patchs RH has
released... Now the detail of if my cranky old server is just having a
better day today has yet to be determined.

> Most of what is RH7's gcc-2.96 became gcc-3. Not that I've checked
> CircleMUD for -fstrict-aliasing compliance...but that's on by
> default in gcc3 not gcc2.96.

Okie, that's great. Not really relevant to the discussion. And not worth
wasting the general membership of this lists time with, as I am sure
most of us are already aware of that.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST