Re: [BLACKBOX] More memory management problems

From: [at]} <Wojtek>
Date: Tue, 28 Jun 2011 10:29:54 -0400

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

> 4. Run the exported procedure "Do" ten times.
> If works fine.
> 5. Compile it again and unload.
> 6. Try to run "Do" again.
> There is no enough memory.

Modules are not unloaded under BlackBox. Upon unloading, they stay locked
in memory. Thus, if you unload and reload a module ten times, you will end
up with nine inactive copies of the module in memory. The last tenth copy
will be active.

It is not a bug. It is feature. Complete unloading a module could lead to
some Windows pointers still pointing at the code and trying to execute it,
leading to a computer crash. If the code is still there, though inactive
from the BlackBox point of view, the external pointers can execute the
code. The results may not be nice, but hopefully not catastrophic.

Note that all BlackBox pointers are under control and should not point to
the "dead wood". It is the DLL pointers, which are not under BlackBox
control, which can potentially still remember the module after it has been
unloaded. If that happens, the entire Windows system may become unstable.
BlackBox designers decided that such a modest memory leak (yes, it is a
memory leak) is a better choice than occasional destriction of the
operating system.

Also note that loadin/unloading a module is a development facility useful
for debugging. A production software should not unload the modules. It can
zap the variables (the pointers) but it should not zap the code.
Therefore, the above "feature" is not affecting production software. The
development is another matter. The BlackBox developer is supposed to know
his/her tool, including the described behavior.

A more in-depth questions should be addressed to BlackBox designers. In
particular, under what circumstances complete unloading of the module
could destroy the operating system. There must have been such cases.
Otherwise BlackBox designers would not resort to the intentional memory
leak as a solution.

