gamedevlists-windows — List for discussing game development on the Windows platform

Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

2002 November 7th
Thursday

Jason,

  Okay, so how DID you get the "process memory consumption"
values that you reported in your C-style comments?

--- Colin
cp...@ea...

Fw: [GD-Windows] memory leak?

[jason z. <dir...@21...>]

VGhhbmsgeW91IGFsbCBmb3Iga2luZCByZXBsaWVzLg0KVGhvdWdoIEknbSBzdGlsbCBhIGJpdCBj
b21mdXNlZCBhYm91dCBpdDotKSAgIA0KRG9lcyBzdGwga2VlcHMgc29tZSBtZW1vcnkgbm90IHJl
bGVhc2VkIGV2ZW4gaWYgYWxsIHN0bCBlbGVtZW50cyBhcmUgYWxyZWFkeSBjbGVhcmVkPyAgSWYg
c28sIA0KSSdsbCB1c2UgcmF3IGFycmF5cyBmb3IgbXkgZHluYW1pYyBvYmplY3RzLg0KDQpCeSB0
aGUgd2F5LCBJJ20gdXNpbmcgTVMgVkMrKyA2LjAuIEkgZG9uJ3Qga25vdyB3aGF0IHZlcnNpb24g
b2Ygc3RsIGl0IHVzZXMuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAi
TWljaGFlbCBGbGFkIiA8TWljaGFlbC5GbGFkQGZhbnRhc3RpYy1yZWFsbXMuY29tPg0KVG86ICJq
YXNvbiB6aGFuZyIgPGRpcmVjdGJveEAyMWNuLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl
ciAwNywgMjAwMiAxMTowNiBQTQ0KU3ViamVjdDogUkU6IFtHRC1XaW5kb3dzXSBtZW1vcnkgbGVh
az8NCg0KDQo+IEhpLA0KPiANCj4gaSBjYW5ub3Qgc2VuZCBtYWlscyB0byB0aGUgbGlzdCAoZXZl
biB0aG91Z2ggSSdtIHJlZ2lzdGVyZWQsIHNvbWUgcHJveHkNCj4gcHJvYmxlbSBvciB3aGF0ZXZl
cikuIFlvdSBjYW4gdGVsbCB0aGUgb3RoZXIgcG9zdGVycywgdGhhdCB5b3UgZGVsZXRlIHRoZQ0K
PiB2ZWN0b3JzIHRoZW1zZWx2ZXMgaW4gdGhlIGxpbmUNCj4gDQo+ICAgICAgICAgZm9yKCBqPTA7
IGo8MjAwOyBqKysgKSAgICBkZWxldGUgcG9ianNbal07DQo+IA0KPiBzbyB3aGF0IHNvbWUgb2Yg
dGhlbSBhcmUgdGVsbGluZyBkb2Vzbid0IG1hdGNoIHlvdXIgc2l0dWF0aW9uLiBUaGUgYmVoYXZp
b3VyDQo+IGFib3V0IGEgdmVjdG9yIG5vdCBmcmVlaW5nIGl0J3MgaW50ZXJuYWwgYWxsb2NhdGVk
IG1lbW9yeSBpcyBvbmx5DQo+IHZhbGlkIGFzIGxvbmcgYXMgdGhlIHZlY3RvciBleGlzdHMuIERl
bGV0aW5nIGEgdmVjdG9yIGZvciBzdXJlIGhhcyB0byBmcmVlDQo+IGl0cyBjb250ZW50cywgaWYg
aXQgZG9lc24ndCBkbyBzbywgaXQncyBmb3Igc3VyZSBhIGJ1ZyBhbmQgbm90IHRoZQ0KPiBkZWZh
dWx0IGJlaGF2aW91ciAoYXQgbGVhc3QgaW4gdGVybXMgb2YgYW4gYWxsb2NhdG9yOjpmcmVlKQ0K
PiANCj4gICBNaWNoYWVsDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
RnJvbTogamFzb24gemhhbmcgW21haWx0bzpkaXJlY3Rib3hAMjFjbi5jb21dDQo+ID4gU2VudDog
VGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDAyIDEwOjQ4DQo+ID4gVG86IE1pY2hhZWwgRmxhZA0K
PiA+IFN1YmplY3Q6IFJlOiBbR0QtV2luZG93c10gbWVtb3J5IGxlYWs/DQo+ID4NCj4gPg0KPiA+
IFRoZSBTVEwgaXMgZnJvbSBNUyB2YysrLiAgIFRoYW5rIHlvdS4NCj4gPg0KPiA+IC0tLS0tIE9y
aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiBGcm9tOiAiTWljaGFlbCBGbGFkIiA8TWljaGFlbC5G
bGFkQGZhbnRhc3RpYy1yZWFsbXMuY29tPg0KPiA+IFRvOiAiamFzb24gemhhbmciIDxkaXJlY3Ri
b3hAMjFjbi5jb20+DQo+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDAyIDU6MDkg
UE0NCj4gPiBTdWJqZWN0OiBSRTogW0dELVdpbmRvd3NdIG1lbW9yeSBsZWFrPw0KPiA+DQo+ID4N
Cj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IHdoaWNoIFNUTCBpbXBsZW1lbnRhdGlvbj8gQUZBSUsg
U1RMIFBvcnQgYW5kIHRoZSBTR0kgb25lIGZvciBpbnN0YW5jZQ0KPiA+ID4gdXNlIGFuIG9wdGlt
aXplZCBhbGxvY2F0b3Igd2hpY2ggdXNlcyBhIHNwZWNpYWwgYWxsb2NhdGlvbiBhbGdvIGZvcg0K
PiA+ID4gc21hbGwgYmxvY2tzIChlLmcuIGJsb2NrcyA8MTI4IG9yIDwyNTZieXRlcykuIFRoZSBh
bGdvIG5ldmVyIHJlYWxseQ0KPiA+ID4gZnJlZXMgc21hbGwgYmxvY2tzIGJ1dCBzdG9yZXMgdGhl
bSBpbiBhIGxpc3Qgb2YgZnJlZSBzbWFsbCBibG9ja3MNCj4gPiA+IChsaXN0cyBmb3Igc2l6ZS1t
dWx0aXBsZXMgb2YgNCBmb3IgaW5zdGFuY2UpIGFuZCBhbGxvY3MgZmlyc3QgY2hlY2sNCj4gPiA+
IHRoZXNlIGxpc3RzIChoYXZlIGEgbG9vayBhdCBTdHJvdXN0cnVwcyBCb29rIFRoZSBDKysgTGFu
Z3VhZ2UgZm9yDQo+ID4gPiBhIGV4YW1wbGUgaW1wbGVtZW50YXRpb24gb2Ygc3VjaCBhIG1lbW9y
eSBhbGxvY2F0b3IpLg0KPiA+ID4NCj4gPiA+IFdpdGgga2luZCByZWdhcmRzLA0KPiA+ID4NCj4g
PiA+IE1pY2hhZWwgRmxhZA0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBGYW50YXN0aWMgUmVhbG1z
IEludGVyYWN0aXZlIEdtYkggLSBHZXJtYW55DQo+ID4gPiBQaG9uZTogKzQ5ICgwKTcxMjEgLyA5
NDcgOTk5IDANCj4gPiA+IEZheDogICArNDkgKDApNzEyMSAvIDk0NyA5OTkgOQ0KPiA+ID4NCj4g
PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogZ2FtZWRldmxp
c3RzLXdpbmRvd3MtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ID4gPiA+IFttYWlsdG86
Z2FtZWRldmxpc3RzLXdpbmRvd3MtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XU9uIEJlaGFs
ZiBPZg0KPiA+ID4gPiBqYXNvbiB6aGFuZw0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1i
ZXIgMDcsIDIwMDIgNzozNQ0KPiA+ID4gPiBUbzogZ2FtZWRldmxpc3RzLXdpbmRvd3NAbGlzdHMu
c291cmNlZm9yZ2UubmV0DQo+ID4gPiA+IFN1YmplY3Q6IFtHRC1XaW5kb3dzXSBtZW1vcnkgbGVh
az8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gSGkgZm9sa3MsDQo+ID4gPiA+ICAgICBJIGhh
ZCBwcm9ncmFtZWQgYW4gb2JqZWN0IGNsYXNzIHdoaWNoIGhhcyBzdGQ6OnZlY3RvciBhcyBpdHMN
Cj4gPiA+ID4gbWVtYmVyLiAgQXMgdGhlIG9iamVjdHMNCj4gPiA+ID4gYXJlIGNyZWF0ZWQgYW5k
IGRlbGV0ZWQgaW4gcnVudGltZSwgIHRoZSBtZW1vcnkgb2YgdGhlIHByb2Nlc3MNCj4gPiA+ID4g
YmVjb21lcyBiaWdnZXIuIFRoZQ0KPiA+ID4gPiBmb2xsb3dpbmcgaXMgYSBzaW1wbGlmaWVkIHZl
cnNpb24sIGluIHdoaWNoIG1lbW9yeSBncm93aW5nIHNlZW1zDQo+ID4gPiA+IG5vIGhhcm0gc2lu
Y2UgdGhlIG1lbW9yeQ0KPiA+ID4gPiBpcyByZWxlYXNlZCB0byBzeXN0ZW0gb25jZSB0aGUgcHJv
Y2VzcyBleGl0cy4NCj4gPiA+ID4gICAgQnV0IGZvciByZWFsIHByb2dyYW0sIG1lbW9yeSBncm93
aW5nIGluIHJ1bnRpbWUgd2l0aCBvYmplY3RzDQo+ID4gPiA+IGNyZWF0aW5nIGFuZCBkZXN0cm95
aW5nIGlzDQo+ID4gPiA+IG5vdCBhY2NlcHRhYmxlLg0KPiA+ID4gPg0KPiA+ID4gPiAjaW5jbHVk
ZSA8dmVjdG9yPg0KPiA+ID4gPg0KPiA+ID4gPiBzdHJ1Y3QgVGVzdE9iag0KPiA+ID4gPiB7DQo+
ID4gPiA+ICAgICBzdGQ6OnZlY3RvcjxmbG9hdD4gYXJyYXk7DQo+ID4gPiA+IH07DQo+ID4gPiA+
DQo+ID4gPiA+IGludCBtYWluKCkNCj4gPiA+ID4gew0KPiA+ID4gPiAgICAgLypjaGVjayB0aGUg
bWVtb3J5IHRoaXMgcHJvY2VzcyBjb25zdW1lLiBJdCBpcyA2MjRLQiBvbg0KPiA+IG15IGNvbXB1
dGVyKi8NCj4gPiA+ID4gICAgIGZsb2F0IGJvYXJkID0gMDsNCj4gPiA+ID4NCj4gPiA+ID4gICAg
IGZvciggaW50IGk9MDsgaTw1OyBpKysgKQ0KPiA+ID4gPiAgICAgew0KPiA+ID4gPiAgICAgICAg
IFRlc3RPYmogKnBvYmpzWzIwMF07DQo+ID4gPiA+ICAgICAgICAgaW50IGo7DQo+ID4gPiA+ICAg
ICAgICAgZm9yKCBqPTA7IGo8MjAwOyBqKysgKSBwb2Jqc1tqXSA9IG5ldyBUZXN0T2JqOw0KPiA+
ID4gPg0KPiA+ID4gPiAgICAgICAgIGludCBrOw0KPiA+ID4gPiAgICAgICAgIGZvciggaz0wOyBr
PDEwMDsgaysrICkNCj4gPiA+ID4gICAgICAgICB7DQo+ID4gPiA+ICAgICAgICAgICAgIGZvcigg
aj0wOyBqPDIwMDsgaisrICkgcG9ianNbal0tPmFycmF5LnB1c2hfYmFjayggYm9hcmQgKTsNCj4g
PiA+ID4gICAgICAgICAgICAgZm9yKCBqPTA7IGo8MjAwOyBqKysgKSBwb2Jqc1tqXS0+YXJyYXku
Y2xlYXIoKTsNCj4gPiA+ID4gICAgICAgICB9DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgZm9y
KCBqPTA7IGo8MjAwOyBqKysgKSAgICBkZWxldGUgcG9ianNbal07DQo+ID4gPiA+ICAgICB9DQo+
ID4gPiA+DQo+ID4gPiA+ICAgICAvKmNoZWNrIHRoZSBtZW1vcnkgYWdhaW4uICBJdCBpcyA2NTJL
QiBub3cqLw0KPiA+ID4gPiAgICAgcmV0dXJuIDA7DQo+ID4gPiA+IH0NCj4gPiA+ID4gTrG1U7Ky
dXl4PU6yTnZ0ei2dc7Z6p3a6fnr9bq2tpi3TGXVTwqNqerJUvradsra6fno/s1Oyca56U/62o1S+
tp2wDQo+ID4gPiA+ID+yp6J5gbdTcnuuP64NCj4gPiA+DQo+ID4gPg0KPiA+DQo+IA0KPiANCg==

Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

