Digital Mars - c++ - Optimization Error

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

I am porting an XML/XSLT package from Linux and, thanks to Digital Mars, this
has been a remarkably straightforward matter. In fact, the only parts of the
source that needed changing were to do with character handling.

I can now compile from the same source with Digital Mars on XP and gcc (using
KDevelop) on Linux, using very few conditional complilation sections. Full marks
to Digital Mars for providing a very simple IDE that allows use of an existing
source tree.

Funny things started to happen when I started to optimize. I turned up an
invariant problem and fixed it (my bad code). I am left now with the following
situation, dealing with about 220 classes in 5 subdirectories:

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.

Jan 16 2006

↑ ↓ ← → Arjan <arjan ask.me> writes:

John Redmond wrote:
 I am porting an XML/XSLT package from Linux and, thanks to Digital Mars, this
 has been a remarkably straightforward matter. In fact, the only parts of the
 source that needed changing were to do with character handling.
 
 I can now compile from the same source with Digital Mars on XP and gcc (using
 KDevelop) on Linux, using very few conditional complilation sections. Full
marks
 to Digital Mars for providing a very simple IDE that allows use of an existing
 source tree.


Yes the idde has been always my favorit idde for project management, 
easy to use and very quick. Only add your source files (c/cpp) set 
includes and "reparse all" and voila there are all the dependecies! The 
various view filters and sortings on the project files is also a nice 
thing to have!

 
 Funny things started to happen when I started to optimize. I turned up an
 invariant problem and fixed it (my bad code). I am left now with the following
 situation, dealing with about 220 classes in 5 subdirectories:
 
 1. Rebuild with -o+speed switch. No complilation errors.
 2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".

 3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
 code switch reset, then relink.
 4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)

 
 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.


And that isn;t caused by the 'missing' code?

Arjan

Jan 17 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

Thanks for your interest, Arjan, but I still have problems:

In article <dqicjo$u7p$1 digitaldaemon.com>, Arjan says...
John Redmond wrote:
 I am porting an XML/XSLT package from Linux and, thanks to Digital Mars, this
 has been a remarkably straightforward matter. In fact, the only parts of the
 source that needed changing were to do with character handling.
 
 I can now compile from the same source with Digital Mars on XP and gcc (using
 KDevelop) on Linux, using very few conditional complilation sections. Full
marks
 to Digital Mars for providing a very simple IDE that allows use of an existing
 source tree.


Yes the idde has been always my favorit idde for project management, 
easy to use and very quick. Only add your source files (c/cpp) set 
includes and "reparse all" and voila there are all the dependecies! The 
various view filters and sortings on the project files is also a nice 
thing to have!

 
 Funny things started to happen when I started to optimize. I turned up an
 invariant problem and fixed it (my bad code). I am left now with the following
 situation, dealing with about 220 classes in 5 subdirectories:
 
 1. Rebuild with -o+speed switch. No complilation errors.
 2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".


THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
__ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
__ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
WILD POINTER. POSSIBLE? 
 3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
 code switch reset, then relink.
 4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)

 
 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.


And that isn;t caused by the 'missing' code?


Arjan

Jan 17 2006

↑ ↓ ← → Arjan <arjan ask.me> writes:

John Redmond wrote:
Funny things started to happen when I started to optimize. I turned up an
invariant problem and fixed it (my bad code). I am left now with the following
situation, dealing with about 220 classes in 5 subdirectories:

1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".


 
 THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
 __ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
 __ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
 WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
 MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
 WILD POINTER. POSSIBLE? 


OK clear, are you building a lib/dll? Or just a plain executable?

3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
code switch reset, then relink.
4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)




So when you just turn off the "C++ inlining" optimization options for 
just this source file the crash goes away?

Arjan

Jan 18 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

Arjan,

Thanks for continuing this thread. To summarize:

1. Compile an executable from all source files with -o+speed.
2. Crashes on launch. It is not possible to get any print statements out, or to
catch any exceptions.
3. Turn off C++ inlining, recompile "commenttemplate.cpp" and relink.
4. No problems with launch.
5. Yes, it IS amazing.

John


In article <dqktnf$2dr$1 digitaldaemon.com>, Arjan says...
John Redmond wrote:
Funny things started to happen when I started to optimize. I turned up an
invariant problem and fixed it (my bad code). I am left now with the following
situation, dealing with about 220 classes in 5 subdirectories:

1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".


 
 THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
 __ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
 __ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
 WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
 MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
 WILD POINTER. POSSIBLE? 


OK clear, are you building a lib/dll? Or just a plain executable?

3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
code switch reset, then relink.
4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)




So when you just turn off the "C++ inlining" optimization options for 
just this source file the crash goes away?

