On Mon, 2012-08-27 at 14:19 +0800, Liuwh wrote:
> Hi all,
>  
> I downloaded FlightGear/SimGear/fgdata v2.9 via GIT, and also
> downloaded pre-compiled 3rdParty dependencies from 
> ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/fgfs-win32-VS100-3rdParty+OSG-20120411.zip
>  
> I built it, the release version can run well, but the debug version
> crashed when I the weather from dialog and click "close",  the result
> was the same when I operated the menu and click apply or close.  The
> call stack indicates that program stopped in _CrtIsValidHeapPointer
> called by puGroup from PLIB functions.
>  
> Did anyone ever encounter this problem?
>  
> BTW, the debug version runs very slow, I don't know whether this also
> occured when others debugging FlightGear.
>  
> Thanks!

Hi Liuwh,

Not sure why you are trying to build the Debug 
version of fgfs, since the 3rd party zip you mentioned 
does NOT contain the 3rdparty Debug library builds...

This is no particular problem when the library is a 
DLL (shared) library, except you will not be able 
to trace into it, but you are mixing the runtimes 
Release and Debug when using static libraries like 
PLIB... 

Quite surprised you even got Debug fgfs to link...

I am steadily building up a parallel Release and 
Debug build, see - 
 http://downloads.fgx.ch/WIN32 
but note I have not yet added say plib-msvc100-rel,
nor dbg.zip, and some others, yet... Must try to get 
to that soon...,

Second, the Debug version certainly runs up to 10 
or MORE times SLOWER ;=((

(a) All functions have extended entry and exit code,
prologue and epilogue, where the user stack is filled 
with a pattern like 0xdd, so the runtime can check if 
you have initialized all the required variables before 
using them...

(b) All functions perform stack level checking on 
exit. 

(c) All memory allocated is a special debug allocation 
where more than the requested bytes is allocated, 
and a leader and trailer area are again filled with a 
pattern, 0xde IIRC, and the application receives a pointer 
after the leader so on memory release, the runtime 
can check if you have under or over run the requested 
memory...

Now fgfs allocates a LOT of memory, and this includes 
memory for std lists, vectors, maps, etc, so for example 
you will see it spends a long time to say load the 
navaids... and lots more time loading scenery... etc.

(d) And the Debug version has a LOT of assert() 
code added... In fact it is sometimes difficult to 
get the Debug version to run without the usual 
assertion failed dialog... Maybe that is what you 
mentioned as _CrtIsValidHeapPointer...

These 'bugs' that show up only in the MSVC Debug 
version seldom get addressed, since there are very few 
of us ready to take all the time required to track 
them down ;=(( and then convince the big unix base 
developers that there is a problem that they just 
do NOT see...

HTH, and I am glad to hear the Release runs 
well... congrats on doing your own build ;=))
That takes some effort...

Enjoy...

Regards,
Geoff.





------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to