2002 November 7th
Thursday

I wrote my own routines for allocation and free,
which essentially wrap malloc() and free(), just
to get a rough idea of total memory use -- and
detect some leaks.

Let's say I override the "new" and "delete"
operators, too.  (Something I haven't tried yet)
Can I get STL to use the overrides without 
explicitly mentioning an allocator in all of
my STL uses?

Or is it more reliable to just go though the
code and change things like vector<T> to
vector<T,MyAllocator>, and thing like
vector<string> to 
vector<string<MyAllocator>,MyAllocator>.
(NOTE: I have no idea if that's how you
change the allocator for "string"!
I remember something like "basic_string"
making life interesting for me once.)

--- Colin
cp...@ea...

RE: [GD-Windows] memory leak?

[Andrew G. <ag...@cl...>]

Yeap, the importance of having identical (modulo hideous CRT bugs) memory
allocation behaviour across platforms can't be understated. Also if you're
working on consoles then a custom memory manager is pretty much vital, even
small degrees of fragmentation can really hurt you.


Andy @ 
Climax Brighton 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 07 November 2002 19:15
> To: gam...@li...
> Subject: RE: [GD-Windows] memory leak? 
> 
> 
> > I've found tools like Purify to be more thorough than 
> > anything I could write myself, however.
> 
> BoundsChecker et. al. do provide some facilities such as API
> verification and stack corruption that are hard to roll on your own
> transparently, but writing your own still gives you a lot more
> flexibility than going off-the-shelf.  And mine just 
> automatically works
> with all my projects and doesn't incur any special startup tasks or
> overhead.
> 
> More importantly, writing your own will give you a solution that's
> cross-platform and works in any environment.  If you have a 
> leak that's
> manifesting on Linux but not Windows then it can be kind of 
> frustrating
> trying to find it.
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] memory leak?

