Hi all

-
Hi all,
I'm experiencing a very strange problem on compiling a DataSnap server on XE2 :

I have systematic error message and crash at  startup (EInsufficientRTTI) ; If I switch building configurations between Release/Debug and compile , the bug vanishes after 4 or 5 compilations. This bug occurs systematically when using msbuild through command line.

This bug wasn't occuring in previous versions , before adding mORMot framework (maybe it has nothing to do with it but it's the major  change).
 
I never seen such a thing happening. Anyone ahs an idea ?

TY !

Comments

  1. Kevin McCoyApril 8, 2013 at 7:53 AM

    It sounds to me like you have an uninitialized variable in your code.  As the EXE memory footprint moves around, or the datagroup/stack happens to have a random-but-reasonable value for the variable to assume, your app mysteriously works.  If the variable takes on an unreasonable value, your app crashes.  Check your hints and warnings when you compile - you may find it if you are lucky.

    ReplyDelete
  2. Olivier SCHWABApril 8, 2013 at 8:54 AM

    thanks for your advice Kevin McCoy . I'll check my warnings anyway (doesn't hurt) , but do you think that it could lead to compiler producing either 'good' or 'bad' executables ?

    ReplyDelete
  3. Kevin McCoyApril 8, 2013 at 8:58 AM

    "good or bad"? Yes, but you may get different results on different hardware, OS, Etc.  You need a bigger sample size to tell for sure if your "good" EXE is actually bullet proof.

    ReplyDelete
  4. Asbjørn HeidApril 8, 2013 at 10:17 AM

    Olivier SCHWAB Will the "bad" EXE always fail, and vice versa? Also does it happen when building on a different PC? Could be RAM/disk corruption issues.

    ReplyDelete
  5. Olivier SCHWABApril 8, 2013 at 10:52 AM

    Asbjørn Heid  the bad always fail, and the 2 exe seems to have a different size (1.5 mb more for the good one).

    ReplyDelete
  6. Asbjørn HeidApril 8, 2013 at 11:03 AM

    Olivier SCHWAB Oh different sizes, that's weird. Could it be a search path issue, where the linker sometimes picks one of two resources (dcus or something)?

    ReplyDelete
  7. Birger JansenApril 8, 2013 at 11:22 AM

    We have the same issue with one of our projects. Even in a build script we first have to a 'build all' followed by a compile to get rid of this behaviour!

    ReplyDelete
  8. Olivier SCHWABApril 9, 2013 at 12:34 AM

    Birger Jansen Can you explain me how you perform "build all" in a script please ? TY

    ReplyDelete
  9. Olivier SCHWABApril 9, 2013 at 12:36 AM

    Asbjørn Heid I thought it was the problem so I've put search path in  "All build configurations" ... My instinct tells me it's linked to mORMot, I'll try to test if it's working when I don't have this framewok in 'uses'...

    ReplyDelete
  10. Birger JansenApril 9, 2013 at 12:55 AM

    Olivier SCHWAB That is in FinalBuilder.

    ReplyDelete
  11. Olivier SCHWABApril 9, 2013 at 3:21 AM

    I've found the following trick :
    msbuild /v:d %PROJECT% /target:MakeAll /p:config=Debug

    => Good Exe

    msbuild /v:d %PROJECT% /target:BuildAll /p:config=Debug

    => bad Exe

    Humhumhum ...

    ReplyDelete
  12. Olivier SCHWABApril 9, 2013 at 3:25 AM

    BTW Jordi Corbilla 's tool for Compilation was a very big help : http://thundaxsoftware.blogspot.fr/2011/07/delphi-msbuild.html

    ReplyDelete
  13. Jordi CorbillaApril 9, 2013 at 4:45 AM

    I'm glad it helped! Olivier SCHWAB

    ReplyDelete
  14. Olivier SCHWABApril 11, 2013 at 8:32 AM

    after further investigations, the problem comes from mORMot framework :

    http://synopse.info/forum/viewtopic.php?id=1211

    I don't really understand why in some case compilation is correct and why in another it is not, but, anyway , all is working now.
    Thanks to all of you for your suggestions !

    ReplyDelete

Post a Comment