[GRASS-dev] [grass-code I][431] g.copy segmentation fault
Volker Wichmann
wichmann at laserdata.at
Fri Jul 27 02:18:21 EDT 2007
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
More information about the grass-dev
mailing list