[Brian H. <bri...@py...>]

> I've found tools like Purify to be more thorough than 
> anything I could write myself, however.

BoundsChecker et. al. do provide some facilities such as API
verification and stack corruption that are hard to roll on your own
transparently, but writing your own still gives you a lot more
flexibility than going off-the-shelf.  And mine just automatically works
with all my projects and doesn't incur any special startup tasks or
overhead.

More importantly, writing your own will give you a solution that's
cross-platform and works in any environment.  If you have a leak that's
manifesting on Linux but not Windows then it can be kind of frustrating
trying to find it.

Brian

Re: [GD-Windows] memory leak?

[Rich <leg...@xm...>]

In article <000001c2868f$f0b82340$6e01a8c0@HOOKDELL220>,
    "Brian Hook" <bri...@py...>  writes:

> > A good memory tracking subsystem is important to any decent-size 
> > project.
> 
> This can't be emphasized enough.

I've used these before, and they are handy.

I've found tools like Purify to be more thorough than anything I could
write myself, however.  These days I would just buy a copy of Purify
instead of writing my own memory allocation tool.  I think it even has
the debug breakpoint stuff you mentioned.
-- 
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>

RE: [GD-Windows] memory leak?

[Brian H. <bri...@py...>]

> A good memory tracking subsystem is important to any decent-size 
> project.

