Thread: RE: [GD-Windows] Release build confusion
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Mike B. <mi...@wi...> - 2005-10-06 02:52:34
|
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: gam...@li... = [mailto:gam...@li...] On Behalf Of = Emmanuel Astier Sent: Wednesday, October 05, 2005 9:00 AM To: gam...@li... 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 <ken...@co...> a =E9crit : > I believe that unless you tell it not to, the > debugger fills=20 > newly-allocated memory with zeros. You may be > counting on that behavior=20 > somewhere. Check your initializations, particularly > of pointers; you may=20 > assume they're zero if they haven't yet been > assigned. >=20 > Kent >=20 >=20 >=20 > Chris Raine wrote: >=20 > >Hi,=20 > > > >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.=20 > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > 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 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 =09 =09 =09 _________________________________________________________________________= __=20 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! = Messenger=20 T=E9l=E9chargez 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 Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Andrew G. <ag...@cl...> - 2005-10-06 06:29:17
|
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 =20 > -----Original Message----- > From: gam...@li... [mailto:gamedevlists- > win...@li...] On Behalf Of Mike Burrows > Sent: Wednesday, October 05, 2005 7:52 PM > To: gam...@li... > Subject: RE: [GD-Windows] Release build confusion >=20 > I don't know of a way to disable this, but I'll ask around... >=20 > Have you tried attaching to the process after "Running" (note: note debugging)? >=20 > Just a thought, >=20 > Cheers, Mike >=20 > -----Original Message----- > From: gam...@li... [mailto:gamedevlists- > win...@li...] On Behalf Of Emmanuel Astier > Sent: Wednesday, October 05, 2005 9:00 AM > To: gam...@li... > Subject: Re: [GD-Windows] Release build confusion >=20 > I second that. >=20 > 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. >=20 > Funny thing is, one week later, I had the opposite > behaviour : crashing inside VS, not crashing outside, > still for memory reasons... >=20 > What I'm not aware of, is a way to tell VS not to > behave this way. Is there a way ? >=20 >=20 > Emmanuel >=20 >=20 > --- Kent Quirk <ken...@co...> a =E9crit : >=20 > > 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 > > Gam...@li... > > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 > > >=20 >=20 >=20 >=20 >=20 >=20 >=20 > __________________________________________________________________ > _________ > Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! = Messenger > T=E9l=E9chargez cette version sur http://fr.messenger.yahoo.com >=20 >=20 > ------------------------------------------------------- > 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 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 >=20 > ------------------------------------------------------- > 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 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU5 |
|
From: Chris R. <c....@gm...> - 2005-10-06 13:05:12
|
That actually worked out pretty well. I still believe (although I am not sure) that the debugger injects it's memory handlers into the running application at the point it attaches itself to the process. I let my application run for a while and attached the debugger later on - and I easily could pinpoint the offending line of code which caused this mayhem after a few retries and a few minutes of heavy thinking. We actually had two memory related issues - one uninitialized pointer, and as an indirect consequence of that, we took the pointer of an object on the stack and used it after it was destroyed long ago. Thanks for all the insights (especially the _heapfill()&co functions)! regards, Chris Raine On Wed, 2005-10-05 at 19:52 -0700, Mike Burrows wrote: > 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: gam...@li... [mailto:gam...@li...] On Behalf Of Emmanuel Astier > Sent: Wednesday, October 05, 2005 9:00 AM > To: gam...@li... > 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 <ken...@co...> 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 > > Gam...@li... > > > 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 > Gam...@li... > 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 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU5 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X