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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