This can't be emphasized enough.  It takes a couple hours, if that, to
write a decent memory allocation tracker.  This will help identify leaks
in your own program very quickly, as they occur, and also has the handy
side effect of letting you trap on certain allocations, check for guard
bytes being modified, and also gives you an indication of your run time
memory requirements (not including stack, statics and globals).

Brian

RE: [GD-Windows] memory leak?

[Jon W. <hp...@mi...>]

> [A] Best guess:  You are doing "new" and "delete"
> on a regular "struct", instead of a "class".
> This may simply allocate raw bytes with the
> same size as your structure.  This means that

Not true.

#include <stdio.h>

struct bar { 
  bar() { puts("bar::bar()"); }
  ~bar() { puts("bar::~bar()"); }
};

struct foo {
  bar b;
};

int
main()
{
  foo * f = new foo[ 1 ];
  delete[] f;
  return 0;
}

This prints the appropriate constructor/destructor. In fact, the
auto-generated assignment operator will also do the right thing. 
However, if you implement your own assignment operator, it will 
have to do all that manually.

> [B] Some kind of DLL page(s) just wasn't (weren't)
> added to your process until you touched the
> "new" and "delete" operators (implemented as

Possible.

> [C] The C run-time library malloc() and free()
> are "lazy" when it comes to returning memory
> pages back to the OS -- for efficiency.

This is usually the case. Similarly, the OS may be lazy about 
returning pages from your general pool, even if you have marked 
them as uninteresting. Hence, the Task Manager's "memory" display 
is often a little bit misleading.

A good memory tracking subsystem is important to any decent-size 
project.

Cheers,

				/ h+

RE: [GD-Windows] memory leak?

[David N. <dno...@mi...>]

> [C] Lazy C runtime library is hanging on to
>   memory after all allocations are freed
>   just because it is likely you'll want
>   more memory again in the near future
>   -- and maybe it can avoid expensive
>   system calls.
>=20

STL hangs on to memory that it pools. It will reuse it later. And it
will be properly freed when the CRT shuts down (and it will be freed,
doesn't rely on the process cleanup). This was bothering as I couldn't
tell what were real leaks from STL 'leaks', however, there was a way of
either forcing the stl to free or making the leak detector work. I'll
dig up my home code tonight and post an answer.

David

Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

2002 November 7th
Thursday

Okay, I just wasn't sure if "new" and "delete" on a
"struct" would, in practice, work the same way as
with a "class".  Let's just say I avoid pointless risks,
and I'd use "class" instead of "struct" if the 
object in question had member variables that
required construction.

The code sample with the "memory leak" calls
std::vector::clear() -- not "erase()".
Sure, capacity is never reduced by "erase()",
but "clear()" (with VC++ .NET implementation)
makes the same single "_Tidy()" call as the
destructor -- which allegedly really does
free memory after calling the destructor on
all elements.

In any case, I don't see how (assuming Jason's
STL implementation isn't broken) STL has
anything to do with the "memory leak",
since Jason's code is doing "new" and 
"delete" on objects that happen to CONTAIN
an STL container.  It's not about capacity
of vectors never shrinking; the whole vector
should be destroyed!

So, I'm still vaguely suspicious about the
vector destructor actually being called when
Jason does the delete on a TestObj -- but I
am totally willing to believe that "struct"
and "class" are essentially treated the
same by the compiler (apart from the very
minor default "public" vs "private"
distinctions).

Maybe it's worthwhile to examine the other
two possibilities I proposed:
[B] Process memory grows due to reading in
  more code (DLL or EXE) because new 
  code/functions were called;
[C] Lazy C runtime library is hanging on to
  memory after all allocations are freed
  just because it is likely you'll want
  more memory again in the near future
  -- and maybe it can avoid expensive
  system calls.

But perhaps the real issue is the method
of measurement of "process (memory) consumption",
and the interpretation of that quantity.

--- Colin
cp...@ea...

RV: [GD-Windows] memory leak?

[Diego D. <br...@te...>]

I don't think so, the only diference between struct and class is the
default access level -- private in classes, public in structs. As Ivan
said, don't expect a std::vector to be decreasing its capacity, the
standard only requires the erase methods to call destructors and
invalidate the items in the array. This is what it says:

 iterator erase(iterator position);
  iterator erase(iterator first, iterator last);

  Effects:
    Invalidates all the iterators and references after the point of  the
    erase.
  Complexity:
    The  destructor of T is called the number of times equal to the num-
    ber of the elements erased, but the  assignment  operator  of  T  is
    called  the  number  of times equal to the number of elements in the
    vector after the erased elements.

In fact, if std::vector reallocated the data on erase, it wont meet the
complexity requeriments set by the standard. Check other containers in
the STL if you really need that.



> De: gam...@li...
> [mailto:gam...@li...] En 
> nombre de Colin Fahey
> Enviado el: Thursday, November 07, 2002 2:05 PM
> Para: GDWindows
> Asunto: Re: [GD-Windows] memory leak?

[..]
> [A] Best guess:  You are doing "new" and "delete"
> on a regular "struct", instead of a "class".
> This may simply allocate raw bytes with the
> same size as your structure.  This means that
> the "std::vector<float> array" member is NOT
> CONSTRUCTED, but is simply given space to exist.
> Even though C++ compilers may implement
> "struct" as "class", I don't know if "new" will
> CONSTRUCT members of a "struct".
> Anyhow, I'm guessing that the "delete" calls
> aren't calling the destructor of the "array"
> object within the "struct" (TestObj).

[..]


Diego

Re: [GD-Windows] memory leak?

[Mickael P. <mpo...@ed...>]

Colin Fahey wrote:
> [...]
> I have three wild guesses about what you might be
> observing:
> 
> [A] Best guess:  You are doing "new" and "delete"
> on a regular "struct", instead of a "class".
> This may simply allocate raw bytes with the
> same size as your structure.  This means that
> the "std::vector<float> array" member is NOT
> CONSTRUCTED, but is simply given space to exist.
> Even though C++ compilers may implement
> "struct" as "class", I don't know if "new" will
> CONSTRUCT members of a "struct".
> Anyhow, I'm guessing that the "delete" calls
> aren't calling the destructor of the "array"
> object within the "struct" (TestObj).
> 
> EXPERIMENT:
> Change the "struct" to "class" (TestObj), and
> just add "public:".  Don't make any other changes.
>
> [...]

There is absolutely no difference in C++ between class
and struct, except the fact that class are private by
default, and struct are public by default.

Construction/destruction behavior should be the same.


    Mickael Pointier

Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

2002 November 7th
Thursday


For Visual Studio .NET, the <vector> header has:

  void clear()
  {
  _Tidy();
  }

The destructor has an identical implementation:

  ~vector()
  {
  _Tidy();
  }

The vector method _Tidy() supposedly frees all
storage.

Okay, even if this is not the case on your STL
implementation, I don't think this is the cause
of your "leak", since you apparently allocate
and delete objects that CONTAIN vector objects.
Regardless of vector's "shrinking" policy, destruction
of the vector object itself should free associated
storage.

I have three wild guesses about what you might be
observing:

[A] Best guess:  You are doing "new" and "delete"
on a regular "struct", instead of a "class".
This may simply allocate raw bytes with the
same size as your structure.  This means that
the "std::vector<float> array" member is NOT
CONSTRUCTED, but is simply given space to exist.
Even though C++ compilers may implement 
"struct" as "class", I don't know if "new" will
CONSTRUCT members of a "struct".
Anyhow, I'm guessing that the "delete" calls
aren't calling the destructor of the "array"
object within the "struct" (TestObj).

EXPERIMENT:
Change the "struct" to "class" (TestObj), and
just add "public:".  Don't make any other changes.


[B] Some kind of DLL page(s) just wasn't (weren't)
added to your process until you touched the
"new" and "delete" operators (implemented as
malloc() and free(), but enhanced with 
calls to constructor and destructor functions).
So, maybe your program won't grow any more than
the observed 28KB even when you "new" and
"delete" 2000000 of your objects instead of
200.

[C] The C run-time library malloc() and free()
are "lazy" when it comes to returning memory
pages back to the OS -- for efficiency.
So, your process appears to remain bigger
even after you free all allocated memory.
The C run-time library may have tuned rules
to decide when to ask for more memory from
the OS, and when it seems obvious from the
passage of time that pages aren't likely to
be used again and can be returned to the OS.
I'll bet the CRT is trying to avoid system
calls in a big way.

I actually have no idea what might be going
on, but it would be interesting to change your
loop counters to 200000 iterations instead of
200, and see if the process growth is anything
other than 28KB.

If not, it would be interesting to reduce the
loop total to "1" iteration (a single "new"
and "delete").  If this is still 28KB, then
it appears that [B] explains everything!

Also, it would be interesting to wait a couple
of minutes, running other miscellaneous applications
that might demand lots of memory, and check 
the process size of your test application.
If it shrinks, then [C] is the likely answer.

--- Colin
cp...@ea...

RE: [GD-Windows] GetAsyncKeyState / DI

[Tom F. <to...@mu...>]

Unfortunately they don't capture some of the stranger keys in terribly
useful ways.

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: Andy Glaister [mailto:an...@mi...]
> Sent: 06 November 2002 21:26
> To: Ignacio Casta=F1o; gam...@li...
> Subject: RE: [GD-Windows] GetAsyncKeyState / DI
>=20
>=20
> Why use GetAsyncKeyState or DirectInput for typical keyboard=20
> handling at all?
>=20
> You are going to get WM_KEYUP and WM_KEYDOWN messages all the=20
> time - it's pretty easy to store these results in an array -=20
> then you can have perfect up/down/pressed notifications that=20
> do not have any input focus issues.
>=20
> Andy.
>=20
> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]=20
> Sent: Wednesday, November 06, 2002 10:10 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] GetAsyncKeyState / DI
>=20
>=20
> Wayne Coles wrote:=20
> > Unfortunately the remarks section inside the MSDN=20
> documentation go on=20
> > to
> > say:
> >=20
> > "Although the least significant bit of the return value indicates=20
> > whether the key has been pressed since the last query, due to the=20
> > pre-emptive multitasking nature of Windows, another application can =

