Thread: RE: [GD-Windows] Nasty GUI bug
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Andrew G. <ag...@cl...> - 2002-10-10 21:35:32
|
I've seen things like that before, and when it's happened I've found I've been trashing memory somewhere. Weird I know, but there you go. Andy @ Climax Brighton > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 10 October 2002 22:08 > To: gam...@li... > Subject: [GD-Windows] Nasty GUI bug > > > I have a nasty bug that breaks Windows GUI big time. > > Here's the context : > - Windows 98 RC2 > - 3DS MAX 4.0 > - A MAX plug using the MFC, among other things > > And what happens : > - I run MAX, plug gets loaded and works fine for a moment. > - Then after some manipulations, the whole Windows GUI breaks > down, falls > appart, goes berserk, becomes mad. Not only in MAX : in > Wordpad, in Notepad, > on the desktop, well, in all other apps. Fonts change for the > ugly years-old > system fonts. Icons disappear. Drag-and-drop doesn't work > anymore. Notepad > don't run anymore. Paint doesn't either, saying there's not > enough memory to > complete requested operation. I could go on for hours. > - Even when the whole world is fucked up, everything goes > back to normal the > second I close MAX. > - And if I remove the MAX Plug, the bug never comes, so I > guess it's the > guilty one. > > I simply have no idea how to track that one, or what could be > happening. > Ideas ? > > Example of fucked-up GUI : > http://www.codercorner.com/GUI_Bug_Fileselect.jpg > http://www.codercorner.com/GUI_Bug_WordPad.jpg > > The problem seems to appear on some other machines, not only > mine, but not > on all of them. Most of the time, it works. > > ..... > > Pierre > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Rich <leg...@xm...> - 2002-10-10 23:16:16
|
In article <F23...@FR...>,
Andrew Grant <ag...@cl...> writes:
> I've seen things like that before, and when it's happened I've found I've
> been trashing memory somewhere.
>
> Weird I know, but there you go.
Sounds like what I was going to suggest... use a tool like Purify,
BoundsChecker, etc., to find the problem.
You say it only occurs on Win98, but I'm willing to bet that's not
quite true. If its a memory bug, its probably occuring everywhere,
just that the effects are more damaging on Win9x. Purify only works
on NT-based platforms (so not 9x), but its worth it, IMO.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Pierre T. <p.t...@wa...> - 2002-10-10 23:37:40
|
Hi Rich, > Sounds like what I was going to suggest... use a tool like Purify, > BoundsChecker, etc., to find the problem. I just installed BoundsChecker. Going to see what I can find. > You say it only occurs on Win98, but I'm willing to bet that's not I didn't say that, but maybe that was unclear. I'm running W98 but the bug *does* indeed occur on other machines, e.g. with W2K. Going to check my bounds right now. Pierre |
|
From: Javier A. <ja...@py...> - 2002-10-11 06:51:01
|
Pierre Terdiman <p.t...@wa...> wrote: > I didn't say that, but maybe that was unclear. I'm running W98 but > the bug *does* indeed occur on other machines, e.g. with W2K. The only way I have ever managed to corrupt the Win2K GUI was by creating graphics resources and not deleting them: bitmaps, DCs, fonts, etc. The last time I had this was because I was creating a new bitmap every time the window was resized / redrawn, but not freeing the previous bitmap properly. I was surprised to see Windows corrupted even after I shut down the offending program, Restart needed. Javier Arevalo Pyro Studios |
|
From: Mickael P. <mpo...@ed...> - 2002-10-11 07:28:26
|
> Pierre Terdiman <p.t...@wa...> wrote:
>
> > I didn't say that, but maybe that was unclear. I'm running W98 but
> > the bug *does* indeed occur on other machines, e.g. with W2K.
>
> The only way I have ever managed to corrupt the Win2K GUI was by creating
> graphics resources and not deleting them: bitmaps, DCs, fonts, etc. The
last
> time I had this was because I was creating a new bitmap every time the
> window was resized / redrawn, but not freeing the previous bitmap
properly.
I second that.
This kind of behavior is generaly not memory related, but "resource"
related. You can kill a windows 98 simply by doing a loop that call
"CreateWindow" repetetively.
Mickael Pointier
|
|
From: <e_a...@ya...> - 2002-10-11 08:37:07
|
Hi, I would say it is a problem of memory, but not of resources. As Javier had just point out, a resource leak is not fixed once you kill the application. Yesterday, I had the same kind of corruption : drawing the GUI of any of the open application was taking ages... The Task manager show me CodeWarrior was using 500 Mg, and that there was more than 1 gigaoctet used... Once I killed CodeWarrior, everything was OK again... Emmanuel --- Mickael Pointier <mpo...@ed...> a écrit : > > Pierre Terdiman <p.t...@wa...> wrote: > > > > > I didn't say that, but maybe that was unclear. > I'm running W98 but > > > the bug *does* indeed occur on other machines, > e.g. with W2K. > > > > The only way I have ever managed to corrupt the > Win2K GUI was by creating > > graphics resources and not deleting them: bitmaps, > DCs, fonts, etc. The > last > > time I had this was because I was creating a new > bitmap every time the > > window was resized / redrawn, but not freeing the > previous bitmap > properly. > > I second that. > > This kind of behavior is generaly not memory > related, but "resource" > related. You can kill a windows 98 simply by doing a > loop that call > "CreateWindow" repetetively. > > Mickael Pointier > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com |
|
From: Mickael P. <mpo...@ed...> - 2002-10-11 09:16:29
|
> Hi,
>
> I would say it is a problem of memory, but not of
> resources. As Javier had just point out, a resource
> leak is not fixed once you kill the application.
> Yesterday, I had the same kind of corruption : drawing
> the GUI of any of the open application was taking
> ages... The Task manager show me CodeWarrior was using
> 500 Mg, and that there was more than 1 gigaoctet
> used...
> Once I killed CodeWarrior, everything was OK again...
<rant>
Killing CodeWarrior generaly solve a lot of things...
</rant>
Well, more seriously, in my experience resource leaks
were fatal under windows 95/98 (millenium also I suspect),
but not always under windows 2k. Depending which kind of
resource was abused 2k sometimes manage to restore it's
internal state when the abusing program is killed, for some
other kind of resources he does not manage to do it.
By resource I mean things like file system handles, gui
items, and basicaly all these things you have to allocate
and then release but are not necessarily related to memory.
The worse problems I had were with DLL, because of the
reference counting thing you not always manage to free
it from memory, so the lost resources I still considered
as used.
Mike
|
|
From: Pierre T. <p.t...@wa...> - 2002-10-11 14:53:11
|
> Going to check my bounds right now.
No luck so far, but BS found something in another part of my code. This is
in a DX7 renderer, the code is :
// Get the current display depth
DEVMODE devmode;
devmode.dmSize = sizeof(DEVMODE);
EnumDisplaySettings(null, ENUM_CURRENT_SETTINGS, &devmode);
And BS tells me :
Stack memory overrun
Copying 156 bytes to devmode
Starting offset: 0, destination size: 148 bytes
Indeed, sizeof(DEVMODE) is 148.
Is it a known bug ? Looks nasty.
Also, is there a way to get the internal reference count of a DLL ?
...to be continued...
Pierre
|
|
From: Rich <leg...@xm...> - 2002-10-10 23:49:28
|
In article <04eb01c270b5$bf7802e0$0e00000a@pierre>,
"Pierre Terdiman" <p.t...@wa...> writes:
> I didn't say that, but maybe that was unclear. I'm running W98 but the bug
> *does* indeed occur on other machines, e.g. with W2K.
Well, lots of stuff in the GUI is in user mode I suppose, so could be
corrupted by an errant app. Things like image lists are definately in
your process space and could be damaged.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Tom F. <to...@mu...> - 2002-10-11 15:01:44
|
Erm... IIRC, the GetDeviceCaps call of many drivers scribbles past the area you give it. So allocate a much bigger buffer (I used 4k extra and didn't have any further problems). Maybe this is a similar or related problem? Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 11 October 2002 15:51 > To: gam...@li... > Subject: Re: [GD-Windows] Nasty GUI bug > > > > Going to check my bounds right now. > > No luck so far, but BS found something in another part of my > code. This is > in a DX7 renderer, the code is : > > // Get the current display depth > DEVMODE devmode; > devmode.dmSize = sizeof(DEVMODE); > EnumDisplaySettings(null, ENUM_CURRENT_SETTINGS, &devmode); > > And BS tells me : > > Stack memory overrun > Copying 156 bytes to devmode > Starting offset: 0, destination size: 148 bytes > > Indeed, sizeof(DEVMODE) is 148. > > Is it a known bug ? Looks nasty. > > > Also, is there a way to get the internal reference count of a DLL ? > > ...to be continued... > > Pierre > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Pierre T. <p.t...@wa...> - 2002-10-11 15:26:37
|
> Erm... IIRC, the GetDeviceCaps call of many drivers scribbles past the area > you give it. So allocate a much bigger buffer (I used 4k extra and didn't > have any further problems). > > Maybe this is a similar or related problem? I'll just use a bigger structure indeed, but that's evil. BTW I forgot to set the dmDriverExtra member to 0, but it doesn't fix the bug anyway (memory still gets overwritten). Pierre |
|
From: Pierre T. <p.t...@wa...> - 2002-10-11 18:30:02
|
....is not a good idea, according to the MSDN. Why ? What are the possible consequences ? Thanks, Pierre |
|
From: Jon W. <hp...@mi...> - 2002-10-11 18:49:44
|
Here's a possible implementation of the DLL loader code:
void WindowsDLLLoader( char const * filename )
{
AcquireLock( globalDllLock );
void * address = ReadFile( filename );
RelocateDll( address );
if( !CallDllWinMain( address ) ) {
FreeDllMemory( address );
}
ReleaseLock( globalDllLock );
}
I'm sure there's other problems, such as with cyclic
dependencies (perhaps involving more than two DLLs) and
initialization order.
Cheers,
/ h+
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Pierre Terdiman
> Sent: Friday, October 11, 2002 11:28 AM
> To: gam...@li...
> Subject: [GD-Windows] Using LoadLibrary in DllMain....
>
>
> ....is not a good idea, according to the MSDN.
>
> Why ? What are the possible consequences ?
>
> Thanks,
> Pierre
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
|
|
From: Pierre T. <p.t...@wa...> - 2002-10-11 19:26:45
|
Ok, so I installed it and started looking for obvious bugs. I found a couple of obvious ones (a device context not released for example), but otherwise there are a lot of memory & resource leaks I'm not sure about. Here they are : http://www.codercorner.com/BoundsChecker.jpg The only obvious one to me is that mutex with "CreateMutexA" somewhere in the middle of the pic. Indeed I don't release it, my mistake. Now, about all the other leaks.... Does it look normal ? I'm not familiar enough with BS to be sure. I think those are mainly leaks within D3D and/or Windows I don't have much control over. Is that right ? Or is it possible to get rid of all of them ? It's a bit scary. I should have installed BS a long time ago I guess. Pierre |
|
From: Julien K. <ma...@ju...> - 2002-10-11 19:43:59
|
You can check a simple Windows Application with BC. The last Time i used BC it reported 5 or 6 Memory-Leaks and/or Warnings for a empty Windows-Application and some more for a simple MFC-App.. Julien Koenen ----- Original Message ----- From: "Pierre Terdiman" <p.t...@wa...> To: <gam...@li...> Sent: Friday, October 11, 2002 9:24 PM Subject: [GD-Windows] BoundsChecker > Ok, so I installed it and started looking for obvious bugs. I found a couple > of obvious ones (a device context not released for example), but otherwise > there are a lot of memory & resource leaks I'm not sure about. > > Here they are : > http://www.codercorner.com/BoundsChecker.jpg > > The only obvious one to me is that mutex with "CreateMutexA" somewhere in > the middle of the pic. Indeed I don't release it, my mistake. > > Now, about all the other leaks.... > > Does it look normal ? I'm not familiar enough with BS to be sure. I think > those are mainly leaks within D3D and/or Windows I don't have much control > over. Is that right ? > > Or is it possible to get rid of all of them ? It's a bit scary. I should > have installed BS a long time ago I guess. > > Pierre > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: Garry & L. P. <po...@ad...> - 2002-10-12 12:02:03
|
BoundsChecker 7.0 (just released) does a much better job at keeping the system DLL leaks and errors out of your way. It's also much better at cradle to grave monitoring, catches many more leaks and errors and has a better GUI. See http://www.compuware.com/products/devpartner/bounds/ Garry (BoundsChecker Developer) |
×
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