Odd g++ compiling

[Ingo Krabbe]

Am Donnerstag, 26. Juli 2007 08:36 schrieb Daniel Lohmann:
> benjamin schrieb:
> > I have encountered a strange performance while compiling. The problem
> > is; when I change some <PARAMETER> in my <PROGRAM> and recompile it via:
> >
> >  g++ <PROGRAM> -o <OUTPUT>
> >
> > and run it:
> >
> >  ./<OUTPUT>
> >
> > I get the <Segmentation fault> error massage. OK, but when I recompile
> > it once again without changing anything:
> >
> >  g++ <PROGRAM> -o <OUTPUT>
> >
> > and run it:
> >
> >  ./<OUTPUT>
> >
> > , the program seems working perfectly well. This is the case only if
> > program is exactly <PROGRAM>, I did not noticed such a behaviour
> > before.
>
> Hi Benjamin,
>
> 1) Did you compare the output of the two g++ runs? Are there, besides time
> stamps, any differences?
>
> 2) Did you try to compile and run on a different machine?
>
> I am asking all this, as in my experience such "mystical" run-time
> behaviour (that seems to depend on moon phase, tide, number of executions
> and so on) is a strong indication for a transient error (hardware problem).
> So I'd suggest to check this first, testing on a different machine is a
> simple way to get some evidence.


I want to extend these experiences by the fact, that in 99% of mystical error 
cases there actually is no hardware problem but a user problem in myself, 
since I was affected by moon phase, tide, weather, too much or too less 
coffee or a wrong combination of other drugs I took that day or the day 
before, including the surrounding air, daily meals and the psycho-social 
states of my wife.

After taking into account all those environmental parameters, or better, after 
freeing myself of all those environmental parameters, getting back all the 
concentration on the <PARAMETERS> of my <PROGRAM> I got a working 
<EXECUTABLE>, free of any transcendental errors or effects (99%).

Please note that it is not always usefull to understand what happendend during 
the phase of defectiveness, once the world and the <PROGRAM> is in 
deterministic state again.

Often the best way to repair a <PROGRAM> is to take a 15 minute walk, 
breathing some fresh air (99%), thinking about something that has nothing to 
do with all those <PARAMETERS>.

bye ingo

>
> Daniel