> > call GetAsyncKeyState and receive the "recently pressed"=20
> bit instead=20
> > of your application. The behavior of the least significant=20
> bit of the=20
> > return value is retained strictly for compatibility with 16-bit=20
> > Windows applications (which are non-preemptive) and should not be=20
> > relied upon."
> >=20
> > So you can't really rely upon this bit being set correctly.
>=20
> Exactly, that's what I meant, the interface of=20
> GetAsyncKeyState is nice, but the real behaviour is not.
>=20
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
> _______________________________________________________________
> Yahoo! Messenger
> Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis!=20
> Desc=E1rgalo ya desde http://messenger.yahoo.es
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm=20
> Tungsten T handheld. Power & Color in a compact size!=20
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Gamedevlists-windows mailing list =
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm=20
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

Re: [GD-Windows] memory leak?

[Ivan-Assen I. <as...@ha...>]

>     I had programed an object class which has std::vector as its member.  As the objects
> are created and deleted in runtime,  the memory of the process becomes bigger. The 
> following is a simplified version, in which memory growing seems no harm since the memory
> is released to system once the process exits.  
>    But for real program, memory growing in runtime with objects creating and destroying is 
> not acceptable.


In most STL implementations, vectors only grow in capacity
and never shrink. 

This is perfectly OK for 90% of the cases, and can be easily
circumvented if you are aware of it in the other 10%.

