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.

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

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?
YES, THE MISSING CODE __MUST__ BE IRRELEVANT?
>
>Arjan

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

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

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

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.
> Unexpected OPTLINK termination aat EIP = 4000408c"> 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
>> 
>> 
>> 

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.
>> Unexpected OPTLINK termination aat EIP = 4000408c"> 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
>>>
>>>
> 
> 

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?

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?