Arjan

Jan 18 2006

↑ ↓ ← → Arjan <arjan ask.me> writes:

John Redmond wrote:
 Arjan,
 
 Thanks for continuing this thread. To summarize:
 
 1. Compile an executable from all source files with -o+speed.
 2. Crashes on launch. It is not possible to get any print statements out, or to
 catch any exceptions.
 3. Turn off C++ inlining, recompile "commenttemplate.cpp" and relink.
 4. No problems with launch.
 5. Yes, it IS amazing.


Yes it is.

Since you have the IDDE it is possible to debug the startup of the 
program. Have you tried that?

IDDE menu [Debug][Settings] option "Debug application startup".

Maybe you get a hint from there. I sounds to me like something is wrong 
with global/static initialization. Maybe the order in which stuff is 
initialized.

Arjan

 
 John
 
 
 In article <dqktnf$2dr$1 digitaldaemon.com>, Arjan says...
 
John Redmond wrote:

Funny things started to happen when I started to optimize. I turned up an
invariant problem and fixed it (my bad code). I am left now with the following
situation, dealing with about 220 classes in 5 subdirectories:

1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".



THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
__ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
__ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
WILD POINTER. POSSIBLE? 


OK clear, are you building a lib/dll? Or just a plain executable?


3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
code switch reset, then relink.
4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)




So when you just turn off the "C++ inlining" optimization options for 
just this source file the crash goes away?

Arjan

Jan 19 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

Arjan,

The saga continues. I took your advice and selected Debug Application Setup in
the Debug > Settings dialog. Then:

1. I selected -o+speed without inlining. All the source files compiled OK.
2. When the link step came, the whole IDDE crashed with explanation:
"Unexpected OPTLINK termination at EIP = 4000408C",
followed by a list of register contents.
3. The OPTLINK crash was very ungraceful, and left behind a $SCW$.EXE file in
the source root.
4. Now came Windows at its charming best: I could not remove $SCW$.EXE because
"... being used by another person or program...". I had to log out and in again
to remove it.

Conclusion? I don't really know, but there is no doubt that the crash came from
the linker, caused by my source code or the linker itself?

John




In article <dqnma3$2kec$1 digitaldaemon.com>, Arjan says...
John Redmond wrote:
 Arjan,
 
 Thanks for continuing this thread. To summarize:
 
 1. Compile an executable from all source files with -o+speed.
 2. Crashes on launch. It is not possible to get any print statements out, or to
 catch any exceptions.


 4. No problems with launch.
 5. Yes, it IS amazing.


Yes it is.

Since you have the IDDE it is possible to debug the startup of the 
program. Have you tried that?

IDDE menu [Debug][Settings] option "Debug application startup".

Maybe you get a hint from there. I sounds to me like something is wrong 
with global/static initialization. Maybe the order in which stuff is 
initialized.

Arjan

 
 John
 
 
 In article <dqktnf$2dr$1 digitaldaemon.com>, Arjan says...
 
John Redmond wrote:

Funny things started to happen when I started to optimize. I turned up an
invariant problem and fixed it (my bad code). I am left now with the following
situation, dealing with about 220 classes in 5 subdirectories:

1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.


That should be relative simple to find out where the bang happens, just 
set some "check-points".



THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
__ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
__ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
WILD POINTER. POSSIBLE? 


OK clear, are you building a lib/dll? Or just a plain executable?


3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
code switch reset, then relink.
4. Runs fine.


When you compile the commenttemplate.cpp file without -o+speed does the 
crash still happen? (you are able to set the optimization used for the 
every single cpp file in the idde, right click the file)




So when you just turn off the "C++ inlining" optimization options for 
just this source file the crash goes away?

Arjan

Jan 19 2006

↑ ↓ ← → Arjan <arjan ask.me> writes:

John Redmond wrote:
 Arjan,
 
 The saga continues. I took your advice and selected Debug Application Setup in
 the Debug > Settings dialog. Then:
 
 1. I selected -o+speed without inlining. All the source files compiled OK.
 2. When the link step came, the whole IDDE crashed with explanation:
 "Unexpected OPTLINK termination at EIP = 4000408C",
 followed by a list of register contents.
 3. The OPTLINK crash was very ungraceful, and left behind a $SCW$.EXE file in
 the source root.


hmm not so nice....

 4. Now came Windows at its charming best: I could not remove $SCW$.EXE because
 "... being used by another person or program...". I had to log out and in again
 to remove it.


kill the scwmn32 process next time.

 
 Conclusion? I don't really know, but there is no doubt that the crash came from
 the linker, caused by my source code or the linker itself?
 
 John


You left pretty much own your own now.