[GD-Windows] memory leak?

[jason z. <dir...@21...>]

SGkgZm9sa3MsDQogICAgSSBoYWQgcHJvZ3JhbWVkIGFuIG9iamVjdCBjbGFzcyB3aGljaCBoYXMg
c3RkOjp2ZWN0b3IgYXMgaXRzIG1lbWJlci4gIEFzIHRoZSBvYmplY3RzDQphcmUgY3JlYXRlZCBh
bmQgZGVsZXRlZCBpbiBydW50aW1lLCAgdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBiZWNvbWVz
IGJpZ2dlci4gVGhlIA0KZm9sbG93aW5nIGlzIGEgc2ltcGxpZmllZCB2ZXJzaW9uLCBpbiB3aGlj
aCBtZW1vcnkgZ3Jvd2luZyBzZWVtcyBubyBoYXJtIHNpbmNlIHRoZSBtZW1vcnkNCmlzIHJlbGVh
c2VkIHRvIHN5c3RlbSBvbmNlIHRoZSBwcm9jZXNzIGV4aXRzLiAgDQogICBCdXQgZm9yIHJlYWwg
cHJvZ3JhbSwgbWVtb3J5IGdyb3dpbmcgaW4gcnVudGltZSB3aXRoIG9iamVjdHMgY3JlYXRpbmcg
YW5kIGRlc3Ryb3lpbmcgaXMgDQpub3QgYWNjZXB0YWJsZS4NCg0KI2luY2x1ZGUgPHZlY3Rvcj4N
CiANCnN0cnVjdCBUZXN0T2JqDQp7DQogICAgc3RkOjp2ZWN0b3I8ZmxvYXQ+IGFycmF5Ow0KfTsN
CiANCmludCBtYWluKCkNCnsNCiAgICAvKmNoZWNrIHRoZSBtZW1vcnkgdGhpcyBwcm9jZXNzIGNv
bnN1bWUuIEl0IGlzIDYyNEtCIG9uIG15IGNvbXB1dGVyKi8NCiAgICBmbG9hdCBib2FyZCA9IDA7
DQoNCiAgICBmb3IoIGludCBpPTA7IGk8NTsgaSsrICkNCiAgICB7DQogICAgICAgIFRlc3RPYmog
KnBvYmpzWzIwMF07DQogICAgICAgIGludCBqOw0KICAgICAgICBmb3IoIGo9MDsgajwyMDA7IGor
KyApIHBvYmpzW2pdID0gbmV3IFRlc3RPYmo7DQogDQogICAgICAgIGludCBrOw0KICAgICAgICBm
b3IoIGs9MDsgazwxMDA7IGsrKyApDQogICAgICAgIHsNCiAgICAgICAgICAgIGZvciggaj0wOyBq
PDIwMDsgaisrICkgcG9ianNbal0tPmFycmF5LnB1c2hfYmFjayggYm9hcmQgKTsNCiAgICAgICAg
ICAgIGZvciggaj0wOyBqPDIwMDsgaisrICkgcG9ianNbal0tPmFycmF5LmNsZWFyKCk7DQogICAg
ICAgIH0NCiANCiAgICAgICAgZm9yKCBqPTA7IGo8MjAwOyBqKysgKSAgICBkZWxldGUgcG9ianNb
al07DQogICAgfQ0KDQogICAgLypjaGVjayB0aGUgbWVtb3J5IGFnYWluLiAgSXQgaXMgNjUyS0Ig
bm93Ki8NCiAgICByZXR1cm4gMDsNCn0NCg==

