RE: Release build confusion

Like Mike says (hi Mike, sorry I missed you in Brighton btw :)) I don't
think there's anyway to disable this, it's an implicit behaviour of the
debug heap. However you *CAN* control what the heap is filled with while
debugging (see _heapfill etc) and this is something you should certainly
make use of.

Personally I consider utilising this functionality to be as fundamental as
checking (and asserting on) memory leaks in debug versions. If you aren't
considering the case where allocated memory has undefined values then at
best you're setting yourself up for undefined behaviour, and at worst
horrible crashes that only occur after playing X number of levels.

Our memory manager allows you to toggle the value which allocated/free'd
memory is filled with, and different people use different settings to catch
problems. Personally I have everything filled with NANs and run with
floating point exceptions as I find this to be most useful on a day to day
basis.

________________________
andrew grant
lead programmer . climax group

 

> -----Original Message-----
> From: [email protected]
[mailto:gamedevlists-
> [email protected]] On Behalf Of Mike Burrows
> Sent: Wednesday, October 05, 2005 7:52 PM
> To: [email protected]
> Subject: RE: [GD-Windows] Release build confusion
> 
> I don't know of a way to disable this, but I'll ask around...
> 
> Have you tried attaching to the process after "Running" (note: note
debugging)?
> 
> Just a thought,
> 
> Cheers, Mike
> 
> -----Original Message-----
> From: [email protected]
[mailto:gamedevlists-
> [email protected]] On Behalf Of Emmanuel Astier
> Sent: Wednesday, October 05, 2005 9:00 AM
> To: [email protected]
> Subject: Re: [GD-Windows] Release build confusion
> 
> I second that.
> 
> I had the same issue noe month ago : crashing outside
> VS, not crashing inside.
> And it was a non initialized pointer that lead to the
> crash.
> 
> Funny thing is, one week later, I had the opposite
> behaviour : crashing inside VS, not crashing outside,
> still for memory reasons...
> 
> What I'm not aware of, is a way to tell VS not to
> behave this way. Is there a way  ?
> 
> 
> Emmanuel
> 
> 
> --- Kent Quirk <[email protected]> a écrit :
> 
> > I believe that unless you tell it not to, the
> > debugger fills
> > newly-allocated memory with zeros. You may be
> > counting on that behavior
> > somewhere. Check your initializations, particularly
> > of pointers; you may
> > assume they're zero if they haven't yet been
> > assigned.
> >
> >     Kent
> >
> >
> >
> > Chris Raine wrote:
> >
> > >Hi,
> > >
> > >I have a problem with our release builds which is
> > driving me nuts for a
> > >couple of days now. If we start our release build
> > from within the Visual
> > >Studio debugger, everything works fine, yet if we
> > start our release
> > >build outside of Visual Studio, it either crashes
> > or displays weird
> > >render artifacts. The debug build works in the IDE
> > as well as outside.
> > >
> > >
> > >
> >
> >
> >
> >
> -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content,
> > downloads, discussions,
> > and more.
> > http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > [email protected]
> >
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> >
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________________________
> _________
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
> Téléchargez cette version sur http://fr.messenger.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gamedevlists-windows mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gamedevlists-windows mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5