Hope it helps,
Wojtek

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-1173969070_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwID4gNC4gUnVuIHRoZSBleHBvcnRlZCBwcm9jZWR1
cmUgIkRvIiB0ZW4gdGltZXMuXHBhcg0KPiAgICBJZiB3b3JrcyBmaW5lLlxwYXINCj4gNS4gQ29t
cGlsZSBpdCBhZ2FpbiBhbmQgdW5sb2FkLlxwYXINCj4gNi4gVHJ5IHRvIHJ1biAiRG8iIGFnYWlu
LlxwYXINCj4gICAgVGhlcmUgaXMgbm8gZW5vdWdoIG1lbW9yeS5ccGFyDQpccGFyDQpNb2R1bGVz
IGFyZSBub3QgdW5sb2FkZWQgdW5kZXIgQmxhY2tCb3guIFVwb24gdW5sb2FkaW5nLCB0aGV5IHN0
YXkgbG9ja2VkXHBhcg0KaW4gbWVtb3J5LiBUaHVzLCBpZiB5b3UgdW5sb2FkIGFuZCByZWxvYWQg
YSBtb2R1bGUgdGVuIHRpbWVzLCB5b3Ugd2lsbCBlbmRccGFyDQp1cCB3aXRoIG5pbmUgaW5hY3Rp
dmUgY29waWVzIG9mIHRoZSBtb2R1bGUgaW4gbWVtb3J5LiBUaGUgbGFzdCB0ZW50aCBjb3B5XHBh
cg0Kd2lsbCBiZSBhY3RpdmUuXHBhcg0KXHBhcg0KSXQgaXMgbm90IGEgYnVnLiBJdCBpcyBmZWF0
dXJlLiBDb21wbGV0ZSB1bmxvYWRpbmcgYSBtb2R1bGUgY291bGQgbGVhZCB0b1xwYXINCnNvbWUg
V2luZG93cyBwb2ludGVycyBzdGlsbCBwb2ludGluZyBhdCB0aGUgY29kZSBhbmQgdHJ5aW5nIHRv
IGV4ZWN1dGUgaXQsXHBhcg0KbGVhZGluZyB0byBhIGNvbXB1dGVyIGNyYXNoLiBJZiB0aGUgY29k
ZSBpcyBzdGlsbCB0aGVyZSwgdGhvdWdoIGluYWN0aXZlXHBhcg0KZnJvbSB0aGUgQmxhY2tCb3gg
cG9pbnQgb2YgdmlldywgdGhlIGV4dGVybmFsIHBvaW50ZXJzIGNhbiBleGVjdXRlIHRoZVxwYXIN
CmNvZGUuIFRoZSByZXN1bHRzIG1heSBub3QgYmUgbmljZSwgYnV0IGhvcGVmdWxseSBub3QgY2F0
YXN0cm9waGljLlxwYXINClxwYXINCk5vdGUgdGhhdCBhbGwgQmxhY2tCb3ggcG9pbnRlcnMgYXJl
IHVuZGVyIGNvbnRyb2wgYW5kIHNob3VsZCBub3QgcG9pbnQgdG9ccGFyDQp0aGUgImRlYWQgd29v
ZCIuIEl0IGlzIHRoZSBETEwgcG9pbnRlcnMsIHdoaWNoIGFyZSBub3QgdW5kZXIgQmxhY2tCb3hc
cGFyDQpjb250cm9sLCB3aGljaCBjYW4gcG90ZW50aWFsbHkgc3RpbGwgcmVtZW1iZXIgdGhlIG1v
ZHVsZSBhZnRlciBpdCBoYXMgYmVlblxwYXINCnVubG9hZGVkLiBJZiB0aGF0IGhhcHBlbnMsIHRo
ZSBlbnRpcmUgV2luZG93cyBzeXN0ZW0gbWF5IGJlY29tZSB1bnN0YWJsZS5ccGFyDQpCbGFja0Jv
eCBkZXNpZ25lcnMgZGVjaWRlZCB0aGF0IHN1Y2ggYSBtb2Rlc3QgbWVtb3J5IGxlYWsgKHllcywg
aXQgaXMgYVxwYXINCm1lbW9yeSBsZWFrKSBpcyBhIGJldHRlciBjaG9pY2UgdGhhbiBvY2Nhc2lv
bmFsIGRlc3RyaWN0aW9uIG9mIHRoZVxwYXINCm9wZXJhdGluZyBzeXN0ZW0uXHBhcg0KXHBhcg0K
QWxzbyBub3RlIHRoYXQgbG9hZGluL3VubG9hZGluZyBhIG1vZHVsZSBpcyBhIGRldmVsb3BtZW50
IGZhY2lsaXR5IHVzZWZ1bFxwYXINCmZvciBkZWJ1Z2dpbmcuIEEgcHJvZHVjdGlvbiBzb2Z0d2Fy
ZSBzaG91bGQgbm90IHVubG9hZCB0aGUgbW9kdWxlcy4gSXQgY2FuXHBhcg0KemFwIHRoZSB2YXJp
YWJsZXMgKHRoZSBwb2ludGVycykgYnV0IGl0IHNob3VsZCBub3QgemFwIHRoZSBjb2RlLlxwYXIN
ClRoZXJlZm9yZSwgdGhlIGFib3ZlICJmZWF0dXJlIiBpcyBub3QgYWZmZWN0aW5nIHByb2R1Y3Rp
b24gc29mdHdhcmUuIFRoZVxwYXINCmRldmVsb3BtZW50IGlzIGFub3RoZXIgbWF0dGVyLiBUaGUg
QmxhY2tCb3ggZGV2ZWxvcGVyIGlzIHN1cHBvc2VkIHRvIGtub3dccGFyDQpoaXMvaGVyIHRvb2ws
IGluY2x1ZGluZyB0aGUgZGVzY3JpYmVkIGJlaGF2aW9yLlxwYXINClxwYXINCkEgbW9yZSBpbi1k
ZXB0aCBxdWVzdGlvbnMgc2hvdWxkIGJlIGFkZHJlc3NlZCB0byBCbGFja0JveCBkZXNpZ25lcnMu
IEluXHBhcg0KcGFydGljdWxhciwgdW5kZXIgd2hhdCBjaXJjdW1zdGFuY2VzIGNvbXBsZXRlIHVu
bG9hZGluZyBvZiB0aGUgbW9kdWxlXHBhcg0KY291bGQgZGVzdHJveSB0aGUgb3BlcmF0aW5nIHN5
c3RlbS4gVGhlcmUgbXVzdCBoYXZlIGJlZW4gc3VjaCBjYXNlcy5ccGFyDQpPdGhlcndpc2UgQmxh
Y2tCb3ggZGVzaWduZXJzIHdvdWxkIG5vdCByZXNvcnQgdG8gdGhlIGludGVudGlvbmFsIG1lbW9y
eVxwYXINCmxlYWsgYXMgYSBzb2x1dGlvbi5ccGFyDQpccGFyDQpIb3BlIGl0IGhlbHBzLFxwYXIN
CldvanRla1xwYXINClxwYXINClxwYXINCi0tLS1ccGFyDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBh
IG1lc3NhZ2Ugd2l0aCBib2R5ICJTSUdOT0ZGIEJMQUNLQk9YIiB0byBMSVNUU0VSVkBMSVNUUy5P
QkVST04uQ0h9fQB1InAE
----boundary-LibPST-iamunique-1173969070_-_---

Received on Tue Jun 28 2011 - 16:29:54 UTC