RE: [GD-Windows] GetAsyncKeyState / DI

[Andy G. <an...@mi...>]

Why use GetAsyncKeyState or DirectInput for typical keyboard handling at =
all?

You are going to get WM_KEYUP and WM_KEYDOWN messages all the time - =
it's pretty easy to store these results in an array - then you can have =
perfect up/down/pressed notifications that do not have any input focus =
issues.

Andy.

-----Original Message-----
From: Ignacio Casta=F1o [mailto:cas...@ya...]=20
Sent: Wednesday, November 06, 2002 10:10 AM
To: gam...@li...
Subject: RE: [GD-Windows] GetAsyncKeyState / DI


Wayne Coles wrote:=20
> Unfortunately the remarks section inside the MSDN documentation go on=20
> to
> say:
>=20
> "Although the least significant bit of the return value indicates=20
> whether the key has been pressed since the last query, due to the=20
> pre-emptive multitasking nature of Windows, another application can=20
> call GetAsyncKeyState and receive the "recently pressed" bit instead=20
> of your application. The behavior of the least significant bit of the=20
> return value is retained strictly for compatibility with 16-bit=20
> Windows applications (which are non-preemptive) and should not be=20
> relied upon."
>=20
> So you can't really rely upon this bit being set correctly.

Exactly, that's what I meant, the interface of GetAsyncKeyState is nice, =
but the real behaviour is not.


Ignacio Casta=F1o
cas...@ya...


_______________________________________________________________
Yahoo! Messenger
Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis!=20
Desc=E1rgalo ya desde http://messenger.yahoo.es


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm=20
Tungsten T handheld. Power & Color in a compact size! =
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Gamedevlists-windows mailing list =
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

RE: [GD-Windows] GetAsyncKeyState / DI

[<cas...@ya...>]

Wayne Coles wrote: 
> Unfortunately the remarks section inside the MSDN documentation go on to
> say:
> 
> "Although the least significant bit of the return value indicates whether
> the key has been pressed since the last query, due to the pre-emptive
> multitasking nature of Windows, another application can call
> GetAsyncKeyState and receive the "recently pressed" bit instead of your
> application. The behavior of the least significant bit of the return value
> is retained strictly for compatibility with 16-bit Windows applications
> (which are non-preemptive) and should not be relied upon."
> 
> So you can't really rely upon this bit being set correctly.

Exactly, that's what I meant, the interface of GetAsyncKeyState is nice, but
the real behaviour is not.


Ignacio Castaño
cas...@ya...


_______________________________________________________________
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

Re: [GD-Windows] GetAsyncKeyState / DI

[Pierre T. <p.t...@wa...>]

> "Although the least significant bit of the return value indicates whether
> the key has been pressed since the last query, due to the pre-emptive
> multitasking nature of Windows, another application can call
> GetAsyncKeyState and receive the "recently pressed" bit instead of your
> application. The behavior of the least significant bit of the return value
> is retained strictly for compatibility with 16-bit Windows applications
> (which are non-preemptive) and should not be relied upon."
>
> So you can't really rely upon this bit being set correctly.

Ooooh that's nasty !

Maybe it's time for me to update my MSDN since that paragraph is *not*
included in mine.

...and actually that might explains a lot of weird things I've seen
recently..... Sigh.

Many thanks, very useful piece of info.......................

Pierre

RE: [GD-Windows] GetAsyncKeyState / DI

[Wayne C. <wc...@re...>]

> // If the function succeeds, the return value specifies whether the key
> was
> pressed since the last call to GetAsyncKeyState, and whether
> // the key is currently up or down. If the most significant bit is set,
> the
> key is down, and if the least significant bit is set, the key
> // was pressed after the previous call to GetAsyncKeyState.
> 
> Isn't it just the same as what you did ?
> 
> >     if( Key[i].state&KEY_BEGIN )
> >         Key[i].state ^= KEY_BEGIN;
> 
> Or simply :
> Key[i].state &= ~KEY_BEGIN;

Unfortunately the remarks section inside the MSDN documentation go on to
say:

"Although the least significant bit of the return value indicates whether
the key has been pressed since the last query, due to the pre-emptive
multitasking nature of Windows, another application can call
GetAsyncKeyState and receive the "recently pressed" bit instead of your
application. The behavior of the least significant bit of the return value
is retained strictly for compatibility with 16-bit Windows applications
(which are non-preemptive) and should not be relied upon."

So you can't really rely upon this bit being set correctly.

Wayne
-Virus scanned and cleared ok

Re: [GD-Windows] GetAsyncKeyState / DI

[Pierre T. <p.t...@wa...>]

