Glynn Clements wrote:
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.]
Thanks a lot for that background information, nice metaphor.
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.
So what to do now? Is there any possibility to trace the bug or at least
to assure it isn't related to GRASS (which I assume as most people don't
have problems with g.copy)?
- I'm using gcc version 4.1.2
Thanks a lot for your support,
Volker
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
