[GRASS-dev] [grass-code I][431] g.copy segmentation fault

[Glynn Clements]

Volker Wichmann wrote:

> > The code was compiled with optimisation enabled (the default CFLAGS
> > are '-g -O2'), so the object code doesn't directly correspond to the
> > source code.
> >
> > It might help if you re-compile the general/manage directory without
> > optimisation, e.g.:
> >
> > 	make -C general/manage clean
> > 	make -C general/manage CFLAGS1='-g'
> >
> > That will certainly make it easier to debug; OTOH, it might simply
> > make the bug disappear.
> 
> Crazy, that did the trick - no segmentation fault anymore!
> Thanks a lot Glynn!!

That isn't necessarily a good thing; it may just be fixing the symptom
rather than the problem. It's quite possible that the bug is still
there, but we can't find it.

[A bug which "disappears" when you start looking for it (e.g. by
compiling with options suitable for debugging) is sometimes referred
to as a "Heisenbug", in reference to the quantum physics concept that
a system can be changed by simply observing it.]

> As I know of several people that they have the same problem, I would 
> like to keep this solution for the record. Glynn, would you be so kind 
> to give me some more background why this can happen? Does this 'feature' 
> relate to specific CPUs, operating systems etc. ?

Segmentation faults often depend upon exactly how variables are
arranged in memory. Disabling optimisation may change the layout
(typically making it less dense; optimisation tends to reduce the
number of variables which are actually stored in memory).

OTOH, it's possible that the problem is due to a bug in the compiler's
optimisation code. An optimising compiler is *much* more complex than
a "dumb" compiler; if you check the change logs for a compiler, you
normally find that the vast majority of bug fixes apply to bugs which
only occur when optimisation is enabled.

-- 
Glynn Clements <glynn at gclements.plus.com>