> The thing I don't like about GetAsyncKeyState is that you can loose keys
> pressed between frames.

Right, that's my main problem with it.

> It also doesn't give you information about when a
> key has been pressed or released.

Here, I'm not sure you're right :

// If the function succeeds, the return value specifies whether the key was
pressed since the last call to GetAsyncKeyState, and whether
// the key is currently up or down. If the most significant bit is set, the
key is down, and if the least significant bit is set, the key
// was pressed after the previous call to GetAsyncKeyState.

Isn't it just the same as what you did ?

key is down => KEY_ON
key is up => KEY_OFF
key was pressed after the previous call => KEY_BEGIN

...maybe KEY_END is missing, unless the LSB is correctly set in the KEY_OFF
case as well...


>     if( Key[i].state&KEY_BEGIN )
>         Key[i].state ^= KEY_BEGIN;

Or simply :
Key[i].state &= ~KEY_BEGIN;


P.

Re: [GD-Windows] GetAsyncKeyState / DI

[<cas...@ya...>]

The thing I don't like about GetAsyncKeyState is that you can loose keys
pressed between frames. It also doesn't give you information about when a
key has been pressed or released. However, testing keys by polling is
usually cleaner and easier than sending and processing events.

Instead of that I use a different polling mechanism. I associate three
different flags to each key:

enum {
    KEY_OFF = 0x00,
    KEY_ON = 0x01,
    KEY_BEGIN = 0x02,
    KEY_END = 0x04
};

And test them like this:

if( GetKey( KEY_SPACE ) )  fire();
if( GetKey( KEY_CONSOLE )&KEY_BEGIN ) console.toggle();
if( GetKey( KEY_ESCAPE )&KEY_END ) exit();

When a key down is received I set the key state to KEY_BEGIN|KEY_ON, and
when key up, I toggle the the KEY_END flag.

On every frame I update the key states like this:

for each key {
    if( Key[i].state&KEY_BEGIN )
        Key[i].state ^= KEY_BEGIN;
    if( Key[i].state&KEY_END )
        Key[i].state = KEY_OFF;
}

So, it's possible to recieve up and down messages in the same frame without
loosing the key pulsation.

You can put that on top of any input mechanism, WM_KEY events, direct input
buffers, SDL keyboard events, etc. Whatever you feel more confortable with.

Actually all that is mixed with my action mapping code, so instead of
testing for keys I test for actions, and that makes the whole thing much
more intuitive.


Ignacio Castaño
cas...@ya...


Pierre Terdiman wrote:
> > DI can give you buffered input, which has it's benefits.
>
> What is it, exactly ? Do you mean it records (say) pressed keys in the
> background, maybe in another thread, and gives all pressed keys since last
> query ? Actually it would be a very good reason to switch to DI.
>
> >Are you really adverse to using it ....
>
> No, I was just wondering if it was worth it. Nothing against the idea.
>
> Pierre


_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

RE: [GD-Windows] GetAsyncKeyState / DI

[Grills, J. <jg...@so...>]

Yup, DirectInput can give you all the key strokes, even when another app has
focus.  It basically treats the keyboard like a big digital button board --
you don't get any repeat messages.  I believe it plugs in at the driver
level, so it doesn't use a thread.  It can be a bit of a trick to get rid of
keystrokes you don't, especially those entered while debugging the
application.  

j

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Tuesday, November 05, 2002 3:12 PM
To: gam...@li...
Subject: Re: [GD-Windows] GetAsyncKeyState / DI


> DI can give you buffered input, which has it's benefits.

What is it, exactly ? Do you mean it records (say) pressed keys in the
background, maybe in another thread, and gives all pressed keys since last
query ? Actually it would be a very good reason to switch to DI.

>Are you really adverse to using it ....

No, I was just wondering if it was worth it. Nothing against the idea.

Pierre



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

Re: [GD-Windows] GetAsyncKeyState / DI

[Pierre T. <p.t...@wa...>]

> DI can give you buffered input, which has it's benefits.

What is it, exactly ? Do you mean it records (say) pressed keys in the
background, maybe in another thread, and gives all pressed keys since last
query ? Actually it would be a very good reason to switch to DI.

>Are you really adverse to using it ....

No, I was just wondering if it was worth it. Nothing against the idea.

Pierre

RE: [GD-Windows] GetAsyncKeyState / DI

[Andrew G. <ag...@cl...>]

Depends what your app is, what you want to achieve and so on.

Directinput is good for treating the keyboard like a giant joypad, but lousy
for textinput. You'll probably get lower latency with regards to mouse
tracking but whether that's something that's critical to you can depend.

Andy @ 
Climax Brighton

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 05 November 2002 12:14
> To: gam...@li...
> Subject: [GD-Windows] GetAsyncKeyState / DI
> 
> 
> Say I have an app that just uses "simple" inputs :
> - standard mouse messages
> - GetAsyncKeyState() for keys
> 
> i.e. no special devices such as force feedback joysticks, etc 
> (or even, no
> joystick at all)
> 
> Is there any advantages to use DirectInput instead ? What would be the
> benefits in my case ? (It looks to me like it wouldn't be 
> better, but maybe
> I'm misssing something)
> 
> Pierre
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>