Re: [BLACKBOX] More memory management problems

From: [at]} <Wojtek>
Date: Tue, 28 Jun 2011 11:36:05 -0400

----boundary-LibPST-iamunique-893090906_-_-
Content-type: text/plain

I am not a Windows programmer (other than BlackBox, of course), so I do
not know whether the following thought is relevant. Think of "memory
fragmentation". It may be so that BlackBox is requestion a large
continuous memory chunk from the operating system. In case such a chunk is
not available, the allocation request will fail despite plenty of memory
being around.

This is certainly an issue on MMU-less embedded systems, like the ones I
am currently developing. It should not be an issue under the virtual
memory hardware, which supposedly can join together disjoint blocks of
physical memory. Windows presumably is a virtual memory system, so the
memory fragmentation should not happen. So the trail may not be relevant.
But maybe it is relevant? Here my expertise stops.

I think that further progress will require (a) an expert opinion; (b)
running BlackBox under Windows debugger and examining internal variables;
or (c) instrumention BlackBox with traps and let the built-in Trap viewer
tell you what is going on.

W.

> As as second thought, I think that Wojtek's explanation does not apply.
> Consider the following experiment.
>
> start Windows XP, start Task manager:
>
> physical memory: total 3145196 K, available 2725404 K
> Run BlackBox:
>
> physical memory available 2720632 K, BlackBox memory usage 7604 K
> Compile "PrivLarge" module:
>
> physical memory available 2721464 K, BlackBox memory usage 8076 K
>
> Run "Do" procedure first time:
>
> physical memory available 2487748 K, BlackBox memory usage 242920 K
>
> Run "Do" procedure second time:
>
> physical memory available 2487748 K, BlackBox memory usage 242920 K (no
> change)
>
> Run "Do" procedure third time:
>
> physical memory available 2491160 K, BlackBox memory usage 242916 K (4 K
> less)
>
> Compile "PrivLarge" again and unload it:
>
> physical memory available 2726200 K, BlackBox memory usage 8540 K
> BlackBox released 240 MB after unloading the module.
>
> Try to run "Do" procedure results in "not enough memory":
>
> physical memory available 2726472 K, BlackBox memory usage 8540 K (no
> change)
>
> This shows that unloading actually removes the module from memory,
>
> leaving BlackBox with only 8.5 MB occupied.
>
> But after that, there is plenty of available memory (far more than "2
> GB/process" limit),
>
> but BlackBox thinks there is "not enough memory" to run a 240 MB module.
>
> Looks like BlackBox has a limit on allocating more than ~300 MB since the
> startup,
>
> REGARDLESS of memory being released in between.
>
> Sinisa

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-893090906_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIEkgYW0gbm90IGEgV2luZG93cyBwcm9ncmFtbWVy
IChvdGhlciB0aGFuIEJsYWNrQm94LCBvZiBjb3Vyc2UpLCBzbyBJIGRvXHBhcg0Kbm90IGtub3cg
d2hldGhlciB0aGUgZm9sbG93aW5nIHRob3VnaHQgaXMgcmVsZXZhbnQuIFRoaW5rIG9mICJtZW1v
cnlccGFyDQpmcmFnbWVudGF0aW9uIi4gSXQgbWF5IGJlIHNvIHRoYXQgQmxhY2tCb3ggaXMgcmVx
dWVzdGlvbiBhIGxhcmdlXHBhcg0KY29udGludW91cyBtZW1vcnkgY2h1bmsgZnJvbSB0aGUgb3Bl
cmF0aW5nIHN5c3RlbS4gSW4gY2FzZSBzdWNoIGEgY2h1bmsgaXNccGFyDQpub3QgYXZhaWxhYmxl
LCB0aGUgYWxsb2NhdGlvbiByZXF1ZXN0IHdpbGwgZmFpbCBkZXNwaXRlIHBsZW50eSBvZiBtZW1v
cnlccGFyDQpiZWluZyBhcm91bmQuXHBhcg0KXHBhcg0KVGhpcyBpcyBjZXJ0YWlubHkgYW4gaXNz
dWUgb24gTU1VLWxlc3MgZW1iZWRkZWQgc3lzdGVtcywgbGlrZSB0aGUgb25lcyBJXHBhcg0KYW0g
Y3VycmVudGx5IGRldmVsb3BpbmcuIEl0IHNob3VsZCBub3QgYmUgYW4gaXNzdWUgdW5kZXIgdGhl
IHZpcnR1YWxccGFyDQptZW1vcnkgaGFyZHdhcmUsIHdoaWNoIHN1cHBvc2VkbHkgY2FuIGpvaW4g
dG9nZXRoZXIgZGlzam9pbnQgYmxvY2tzIG9mXHBhcg0KcGh5c2ljYWwgbWVtb3J5LiBXaW5kb3dz
IHByZXN1bWFibHkgaXMgYSB2aXJ0dWFsIG1lbW9yeSBzeXN0ZW0sIHNvIHRoZVxwYXINCm1lbW9y
eSBmcmFnbWVudGF0aW9uIHNob3VsZCBub3QgaGFwcGVuLiBTbyB0aGUgdHJhaWwgbWF5IG5vdCBi
ZSByZWxldmFudC5ccGFyDQpCdXQgbWF5YmUgaXQgaXMgcmVsZXZhbnQ/IEhlcmUgbXkgZXhwZXJ0
aXNlIHN0b3BzLlxwYXINClxwYXINCkkgdGhpbmsgdGhhdCBmdXJ0aGVyIHByb2dyZXNzIHdpbGwg
cmVxdWlyZSAoYSkgYW4gZXhwZXJ0IG9waW5pb247IChiKVxwYXINCnJ1bm5pbmcgQmxhY2tCb3gg
dW5kZXIgV2luZG93cyBkZWJ1Z2dlciBhbmQgZXhhbWluaW5nIGludGVybmFsIHZhcmlhYmxlcztc
cGFyDQpvciAoYykgaW5zdHJ1bWVudGlvbiBCbGFja0JveCB3aXRoIHRyYXBzIGFuZCBsZXQgdGhl
IGJ1aWx0LWluIFRyYXAgdmlld2VyXHBhcg0KdGVsbCB5b3Ugd2hhdCBpcyBnb2luZyBvbi5ccGFy
DQpccGFyDQpXLlxwYXINClxwYXINCj4gQXMgYXMgc2Vjb25kIHRob3VnaHQsIEkgdGhpbmsgdGhh
dCBXb2p0ZWsncyBleHBsYW5hdGlvbiBkb2VzIG5vdCBhcHBseS5ccGFyDQo+IENvbnNpZGVyIHRo
ZSBmb2xsb3dpbmcgZXhwZXJpbWVudC5ccGFyDQo+XHBhcg0KPiBzdGFydCBXaW5kb3dzIFhQLCBz
dGFydCBUYXNrIG1hbmFnZXI6XHBhcg0KPlxwYXINCj4gICBwaHlzaWNhbCBtZW1vcnk6IHRvdGFs
IDMxNDUxOTYgSywgYXZhaWxhYmxlIDI3MjU0MDQgS1xwYXINCj4gUnVuIEJsYWNrQm94OlxwYXIN
Cj5ccGFyDQo+ICAgcGh5c2ljYWwgbWVtb3J5IGF2YWlsYWJsZSAyNzIwNjMyIEssIEJsYWNrQm94
IG1lbW9yeSB1c2FnZSA3NjA0IEtccGFyDQo+IENvbXBpbGUgIlByaXZMYXJnZSIgbW9kdWxlOlxw
YXINCj5ccGFyDQo+ICAgcGh5c2ljYWwgbWVtb3J5IGF2YWlsYWJsZSAyNzIxNDY0IEssIEJsYWNr
Qm94IG1lbW9yeSB1c2FnZSA4MDc2IEtccGFyDQo+XHBhcg0KPiBSdW4gIkRvIiBwcm9jZWR1cmUg
Zmlyc3QgdGltZTpccGFyDQo+XHBhcg0KPiAgIHBoeXNpY2FsIG1lbW9yeSBhdmFpbGFibGUgMjQ4
Nzc0OCBLLCBCbGFja0JveCBtZW1vcnkgdXNhZ2UgMjQyOTIwIEtccGFyDQo+XHBhcg0KPiBSdW4g
IkRvIiBwcm9jZWR1cmUgc2Vjb25kIHRpbWU6XHBhcg0KPlxwYXINCj4gICBwaHlzaWNhbCBtZW1v
cnkgYXZhaWxhYmxlIDI0ODc3NDggSywgQmxhY2tCb3ggbWVtb3J5IHVzYWdlIDI0MjkyMCBLIChu
b1xwYXINCj4gY2hhbmdlKVxwYXINCj5ccGFyDQo+IFJ1biAiRG8iIHByb2NlZHVyZSB0aGlyZCB0
aW1lOlxwYXINCj5ccGFyDQo+ICAgcGh5c2ljYWwgbWVtb3J5IGF2YWlsYWJsZSAyNDkxMTYwIEss
IEJsYWNrQm94IG1lbW9yeSB1c2FnZSAyNDI5MTYgSyAoNCBLXHBhcg0KPiBsZXNzKVxwYXINCj5c
cGFyDQo+IENvbXBpbGUgIlByaXZMYXJnZSIgYWdhaW4gYW5kIHVubG9hZCBpdDpccGFyDQo+XHBh
cg0KPiAgIHBoeXNpY2FsIG1lbW9yeSBhdmFpbGFibGUgMjcyNjIwMCBLLCBCbGFja0JveCBtZW1v
cnkgdXNhZ2UgODU0MCBLXHBhcg0KPiAgIEJsYWNrQm94IHJlbGVhc2VkIDI0MCBNQiBhZnRlciB1
bmxvYWRpbmcgdGhlIG1vZHVsZS5ccGFyDQo+XHBhcg0KPiBUcnkgdG8gcnVuICJEbyIgcHJvY2Vk
dXJlIHJlc3VsdHMgaW4gIm5vdCBlbm91Z2ggbWVtb3J5IjpccGFyDQo+XHBhcg0KPiAgIHBoeXNp
Y2FsIG1lbW9yeSBhdmFpbGFibGUgMjcyNjQ3MiBLLCBCbGFja0JveCBtZW1vcnkgdXNhZ2UgODU0
MCBLIChub1xwYXINCj4gY2hhbmdlKVxwYXINCj5ccGFyDQo+IFRoaXMgc2hvd3MgdGhhdCB1bmxv
YWRpbmcgYWN0dWFsbHkgcmVtb3ZlcyB0aGUgbW9kdWxlIGZyb20gbWVtb3J5LFxwYXINCj5ccGFy
DQo+IGxlYXZpbmcgQmxhY2tCb3ggd2l0aCBvbmx5IDguNSBNQiBvY2N1cGllZC5ccGFyDQo+XHBh
cg0KPiBCdXQgYWZ0ZXIgdGhhdCwgdGhlcmUgaXMgcGxlbnR5IG9mIGF2YWlsYWJsZSBtZW1vcnkg
KGZhciBtb3JlIHRoYW4gIjJccGFyDQo+IEdCL3Byb2Nlc3MiIGxpbWl0KSxccGFyDQo+XHBhcg0K
PiBidXQgQmxhY2tCb3ggdGhpbmtzIHRoZXJlIGlzICJub3QgZW5vdWdoIG1lbW9yeSIgdG8gcnVu
IGEgMjQwIE1CIG1vZHVsZS5ccGFyDQo+XHBhcg0KPiBMb29rcyBsaWtlIEJsYWNrQm94IGhhcyBh
IGxpbWl0IG9uIGFsbG9jYXRpbmcgbW9yZSB0aGFuIH4zMDAgTUIgc2luY2UgdGhlXHBhcg0KPiBz
dGFydHVwLFxwYXINCj5ccGFyDQo+IFJFR0FSRExFU1Mgb2YgbWVtb3J5IGJlaW5nIHJlbGVhc2Vk
IGluIGJldHdlZW4uXHBhcg0KPlxwYXINCj4gU2luaXNhXHBhcg0KXHBhcg0KXHBhcg0KLS0tLVxw
YXINClRvIHVuc3Vic2NyaWJlLCBzZW5kIGEgbWVzc2FnZSB3aXRoIGJvZHkgIlNJR05PRkYgQkxB
Q0tCT1giIHRvIExJU1RTRVJWQExJU1RTLk9CRVJPTi5DSH19AGw5EB0
----boundary-LibPST-iamunique-893090906_-_---

Received on Tue Jun 28 2011 - 17:36:05 UTC