"John Redmond" <John_member@pathlink.com> wrote in message news:dqhktn$2n3g$1@digitaldaemon.com...
> 1. Rebuild with -o+speed switch. No complilation errors.
> 2. Crashes on running.
> 3. Recompile one file (it happens to be 'commenttemplate.cpp') with the
> inline
> code switch reset, then relink.
> 4. Runs fine.
>
> This suggests some suspect code in 'commenttemplate.cpp' or its header.
> Therefore:
> 5. Comment out all code in commenttemplate.h and commenttemplate.cpp.
> 6. Still crashes on running.
>
> Suggestions please.

First of all, it is very common for a bug to not appear in unoptimized code, but appear in optimized code. The most likely culprit is an uninitialized variable or uninitialized class member. Unoptimized/optimized will often produce different initial values for the variable, some of which may not affect the execution.

Next, how to find it is reasonably straightforward. Compile your whole project optimized, verify the failure. Store off all the obj files in one directory. Compile whole project unoptimized, verify it works. Save the obj files in another directory.

Now, mix and match the two sets of obj files, linking the project, until you isolate down which obj file is the trigger for the error. Doing it by halves, 220 object files will take about 8 links.

Once you have the offending obj file identified, then split the source for it in half (using #ifdef's), produce two obj files, and find out which offends. Keep going till you isolate it down to one function.

Warren:

Thanks for your reply. I had done pretty much what you suggested with the obj files, but your way was much more efficient. I am able to identify the problem obj file in this way, and there never seems to be more than a single problem file at any one time, but the puzzling thing is that the offending file keeps changing. To explain:

1. I can comment out all the code in the offending source file. The problem is still there. The code in that file is therefore (?) not the problem.

2. If I move part of the code in the cpp file to another cpp file, and add that file to the project, the problem is still there.

3. Now this is the interesting part: If I remove the original cpp file from the project and re-add it, the problem moves to another source file. I can repeat this over and over, and the problem continues to move. The files are  not particularly complex and there does not seem to be any scope for invariant errors. Please correct me, but I feel that the link order could be changing when I change the compilation order. Could linking be the cause of the problem?

John

In article <dqvl28$1qkt$1@digitaldaemon.com>, Walter Bright says...
>
>
>"John Redmond" <John_member@pathlink.com> wrote in message news:dqhktn$2n3g$1@digitaldaemon.com...
>> 1. Rebuild with -o+speed switch. No complilation errors.
>> 2. Crashes on running.
>> 3. Recompile one file (it happens to be 'commenttemplate.cpp') with the
>> inline
>> code switch reset, then relink.
>> 4. Runs fine.
>>
>> This suggests some suspect code in 'commenttemplate.cpp' or its header.
>> Therefore:
>> 5. Comment out all code in commenttemplate.h and commenttemplate.cpp.
>> 6. Still crashes on running.
>>
>> Suggestions please.
>
>First of all, it is very common for a bug to not appear in unoptimized code, but appear in optimized code. The most likely culprit is an uninitialized variable or uninitialized class member. Unoptimized/optimized will often produce different initial values for the variable, some of which may not affect the execution.
>
>Next, how to find it is reasonably straightforward. Compile your whole project optimized, verify the failure. Store off all the obj files in one directory. Compile whole project unoptimized, verify it works. Save the obj files in another directory.
>
>Now, mix and match the two sets of obj files, linking the project, until you isolate down which obj file is the trigger for the error. Doing it by halves, 220 object files will take about 8 links.
>
>Once you have the offending obj file identified, then split the source for it in half (using #ifdef's), produce two obj files, and find out which offends. Keep going till you isolate it down to one function.
>
>

"John Redmond" <John_member@pathlink.com> wrote in message news:dr1caf$fvs$1@digitaldaemon.com...
> 3. Now this is the interesting part: If I remove the original cpp file
> from the
> project and re-add it, the problem moves to another source file. I can
> repeat
> this over and over, and the problem continues to move. The files are  not
> particularly complex and there does not seem to be any scope for invariant
> errors.

Problems that appear and disappear when code is moved around have the odor of either uninitialized data or pointer bugs. I suggest trying out a malloc debugger, such as the one in ftp://ftp.digitalmars.com/ctools.zip. Other things to try are running lint on your code, or compiling it under linux.

Since this happens at startup, you need to seriously examine all of your code that runs at startup, which would be the static constructors. Also, be aware that the order in which static constructors run is *not defined*, and so if your code has any such dependencies, it'll break.

I also suggest firing up the debugger, and starting at the start address, step through your code and verify, step by step, that it is working.

> Please correct me, but I feel that the link order could be changing when I change the compilation order. Could linking be the cause of the problem?

The link order is defined by the order of the obj files in your linker command or linker response file. The compiler has nothing to do with it.

Walter Bright wrote:
> "John Redmond" <John_member@pathlink.com> wrote in message news:dr1caf$fvs$1@digitaldaemon.com...
> 
>>3. Now this is the interesting part: If I remove the original cpp file
>>from the
>>project and re-add it, the problem moves to another source file. I can
>>repeat
>>this over and over, and the problem continues to move. The files are  not
>>particularly complex and there does not seem to be any scope for invariant
>>errors.
> 
> 
> Problems that appear and disappear when code is moved around have the odor of either uninitialized data or pointer bugs. I suggest trying out a malloc debugger, such as the one in ftp://ftp.digitalmars.com/ctools.zip. Other things to try are running lint on your code, or compiling it under linux.

If you're going to compile on Lin(s)ux, FreeBSD or your favorite *nix, you might want to look into Gray Watson's dmalloc library. It does some pretty extensive malloc checking (which can be turned on and off), and has been a lifesaver over the years.


-scooter
 (who helped Gray with the library back in the early 90s.)

Thanks to all for their contributions to this problem. To summarize the history;

1. The project is a port from Linux (and gcc). There has never been a problem
with O3 or higher optimization there.
2. DM made it very easy to do the port to Windows. There are no build problems,
provided I do not attempt inlining.
3. Inlining leads to a runtime crash. No exceptions could be caught or print
statements got out. Conclusion: the problem is before main() is entered.
4. Selective recompilation of individual .cpp files without inlining narrowed
the problem down to a single source file (commenttemplate.cpp). If I compile the
whole project with inlining, then recompile commenttemplate.cpp WITHOUT inlining
and relink, the problem disappears.
5. If I remove commenttemplate.cpp from the project and then re-add it, a
different source file needs to be given the special treatment (as in 4.).
6. Non-local statics were the most likely cause, so I replaced them all with
Meyers singletons. The problem remains.
7. At present, I feel that I have to live with the kludge (as in 4.) but, in the
longer term, I just gotta find out what is happening.

John


In article <dr6k12$43c$1@digitaldaemon.com>, Scott Michel says...
>
>Walter Bright wrote:
>> "John Redmond" <John_member@pathlink.com> wrote in message news:dr1caf$fvs$1@digitaldaemon.com...
>> 
>>>3. Now this is the interesting part: If I remove the original cpp file
>>>from the
>>>project and re-add it, the problem moves to another source file. I can
>>>repeat
>>>this over and over, and the problem continues to move. The files are  not
>>>particularly complex and there does not seem to be any scope for invariant
>>>errors.
>> 
>> 
>> Problems that appear and disappear when code is moved around have the odor of either uninitialized data or pointer bugs. I suggest trying out a malloc debugger, such as the one in ftp://ftp.digitalmars.com/ctools.zip. Other things to try are running lint on your code, or compiling it under linux.
>
>If you're going to compile on Lin(s)ux, FreeBSD or your favorite *nix, you might want to look into Gray Watson's dmalloc library. It does some pretty extensive malloc checking (which can be turned on and off), and has been a lifesaver over the years.
>
>
>-scooter
> (who helped Gray with the library back in the early 90s.)

John Redmond wrote:
> 4. Selective recompilation of individual .cpp files without inlining narrowed the problem down to a single source file (commenttemplate.cpp). If I compile the whole project with inlining, then recompile commenttemplate.cpp WITHOUT inlining and relink, the problem disappears.

Ok, this is time consuming but eventually it gives Walter a test case to play with. Of course, YMMV as to when the bug gets fixed but Walter has a good track record of being responsive.

If you can, conditionally compile out the inlines ('#if 0' them out), then re-enable them one-by-one to find the offending code. If you can eventually package the offending inline along with code that references it into a small test case, send if off to Walter so he can get some clue.

Sounds like a serious enough bug that he'll fix it quickly, but then again, I don't speak for Walter.


-scooter

Scott:

You have pricked my conscience. The socially responsible thing it to identify what is going on, and not rely on any kludges. As it happens, I am about to go on a much put-off vacation to Tasmania for a month (I live in Sydney), so don't expect anything to happen very quickly.

As already said, I just gotta get to the bottom of this.

John.

In article <drdnea$1soq$1@digitaldaemon.com>, Scott Michel says...
>
>Ok, this is time consuming but eventually it gives Walter a test case to play with. Of course, YMMV as to when the bug gets fixed but Walter has a good track record of being responsive.
>
>If you can, conditionally compile out the inlines ('#if 0' them out), then re-enable them one-by-one to find the offending code. If you can eventually package the offending inline along with code that references it into a small test case, send if off to Walter so he can get some clue.
>
>Sounds like a serious enough bug that he'll fix it quickly, but then again, I don't speak for Walter.
>
>
>-scooter

Actually... what you are running into might be a more or less classic case of initialisation/construction of static data/classes.
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

By what you are doing you are reordering files for the link and thus for position in memory and static (pre main()) construction initialization than thus you might be moving the problem around.

HTH

Thanks!
Jan



John Redmond wrote:
> Thanks to all for their contributions to this problem. To summarize the history;
> 
> 1. The project is a port from Linux (and gcc). There has never been a problem
> with O3 or higher optimization there.
> 2. DM made it very easy to do the port to Windows. There are no build problems,
> provided I do not attempt inlining.
> 3. Inlining leads to a runtime crash. No exceptions could be caught or print
> statements got out. Conclusion: the problem is before main() is entered.
> 4. Selective recompilation of individual .cpp files without inlining narrowed
> the problem down to a single source file (commenttemplate.cpp). If I compile the
> whole project with inlining, then recompile commenttemplate.cpp WITHOUT inlining
> and relink, the problem disappears.
> 5. If I remove commenttemplate.cpp from the project and then re-add it, a
> different source file needs to be given the special treatment (as in 4.).
> 6. Non-local statics were the most likely cause, so I replaced them all with
> Meyers singletons. The problem remains.
> 7. At present, I feel that I have to live with the kludge (as in 4.) but, in the
> longer term, I just gotta find out what is happening.
> 
> John
> 
> 
> In article <dr6k12$43c$1@digitaldaemon.com>, Scott Michel says...
> 
>>Walter Bright wrote:
>>
>>>"John Redmond" <John_member@pathlink.com> wrote in message news:dr1caf$fvs$1@digitaldaemon.com...
>>>
>>>
>>>>3. Now this is the interesting part: If I remove the original cpp file 
>>>
>>>>from the
>>>
>>>>project and re-add it, the problem moves to another source file. I can repeat
>>>>this over and over, and the problem continues to move. The files are  not
>>>>particularly complex and there does not seem to be any scope for invariant
>>>>errors.
>>>
>>>
>>>Problems that appear and disappear when code is moved around have the odor of either uninitialized data or pointer bugs. I suggest trying out a malloc debugger, such as the one in ftp://ftp.digitalmars.com/ctools.zip. Other things to try are running lint on your code, or compiling it under linux.
>>
>>If you're going to compile on Lin(s)ux, FreeBSD or your favorite *nix,
>>you might want to look into Gray Watson's dmalloc library. It does some
>>pretty extensive malloc checking (which can be turned on and off), and
>>has been a lifesaver over the years.
>>
>>
>>-scooter
>>(who helped Gray with the library back in the early 90s.)
> 
> 
> 

-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org