[Gllug] SIGSEGV error

[Nix]

On 29 Aug 2007, t. clarke stated:

> Just a passing thought;
>
> you said it compiled OK on ubuntu

If the Ubuntu system was different hardware, this strongly supports the
bad RAM hypothesis.

> There is a little 'gotcha' in the Gnu C compiler  (if it is invoked directly
> or indirectly) involving static strings in programs.
>
> If a program attempts to modify a declared static string the program will fall
> over with a segment violation, as the static string is linked into the 'text'
> scetion of the porgram as opposed to the 'writable' variable portion of the
> program.

You're being too ambiguous to be useful, I'm afraid.

A char array intialized by a string constant, static or no, is modifiable, viz:

static char foo[] = "bar";

(although be careful not to run off the end of it).

A pointer to a string constant, e.g.:

static char *foo = "bar";

may be stored in constant storage, shared with other declarations, or
stored in any other way the implementation desires: modifying it invokes
undefined behaviour. It's not a `gotcha in the Gnu C compiler', it's the
way the language works.

>           If this is the cause of the fault,  compiling with -fwritable-strings
> will cause the compiler to locate the stgatic strings in 'writable' memory,

FWIW, this option hsa been removed in GCC 4.2.


The fact that it died only after some time implies to me either that
there is a somewhat rare intermittent bug, or a bug that triggers when
the simulation reaches a particular state, or, indeed, bad RAM. Some
types of RAM problem can lead to data being fine for a while after it's
written, but then getting mangled. If this happens to a pointer, and
then you chase that pointer, *boom*.


If it's not hardware, there's nothing you can do without the source code
(only wizards bother to try to track this sort of problem down in
compiled binaries these days).
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug