plib-devel

[Plib-devel] hpr?

[Philippe C.D. R. <ro...@ia...>]

Hi,

I have just a simple question... how exactly are the hpr angles defined
(what coordinate axis order, which direction)? 

thx,

sweet dreams, Phil
--
Philippe C.D. Robert | http://www.iam.unibe.ch/~robert/

Research Group Computational Geometry and Graphics
Institute of Computer Science and Appl. Mathematics (IAM), Office 205
Neubrueckstrasse 10, CH-3012 Bern Switzerland, phone: +41 31 6313321

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

I wrote:

>"new doesnt accept three parameters".

Ok, I found the problem, it was quite trivial :-/.

For those interested:
While some of the not-freed-blocks I looked at are of
the unproblematic variety, most are slightly problematic leaks that
occur per window.

Ok, I really switch over to the PPE-list now, unless
I should find plib-leaks.


Bye bye,
Wolfram.

RE: [Plib-devel] Nested LOD selectors almost works...

[Vallevand, M. K <Mar...@UN...>]

Nested LOD selectors work for me now.  Thanks for the big
hint, Steve.  

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[<Va...@t-...>]

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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

Thank you, now I understand.

Bye bye,
Wolfram.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

Warning: Of topic (about Windo$ memory
leak detection tools).

Dave wrote:

>I recommend using "NuMega BoundsChecker" with Visual C++.

I have written a modeler we use as an in-house-tool.
I have to admit that I never got rid of all the mem leaks :-(.
Until now I used the tools of Windo$/MSVC to find them.
These are quite ok in some respects, for example,
they find and print all the leaked blocks.
With a bit of effort you can get MSVC to tell you exactly
where the block was allocated. However, this only works
in some instances. I never completely understood, in which.

I have looked at all the memory-leak-detection tools and also
favour BoundsChecker. However, we didnt buy it yet since
I dont have time to use it anyway. For at least 6 month now I only did
things that I had to do until a certain date and fixing leaks doesnt
have a date. I always said, we will buy it when I know I have 
at least two weeks, so that I can learn and use it.
But, if I had two weeks now, I would rather take some 
holidays, I had almost none the last half year.

Maybe now is the moment to buy BoundsChecker.

But I read an example in the MSVC docs
("example 2", this is in the text about _CrtSetDumpClient)
that I hoped would solve my problem quickly. However, it
simply doesnt work :-(.
Its one of those things were succeess always seems
tantalizing (correct word?) near:
When I saw example 2, I thought: That solves my main problem.
When it didnt work, I thought I could use the ideas.
When I saw that PPE as non-MFC-app makes additional problem, I
thought, oh I have the MFC-source, I just need to transfer it.
When it worked for ppe.cxx, I thought, oh its just a matter of
cleaning it up and using the same principle for the other files.
But it doenst work on some other files :-((.

For example, in ppe.cxx:
	PPE_MainGroup =  new AppPluginBase(0,0,0,0);
works. In ppeScene
		clipboard = new ssgRoot () ;
doesnt work. I think it has somehow to doe with the empty parentheses.
In the header I include in everything, there are the lines, adapted
from the MFC-source code:

extern void* /*__cdecl */operator new(size_t nSize, char *
lpszFileName, int nLine);

#define new DEBUG_NEW
#define DEBUG_NEW new(__FILE__, __LINE__)

Probably the last two line could be merged.
The error in ppeScene is
"new doesnt accept three parameters".

Sigh. 

Well, I have to look for info on overloading "new", the online-help is
very sparse about this topic an my C++-books are in the company.

BTW, since I want to use this code only to look for mem leaks,
portability etc is not an issue.

Bye bye,
Wolfram.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Michael K. <neg...@ea...>]

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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Eero P. <epa...@ko...>]

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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Michael K. <neg...@ea...>]

----- 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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[<Va...@t-...>]

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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Eero P. <epa...@ko...>]

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

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Steve B. <sjb...@ai...>]

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)

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Steve B. <sjb...@ai...>]

Wolfram Kuss wrote:
> 
> 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$.

Yep - I see it on Voodoo-1, 2 and 3 under Linux too - but not
on TNT or G200 under Linux or SGI's IRIX OpenGL on one of their
big boxes...strange.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Dave M. <Dav...@dy...>]

I recommend using "NuMega BoundsChecker" with Visual C++.
If you go to:

http://www.numega.com/devcenter/bc.shtml

and click on the "Try It!" button on the left-hand frame
you can get an eval copy.  BoundsChecker tells you exactly
where in the source code the memory leaks are occuring.

--Dave

> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of 
> Wolfram Kuss
> Sent: Sunday, April 30, 2000 1:44 PM
> To: pli...@li...
> Subject: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall
> 
> 
> 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
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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.

Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Eero P. <epa...@ko...>]

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

[Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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

RE: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Dave M. <dp...@ef...>]

> 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.

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Steve B. <sjb...@ai...>]

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)

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

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.

Re: [Plib-devel] Nested LOD selectors almost works...

[Steve B. <sjb...@ai...>]

"Vallevand, Mark K" wrote:
> 
> That's it!
> 
> Yes, all of my tiles share the same origin.

> However, the bounding sphere for each tile is in the
> correct location.
> 
> The solution is what?  Insert a transform branch above the
> LOD Selector?

Above the LOD selector - yes.

> A transform branch in place of the regular branch?

No.

It's a hard call.  Some API's use the center of the
bounding sphere as the point to measure LOD from - but
the problem with that is that SSG auto-computes your
bsphere's for you (sometimes on-the-fly) - and you have
no control of where it ends up.

I *could* (and perhaps in retrospect *should*) have
added a user-specified origin for the LOD - but that
would add an additional transform to the CULL - and
if you are going to do that, you might as well add
an ssgTransform...it's the same amount of math - and
in many cases, the user wants a transform there anyway.

So - well - it's a hard call...and it is the way it is.

You can always spin off a derived class of your own of
course.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)