Thread: [Plib-devel] GL_COLOR_MATERIAL pitfall
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Dave M. <dp...@ef...> - 2000-04-25 04:32:47
|
i saw something in Kilgard's "common opengl pitfalls" page that might be relevant to SSG. see "#14. Careful Enabling Color Material" at http://www.opengl.org/Coding/KilgardTechniques/oglpitfall/oglpitfall.html would this explain any of the problems encounted in ppe and flightgear? --Dave McClurg |
|
From: Steve B. <sjb...@ai...> - 2000-04-25 07:04:32
|
Dave McClurg wrote: > i saw something in Kilgard's "common opengl pitfalls" page that might be > relevant to SSG. > see "#14. Careful Enabling Color Material" at > > http://www.opengl.org/Coding/KilgardTechniques/oglpitfall/oglpitfall.html > > would this explain any of the problems encounted in ppe and flightgear? It's certainly something *like* that. In the course of discussions on OpenGL-Gamedev, it became aparrent that: 1) No two Guru's could agree on what *should* happen under every circumstance. 2) As a consequence of (1), quite a few OpenGL implementations actually get it wrong. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: <Va...@t-...> - 2000-04-25 11:20:55
|
Steve Baker wrote: > > In the course of discussions on OpenGL-Gamedev, it became aparrent > that: > > 1) No two Guru's could agree on what *should* happen under every > circumstance. > > 2) As a consequence of (1), quite a few OpenGL implementations > actually get it wrong. Can't they sit down and define a standard for OpenGL 1.3? Or are they already doing that? CU, Christian |
|
From: Steve B. <sjb...@ai...> - 2000-04-25 23:30:22
|
Christian Mayer wrote: > > Steve Baker wrote: > > > > In the course of discussions on OpenGL-Gamedev, it became aparrent > > that: > > > > 1) No two Guru's could agree on what *should* happen under every > > circumstance. > > > > 2) As a consequence of (1), quite a few OpenGL implementations > > actually get it wrong. > > Can't they sit down and define a standard for OpenGL 1.3? Or are they > already doing that? Well, there is a standard - but it's rather hard to understand from the wording in the specification - and the 'official' OpenGL test suite that is run on every implementation before it's allowed to be called 'OpenGL' doesn't have a test for this particular problem, so it's rather easy for broken implementations to sneak past. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Wolfram K. <w_...@rz...> - 2000-04-28 16:38:44
|
BTW, regarding the GL_COLOUR_MATERIAL problem: Steve said some time ago that the next thing to do would be to write a program that has the same problem as PLIB/PPE, but is as simple as possible. I think I read a long time ago about people "logging" OpenGL calls with some tool and think the easiest way would be to log them and throw out everything unneeded. However, I neither found a "generic OpenGL command recorder" nor a "Windows-dll-function-call-logger".Does anyone know of such a beast? If not, I could rename opengl.dll and write a new dll, that simply calls the old one and logs all calls. Bye bye, Wolfram. |
|
From: Curtis L. O. <cu...@me...> - 2000-04-28 16:55:45
|
Wolfram Kuss writes:
> BTW, regarding the GL_COLOUR_MATERIAL problem:
> Steve said some time ago that the next thing to do would be to write
> a program that has the same problem as PLIB/PPE, but is as simple as
> possible.
>
> I think I read a long time ago about people "logging" OpenGL
> calls with some tool and think the easiest way would be to log
> them and throw out everything unneeded.
>
> However, I neither found a "generic OpenGL command recorder"
> nor a "Windows-dll-function-call-logger".Does anyone know of such a
> beast?
>
> If not, I could rename opengl.dll and write a new dll, that simply
> calls the old one and logs all calls.
A while back Steve sent me something he had whipped up which he called
"xgl". Basically you include xgl.h instead of gl.h and prepend an "x"
in front of all your opengl calls. He then had things structured with
#defines so these could be translated straight to the real opengl
calls, or you could dump a log of the calls to console or file.
A modified version of this is part of the SimGear package:
ftp://ftp.flightgear.org/pub/fgfs/Source/
Regards,
Curt.
--
Curtis Olson Human Factors Research Lab Flight Gear Project
Twin Cities cu...@hf... cu...@fl...
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
|
|
From: Steve B. <sjb...@ai...> - 2000-04-28 18:18:43
|
Wolfram Kuss wrote:
>
> BTW, regarding the GL_COLOUR_MATERIAL problem:
> Steve said some time ago that the next thing to do would be to write
> a program that has the same problem as PLIB/PPE, but is as simple as
> possible.
>
> I think I read a long time ago about people "logging" OpenGL
> calls with some tool and think the easiest way would be to log
> them and throw out everything unneeded.
Since you mention it...I have been writing exactly such a thing
over the past couple of days. I have written a header file
containing about a gazillion things like:
#ifdef OPENGL_DEBUG
#define glBegin debug_glBegin
extern void debug_glBegin ( GLenum type ) ;
#endif
...then an executable containing:
void debug_glBegin ( GLenum type )
{
if ( logging ( "glBegin" ) )
fprintf ( debug_stderr, "glBegin ( %s ) ;\n".
enum_to_string ( type ) ) ;
if ( executing ( "glBegin" ) )
glBegin ( type ) ;
}
...the result (when it works) will be that you can compile your
opengl program with all your files #including the debugging
header file...then link to the executable and turn debug tracing
on and off either under program control or with a 'signal' from
outside.
That should precisely enable me to do what you say.
> However, I neither found a "generic OpenGL command recorder"
> nor a "Windows-dll-function-call-logger".Does anyone know of such a
> beast?
There are some around - but none that are portable (that I know of).
I've used 'ogldebug' on Silicon Graphics machine, under Linux, you
have a way to compile Mesa to make it trace execution.
But mine will be more flexible and let you do things like telling
the library to record everything from the next swapbuffers to the
one after that to get an entire frame's worth of data.
> If not, I could rename opengl.dll and write a new dll, that simply
> calls the old one and logs all calls.
Yep - that would prevent you from having to mess around with header
files - but forces you to trace calls made by other libraries like
GLU...I can see uses for both approaches.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
|
From: Wolfram K. <w_...@rz...> - 2000-04-29 19:38:49
|
Steve wrote: >Since you mention it...I have been writing exactly such a thing >over the past couple of days. Great, I look forward to it! This is not "xgl", but an improvement on it, is it not? Do you want to extract the OpenGL-commands from PPE/PLIB, that cause the GL_COLOUR_MATERIAL-bug yourself, or do you want me to look into it? BTW, at the moment I am also looking into the PPE-memory leaks you spoke about. There are indeed some. Bye bye, Wolfram Kuss. |
|
From: Steve B. <sjb...@ai...> - 2000-04-29 21:11:14
|
Wolfram Kuss wrote: > >Since you mention it...I have been writing exactly such a thing > >over the past couple of days. > > Great, I look forward to it! This is not "xgl", but an improvement on > it, is it not? Yes - it's kindof a reversal of it. With xgl, you have to manually write 'xglBegin' instead of 'glBegin' - and the header file conditionally convert the xgl's to gl's. With my new code, you can just write 'glBegin' and the header will map it to a routine with another name if it needs to. The second way is a lot more convenient - I have no idea why I didn't think of doing it like that in the first place! > Do you want to extract the OpenGL-commands from > PPE/PLIB, that cause the GL_COLOUR_MATERIAL-bug yourself, or > do you want me to look into it? Hopefully, when I finish dinking with this new stuff, it should be easy to capture a frame of imagery with the bug in it - and then reduce that code down to something small enough to understand. > BTW, at the moment I am also looking into the PPE-memory leaks you > spoke about. There are indeed some. :-( -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Dave M. <dp...@ef...> - 2000-04-30 04:45:32
|
> BTW, at the moment I am also looking into the PPE-memory leaks you > spoke about. There are indeed some. > I spotted a couple leaks in ssgImageLoader. But I think they only occur when the load fails and the default texture is used. |
|
From: Wolfram K. <w_...@rz...> - 2000-04-30 20:53:28
|
Dave wrote: >I spotted a couple leaks in ssgImageLoader. But I think they only occur >when the load fails and the default texture is used. Ok, thanks, I will ignore them. But at the moment I am still fighting MSVC (Microsoft Visual C++) :-(. The normal way to search for memory leaks with MSVC is very tedious. MSVC tells you all the memory leaks, but it only gives you the index of the allocation. So, for example, it says, the things that were allocated 6. and 23. of all allocations were not freed until the termination of the program. Of course it would be much better if you could convince MSVC to tell you where (filename + linenumber) the allocations were, but this is very difficult to achieve :-(. Just out of curiosity, are there tools to look for memory leaks under Linux? At the moment I can only say that a lot of memory blocks are leaked if I just start PPE and close it right away. Bye bye Wolfram |
|
From: Eero P. <epa...@ko...> - 2000-04-30 21:17:58
|
Wolfram Kuss wrote: > > Dave wrote: > > >I spotted a couple leaks in ssgImageLoader. But I think they only occur > >when the load fails and the default texture is used. > > Ok, thanks, I will ignore them. > > But at the moment I am still fighting MSVC > (Microsoft Visual C++) :-(. > The normal way to search for memory leaks with MSVC is very tedious. > MSVC tells you all the memory leaks, but it only gives you the index > of the allocation. So, for example, it says, the things that were > allocated 6. and 23. of all allocations were not freed until the > termination of the program. > Of course it would be much better if you could convince MSVC to > tell you where (filename + linenumber) the allocations were, but this > is very difficult to achieve :-(. > On Windows (and on Unix when Purify was not available). I have used the Boehm garbage collecting malloc library as a leak detector. It is usefull because it only complains from leaked memory areas. It doesn't complain just because you don't free those areas which you allocate in the begining, and use to the end of program run. In addition to the gc-malloc there are tools like heapagent, which you might request for evaluation... Eero |
|
From: Wolfram K. <w_...@rz...> - 2000-04-30 23:14:35
|
Eero, I dont quite understand you. I know there are Purify and Boundschecker and a few other commercial toolkits. AFAIK Boehm is the name of a GC ALGORITHM. If the toolkit you speek about is free, where can one get it? >It is usefull >because it only complains from leaked memory areas. >It doesn't complain just because you don't free >those areas which you allocate in the begining, and use to >the end of program run. Interesting! How does it differentiate between "real leaks" and memory that is used up to the end? > Eero Bye bye, Wolfram. |
|
From: Eero P. <epa...@ko...> - 2000-05-01 06:48:23
|
Wolfram Kuss wrote: > > Eero, > > I dont quite understand you. > I know there are Purify and Boundschecker > and a few other commercial toolkits. > AFAIK Boehm is the name of a GC > ALGORITHM. > See for example: http://reality.sgi.com/boehm/gc.html > If the toolkit you speek about is free, where can one get it? > > >It is usefull > >because it only complains from leaked memory areas. > >It doesn't complain just because you don't free > >those areas which you allocate in the begining, and use to > >the end of program run. > > Interesting! How does it differentiate between > "real leaks" and memory that is used up to the end? > A memory block is live, if there is a valid pointer pointing to it. A pointer is valid if it is a local or global variable or if it is in a valid block. So a whole tree becomes leaked, if you lose its root pointer. The gc library goes through all the variable data areas (+ registers) to find the first level pointers, and then follows the pointers from the memory blocks. Now it is possible that for example an integer or a floating point value looks like a pointer, this causes some leaks to be undetected, but in practise the effect is not too bad. (I think the library tries to avoid allocating blocks with "trivial" bit pattern adresses) I suspect that using custom allocators (STL??) propably decreases the efficiency of the GC/leak detection, but at least STLport can be forced to use malloc. Eero |
|
From: Michael K. <neg...@ea...> - 2000-05-01 07:50:56
|
----- Original Message -----
From: Eero Pajarre <epa...@ko...>
To: <pli...@li...>
Sent: Sunday, April 30, 2000 11:39 PM
Subject: Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall
> A memory block is live, if there is a valid pointer
> pointing to it. A pointer is valid if it
> is a local or global variable or if it is in a valid block.
> So a whole tree becomes leaked, if you lose its
> root pointer.
>
Ok, that almost makes no sense.
A pointer to a local variable is valid only within the local scope of code.
A pointer to a global variable is valid anywhere in the program. A pointer
to any block of memory not within a programs memory is only valid when it
has been assigned through the systems memory management routines, typically
through malloc or new.
A valid ('live') memory block is created through malloc/new, and is no
longer valid when a free/delete is called on it. A problem that I have seen
before is with two pointers pointing to a block of allocated memory. A
routine frees the block and clears one pointer, but the other pointer
remains but it is no longer valid because the system now thinks the block of
ram can be reassigned to another malloc/new call.
Also, a pointer may accidentially point to what can be concidered a "live"
block of ram - one that you have write access to - but that does not mean it
is a valid block of ram that you should be writing to, in all likelyhood
you'll be overwriting part of your program or data.
This is especially a problem with Windows because it doesn't protect any of
the system ram at all, and applications are free to walk all over each
other.
-Michael Kurth
|
|
From: Eero P. <epa...@ko...> - 2000-05-01 08:06:53
|
Michael Kurth wrote:
>
> ----- Original Message -----
> From: Eero Pajarre <epa...@ko...>
> To: <pli...@li...>
> Sent: Sunday, April 30, 2000 11:39 PM
> Subject: Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall
>
> > A memory block is live, if there is a valid pointer
> > pointing to it. A pointer is valid if it
> > is a local or global variable or if it is in a valid block.
> > So a whole tree becomes leaked, if you lose its
> > root pointer.
> >
>
> Ok, that almost makes no sense.
>
Oh, sorry...
>
> A pointer to a local variable is valid only within the local scope of code.
> A pointer to a global variable is valid anywhere in the program. A pointer
> to any block of memory not within a programs memory is only valid when it
> has been assigned through the systems memory management routines, typically
> through malloc or new.
>
I was trying to explain from the garbage collection/leak detection perspective,
where the question is which malloced blocks are still alive. (And blocks
are alive if there are "valid" pointers pointing to them)
>
> A valid ('live') memory block is created through malloc/new, and is no
> longer valid when a free/delete is called on it. A problem that I have seen
> before is with two pointers pointing to a block of allocated memory. A
> routine frees the block and clears one pointer, but the other pointer
> remains but it is no longer valid because the system now thinks the block of
> ram can be reassigned to another malloc/new call.
>
Well if you really use garbage collection (not just for leak detection)
You don't manually free any memory blocks, which solves the
duplicate use problem. This is not always feasible because there are
other resources related to objects in addition to memory.
> Also, a pointer may accidentially point to what can be concidered a "live"
> block of ram - one that you have write access to - but that does not mean it
> is a valid block of ram that you should be writing to, in all likelyhood
> you'll be overwriting part of your program or data.
>
It might be useful to clear all the pointers which are not
pointing to valid data.
Eero
|
|
From: Michael K. <neg...@ea...> - 2000-05-01 08:38:03
|
This is getting rather off topic from the list, unless everyone wants to read about memory management and auto garbage collectors. ----- Original Message ----- From: Eero Pajarre <epa...@ko...> To: <pli...@li...> Sent: Monday, May 01, 2000 12:57 AM Subject: Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall > > Also, a pointer may accidentially point to what can be concidered a "live" > > block of ram - one that you have write access to - but that does not mean it > > is a valid block of ram that you should be writing to, in all likelyhood > > you'll be overwriting part of your program or data. > > > > It might be useful to clear all the pointers which are not > pointing to valid data. > Yes, thank you. The point is that automatic garbage collectors do not work well, in my opinion. Obviously nothing beats paying attention to what you are doing. But turning a blind eye towards your pointers and hoping that a garbage collector "does the right thing" is not a good idea. I would much rather use a program that identified memory leaks during development, and ship an optimized program, than to include garbage collector routines simply because it was easier. Perhaps it's simply different schools of thought. I write 3D applications that need performance. For me, personally, the overhead of garbage collection is not worth it - I would rather identify the flaws in my code and eliminate them. -Michael Kurth |
|
From: Wolfram K. <w_...@rz...> - 2000-05-01 12:06:43
|
Michael wrote: >This is getting rather off topic from the list, unless everyone wants to >read about memory management and auto garbage collectors. True, and now it may even get religious :-/, so lets be carefull. >Obviously nothing beats paying attention to what you are doing. The two obvious disadvantages to the manual way is the huge time amount it takes and the possibilty to create bad bugs, for example, in an esoteric circumstance you might free something that isnt created. I have to admit so, that such errors are very rare. >Perhaps it's simply >different schools of thought. I write 3D applications that need performance. So do I, I wrote a modeler. However, this only sometimes needs to be fast, often it is waiting for the user (I dont redraw the screen if nothing is happening). I use a gc for the objects of some classes. I call the gc in the "OnIdle-routine", which is called when the CPU has nothing better to do. I think this uses very little CPU-time that could be spend on other things, but I never did measurements. Also, it is clear that this approach doesnt work for, say a flight simulator. >For me, personally, the overhead of garbage collection is not worth it - I >would rather identify the flaws in my code and eliminate them. Just out of curiosity: How large is your program, have you eliminated all/most memory leaks and how much time did it take? My answers: 100k lines, no/no, maybe 10%, but I could spend MUCH more. >-Michael Kurth Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2000-05-01 12:06:46
|
Thank you, now I understand. Bye bye, Wolfram. |
|
From: Steve B. <sjb...@ai...> - 2000-05-01 03:03:11
|
Wolfram Kuss wrote: > > Just out of curiosity, are there tools to look for memory leaks under > Linux? None that I use - there is a contraption called 'electric fence' - but I havn't had much luck with it. The problem is to know what is a memory leak and what is genuinely needed 'stuff'. That's very dependent on the application. I think what you are talking about in MSVC is the issue of memory that the application allocated but did not free when the program exited. This (if true) is a M$ peculiarity. "Proper" operating systems know what memory an application used during it's run and automagically reclaim it. What's more interesting is memory allocated at one program milestone and not given back by some other. Eg if I load a model into PPE and then close the window, I'd expect all the memory allocated at the first operation to be free'd again by the other. Anyway, what I've done in the past was to overload the 'operator new' and 'operator delete' in C++ with my own functions that record the address and size of allocated memory when it's "new'ed" and remove that record when the block is deleted. Alongside each record, I remember the value of a simple global variable. New and delete can then call 'malloc' and 'free' so that they work as they should. Now if we were to run PPE up to the point just before (say) doing a 'load model' - and deliberately remove all the records made by operator new calls up to that point...then print out the contents of that table of records when the 'close window' function has completed. That table should contain the addresses *AND* the value of that global variable had when the block was allocated. Theoretically, the table will be empty - but there will be some remaining entries in it if we are leaking. Next, you need to know WHERE those blocks were allocated - and you find that out by littering your code with assignments to that magic global variable. Different values in different places. It's quite easy then to discover that the allocation happened (say) after the global was set to 1234 but before it was again set to 9876. You can use a 'binary chop' technique to eventually discover at which line the allocation of the leak occoured. It's quite easy to modify that overloaded operator new/delete code to also detect attempts to free memory that's already free'd, or various other nastinesses. > At the moment I can only say that a lot of memory blocks are leaked if > I just start PPE and close it right away. I don't consider that a bug though...(although maybe Windoze finds it serious and we have to fix it anyway). -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: <Va...@t-...> - 2000-05-01 07:12:54
|
Steve Baker wrote:
>
> I think what you are talking about in MSVC is the issue of memory
> that the application allocated but did not free when the program
> exited. This (if true) is a M$ peculiarity. "Proper" operating
> systems know what memory an application used during it's run and
> automagically reclaim it.
This isn't true. Even the old DOS freed the memory.
(To get sure I just wrote a program that allocated 1 MB and didn't free
it. As soon as it quit itself the memory was freed)
> > At the moment I can only say that a lot of memory blocks are leaked if
> > I just start PPE and close it right away.
>
> I don't consider that a bug though...(although maybe Windoze finds
> it serious and we have to fix it anyway).
This doesn't really need a fix as it's not a problem - at least not in
our case.
I once reused an old C program (it had the foo( x, y ) int x; float y; {
... } style - argh) that didn't free any memory. If I would have used it
as a standalone program (as it was designed for) it wouldn't have
mattered. But I used it as a part of a bigger program (FGFS) and thus it
was an issue.
As the programming style was that bad that you really couldn't figure
out what each part was doing and anny attemt to fix the leakes resulted
in braking its functionality I replaced all mallocs with my_malloc that
kept track of the allocations and freed themselfs when they weren't
used.
Although it didn't have an leak afterwards I was happy to replace it
later as such an ugly code shouldn't be redistributed.
CU,
Christian
|
|
From: Wolfram K. <w_...@rz...> - 2000-05-01 12:06:41
|
Christian wrote: >Even the old DOS freed the memory. >(To get sure I just wrote a program that allocated 1 MB and didn't free >it. As soon as it quit itself the memory was freed) Thats interesting. Did you really run it under pure DOS or under the shell of Win NT/ Win 95/Win 2000? BTW, does DOS use the MMU? The main disadvantage of the Amiga was that the OS didnt use a MMU, even if one was present. The Amiga taught you about freeing things. >CU, >Christian Bye bye, Wolfram. |
|
From: <Va...@t-...> - 2000-05-01 13:33:51
|
Wolfram Kuss wrote:
>
> Christian wrote:
>
> >Even the old DOS freed the memory.
> >(To get sure I just wrote a program that allocated 1 MB and didn't free
> >it. As soon as it quit itself the memory was freed)
>
> Thats interesting.
> Did you really run it under pure DOS or under the shell of Win NT/
> Win 95/Win 2000?
I've compiled
#include <conio.h>
void main(void)
{
char *c;
c = new char[1000000];
while ( getch() != 'q' )
;
}
as a Win32 console app. When I run it under Win2k I see how about 1.5 MB
RAM 'goes away' and as soon as I hit q it reappears.
Ditto under Win 95 (DOS shell)
I was curious about DOS now so I looked it up. When you asked DOS
directly for RAM (calling the MS-DOS interrupt 0x21(?) with 0x48 in AH)
it would be allocated till the next restart or you'd free it (AH =
0x49). But as the C-compilers allocated the memory on their heap and the
heap got freed when the program terminated you wouldn't get a leak.
So I was wrong about DOS (but not about normal programms that were
running under DOS).
> BTW, does DOS use the MMU?
> The main disadvantage of the Amiga was that the OS didnt use a MMU,
> even if one was present. The Amiga taught you about freeing things.
If the MMU is the posibility of the CPU to lock RAM pages and call an
interrupt/exception if an programm wants to access such a locked page
(e.g. it's locked as the memory content is swapped or used by a
different program) then it's not used by DOS as it's using the real mode
(it only knows the 640 kb). But there are DOS extenders (e.g. EMM32 and
some others) that switch the CPU to the protected mode and make it look
like it's still running the real mode. Only these programs let you
access more than the 640 kb RAM under DOS. You'd tell them that you need
xx byte RAM, they allocate it for you and then you'd give them an
address in the first 640 kb that contains the data and the extender
copies it then to the extended RAM. (This is all of the top of my head;
I could look up the details - but I gues noone really cares anymore)
Thank god that the 16bit days have gone!!
CU,
Christian
|
|
From: Wolfram K. <w_...@rz...> - 2000-05-01 12:06:43
|
Steve wrote: >I think what you are talking about in MSVC is the issue of memory >that the application allocated but did not free when the program >exited. This (if true) is a M$ peculiarity. "Proper" operating >systems know what memory an application used during it's run and >automagically reclaim it. Yes, Windo$ NT does it. >What's more interesting is memory allocated at one program milestone >and not given back by some other. Yes. Under Windo$, there are functions to set up and use Checkpoints: You set a Checkpoint via void _CrtMemCheckpoint( _CrtMemState *state ); and then Dump all the objects that were allocated since a Checkpoint, but not freed via: void _CrtMemDumpAllObjectsSince( const _CrtMemState *state ); But I have to "admit" that looking for memory leaks I almost always use _CrtDumpMemoryLeaks, which lists ALL used memory. (For Windo$ users: _CRTDBG_ALLOC_MEM_DF works for me only sometimes). I think there are not too many used memory blocks of the unproblematic kind. Of course, from the blocks I found now (just starting and stoping the program) half or more might be unproblematic. But it is normally quite easy to put in deletes for these since there is only one place where to free the block. Once I have done that all the unused blocks I find then (for example when I do start PPE - load 3D object - close 3D object - close PPE) are problems. Then you dont have to think about where to put the checkpoints and whether all operations can be "checkpointed". Thinking about it now, it might still well be that using checkpoints is faster. BTW, I looked up the link to Mr Boehm that Eero gave me and he has an additional argument, he writes about "fixing" the unproblematic "leaks": "a potentially useless activity that often triggers large amounts of paging. " >Anyway, what I've done in the past was to overload the 'operator new' >and 'operator delete' Yes, thats what I try just now. >Alongside each record, I remember the >value of a simple global variable. Just out of curiosity: Why dont you remember filename and linenumber of the allocation? >It's quite easy then to discover that the allocation happened (say) >after the global was set to 1234 but before it was again set to 9876. >You can use a 'binary chop' technique [...] Yes, it sounds easy, but tedious. >> At the moment I can only say that a lot of memory blocks are leaked if >> I just start PPE and close it right away. > >I don't consider that a bug though...(although maybe Windoze finds >it serious and we have to fix it anyway). I think its a bug under Win 95. Also, I think "fixing" these "leaks" will make it easyer finding real leaks later on. Well, lets see. One of the reasons I am looking into mem leaks in PPE is that maybe I can learn something I will use in work. Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2000-04-30 20:53:26
|
Steve wrote:
>The second way is a lot more convenient
Yes, I see.
>it should be
>easy to capture a frame of imagery with the bug in it - and then
>reduce that code down to something small enough to understand.
Yes, thats why I thought of doing it ;-).
BTW, is the problem reproducable for you?
With the newest Voodoo-3-drivers, PPE reproducably
shows the problem ("shaded/lighted grid") under Windo$.
Bye bye,
Wolfram
|
×
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