Since the crash seems to happen before main is called, try to find the 
code in your project which gets run before main and see if there is some 
dependency in initializing or executing...

DMC has some extension which might be handy to help you assure some 
requirements are met before the next code is executed/compiled.

see: http://www.digitalmars.com/ctg/ctg.html language extensions and 
C/C++ extensions.

Arjan

 
 
 
 
 In article <dqnma3$2kec$1 digitaldaemon.com>, Arjan says...
 John Redmond wrote:
 Arjan,

 Thanks for continuing this thread. To summarize:

 1. Compile an executable from all source files with -o+speed.
 2. Crashes on launch. It is not possible to get any print statements out, or to
 catch any exceptions.


 4. No problems with launch.
 5. Yes, it IS amazing.



 Since you have the IDDE it is possible to debug the startup of the 
 program. Have you tried that?

 IDDE menu [Debug][Settings] option "Debug application startup".

 Maybe you get a hint from there. I sounds to me like something is wrong 
 with global/static initialization. Maybe the order in which stuff is 
 initialized.

 Arjan

 John


 In article <dqktnf$2dr$1 digitaldaemon.com>, Arjan says...

 John Redmond wrote:

 Funny things started to happen when I started to optimize. I turned up an
 invariant problem and fixed it (my bad code). I am left now with the following
 situation, dealing with about 220 classes in 5 subdirectories:

 1. Rebuild with -o+speed switch. No complilation errors.
 2. Crashes on running.


 set some "check-points".


 THIS IS THE POINT THAT I SHOULD HAVE EMPHASIZED: THERE IS __NO__ EVIDENCE THAT
 __ANY__ CODE IS EXECUTED ON LAUNCH, SO THAT NO PRINT STATEMENTS ARE EXECUTED
 __ANYWHERE__ IN THE PACKAGE. AND __NO EXECEPTIONS__ ARE CAUGHT.
 WITHOUT ANY EVIDENCE, I FEEL IN MY BONES THAT THERE IS SOMETHING LIKE A CODE
 MISALIGNMENT SOMEWHERE. AND THAT THIS STARTS __BEFORE__ COMMENTTEMPLATE. OR A
 WILD POINTER. POSSIBLE? 




 3. Recompile one file (it happens to be 'commenttemplate.cpp') with the inline
 code switch reset, then relink.
 4. Runs fine.


 crash still happen? (you are able to set the optimization used for the 
 every single cpp file in the idde, right click the file)




 just this source file the crash goes away?

 Arjan

Jan 20 2006

↑ ↓ ← → Scott Michel <scottm aero.org> writes:

John Redmond wrote:
1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.






You don't have wacky things going on in globally constructed variables,
do you? Also, are you using the CD or the free version of the compiler?
If you're using the CD version, are you attempting to use the DLL
runtime or the static runtime?

I ask about globally constructed variables b/c that's all going to
happen before main(). The other question would be with respect to the
inlined code -- what dependencies does it have on (properly constructed)
global state?

Jan 20 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

Arjan and Scott:

Thanks for staying with me on this. To answer your questions, Scott:

1. I am using the CD IDDE with 8.42n compiler.
2. I am trying to build a statically-linked console app.

I have to agree with you both, that there are probably problems with
initialization of a small number of globals. (I have been aware of the danger,
and have used Meyers singletons where possible.)

It will take me a little while to establish this, as there are, at last count,
229 classes. I suppose that what has distracted me is the fact that I have been
getting LINK errors as well as runtime errors. I will stay with it (I HAVE to)
and, if there is a general lesson to be learnt, I will report back.

Thanks again,
John

In article <43D121D0.7040004 aero.org>, Scott Michel says...
John Redmond wrote:
1. Rebuild with -o+speed switch. No complilation errors.
2. Crashes on running.






You don't have wacky things going on in globally constructed variables,
do you? Also, are you using the CD or the free version of the compiler?
If you're using the CD version, are you attempting to use the DLL
runtime or the static runtime?

I ask about globally constructed variables b/c that's all going to
happen before main(). The other question would be with respect to the
inlined code -- what dependencies does it have on (properly constructed)
global state?

Jan 20 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"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.

Jan 22 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

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.

Jan 22 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"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.

Jan 22 2006

↑ ↓ ← → Scott Michel <scottm aero.org> writes:

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.)

Jan 24 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

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.)

Jan 26 2006

↑ ↓ ← → Scott Michel <scottm aero.org> writes:

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

Jan 27 2006

↑ ↓ ← → John Redmond <John_member pathlink.com> writes:

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

Jan 27 2006

↑ ↓ ← → Jan Knepper <jan smartsoft.us> writes:

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

Jan 27 2006