Why doesnt Dispose() clean the memory address or am I being lazy?

When looking at the memory address of a reference variable before a value is assigned after its been NEW’ed its empty/clean, when I check the same location after its been disposed, the data still shows in the memory location.

Why doesnt Dispose() clean this memory location?

I could probably write my own function to clean it and then dispose, but from a security perspective, wouldnt it be better if dispose() cleaned the memory itself?

After all this is one of the justifications for using .net, in that it cleans up behind you, or is this where everyone comes out and says, dont you clean before disposing, which is an alternative to doing a function?

Because it would slow things down. And most things do not need to be cleared before release. But if yours does, it should not be hard to do.

1 Like

But is that really a factor today with 5Ghz machines, unlike the 8086/286/Pentium days?

If it is done often enough, like in a loop, then yes it can matter.

Particularly when, once disposed, any access to the pointer can (maybe) cause a GPF. So it should never be touched after.

But if it is a security issue, which is more of a concern nowdays, then maybe it should be cleared and overwritten before Dispose.

Hmmmm ads targeted to hackers.

1 Like

So whilst I could say, I’d question if Dispose is in the right place inside a loop, I can see how it could slow the loop up. Problem is, do I assume new() and dispose() is taking place from the same starting pointing in memory, in effect over writing itself which would garbage up the smaller string lengths, but the last part of the longest string would still be visible in memory. If new() starts from the same starting point in memory, a function which notes the longest string could then clean the memory for the longest string once after the loop which would encompass all the other smaller strings. Job done, nice and easy.

However, if new() not starting from the same starting point in memory, then I’m going to have to clean each and every memory space that new() uses, so then it becomes a question of strategy, do I log the memory addresses used, in a queue, and then after the loop sort the queue, and work out the best way to wipe the memory, whilst trying to avoid repeating any wipes/cleans on a memory address.

I think I’ll have to do a class to start logging the memory usage with new() and dispose() and see what it does in different situations and then come up with different ways to efficiently wipe the memory.

I think it would be handy to also log what is left in the memory addresses after dispose() to also see what usable data can be obtained from memory and see just how risky not cleaning memory is. This might also shed some light on how ASLR is working in windows, when its switched on.

Time between new() and then the inevitable wipe/clean will also be a factor as I’d imagine making it as small a window of time between new() and wipe/clean will also be ideal to reduce windows of opportunity for prying “eyes”.

[min 20 character board filler] What do you mean?

MyRef = MyAdvertisement

I still understand what you mean? Are you getting adverts in your browser showing security tools or something. I think you’ll have to walk me through this one… :confused:

I agree if a developer has a desire to protect disposed data left in memory … then they can easily code their own protection to clear it. The RTL should Not be slowed … as noted below there is much more to consider to be “secure”.

New() and Dispose() data are not the only concern. What about all the variables declared in a Procedure? When the Procedure closes that memory will be returned to the OS “as is”. Most will be on the Stack and larger variables on the Heap… then you have File Record Buffers that may have Fields with sensitive data that should be cleared when the file is closed? Data that is THREAD that should be cleaned when the Thread terminates? Static / Global data when the process is closed.

There’s a bunch of stuff about the string stack and other stack stuff in Clarion\docs\AdvancedTopicsReferenceGuide.pdf

I had started a new post but it got flagged and hidden for some obscure reason, but I think ASLR enabled systems pave the way for virtualised code outside of an OS to utilise these ASLR procedures on systems with double or triple digit GB of ram, where the procedures dont ever get overwritten during a session, in much the same way TSR’s used to work in the DOS days, only instead of there being a dos interrupt the virtualised code utilises it. It has many benefits, like its outside of the OS and thus potentially not detected and not constrained by the boundaries an OS places on code that runs on it.

Pretty much all files and programs fit inside a template of sorts, otherwise the things could not run…

We know there is an order to the way a PE file is constructed where some elements are mandatory and some optional, so how hard is it to have some virtualised code reading everything from an ALSR procedure on a system with lots of ram?

PE Format - Win32 apps | Microsoft Docs

TLDR, tiny amounts of ram on a slow cheap value pc could be an unrecognised industry wide security feature!!!

All those page swaps being made by the slow cheap value pc could be negating the need for programmers to clean up behind their code, when using things like New() and Dispose() and virtualised sniffers could have a hard time keeping up with reading whats currently in memory.

[quote=“RichClaCode, post:6, topic:5260”]…
However, if new() not starting from the same starting point in memory, then I’m going to have to clean each and every memory space that new() uses, so then it becomes a question of strategy, do I log the memory addresses used, in a queue, and then after the loop sort the queue, and work out the best way to wipe the memory, whilst trying to avoid repeating any wipes/cleans on a memory address. …
There have been languages that did this kind of thing, put they were so slow and “klunky” that they are no longer used. The time saved was less than the extra time used.

Keep it simple and small. Clear the things necessary right after the New(), or if for security right before the Dispose().

The memory areas can be anywhere in physical memory, even if the program thinks they are right together. See the memory handling inside the CPU.

P.S., More than half of the memory values will usually be written immediatly after the New(), so that clearing is not needed for them. If something is not set right after New(), then it should be cleared.

Clarion automatically clears memory as part of doing a New(). So it basically does a malloc then memset. This does add a tiny overhead but means you don’t need to worry about clearing New() memory before using it.

Not sure that applies to classes. Not sure about nowadays, but early on, they told us to initialize properties in the constructor, as you could not assume what the values would be.

interesting Jeff - I would have thought if you had properties of a class then the default values would apply.


x string(‘abcdef’)
y string(100) ! initialized to spaces
z string(100),auto ! not initialized so potentially whatever is sitting in memory

and then if a class had

xx &string

xx &= new string(100) ! this is initialized to spaces

I’d be pretty surprised if that was not the case - but I have never tested it


Geoff R

To me, this use of heap and stack memory seems like a security nightmare and is clear it was designed for performance first and not security especially considering how slow these computers used to run and the invention of .net which many have bought in to.

I’ve never understood why the Auto attribute exists, other than to force the use of the supposedly “faster” stack memory instead of slower “heap” memory, because at some point some data will be placed in it, and whilst its understandable that variables are initialised (read cleaned), if this tiny overhead of clearing the memory takes place with new(), then why not with dispose()? Not even as an optional parameter in the language function? Stack-based memory allocation - Wikipedia

And as the stack seems to be allocating a big block of memory when a procedure is called, is the OS clearing the memory before its allocated to the stack? From what I see in the debugger and this thread I’d say no the OS is not cleaning memory before its assigned to the procedure and the stack.

And when we look at why .net came into existence, which was to tidy up the memory usage, ie making sure Dispose() was called automatically because so many programmers were not disposing of their variables and to enforce higher standards like a new security model called CAS, even CAS has died a death because its too complicated for programmers!
The end of Code Access Security in Microsoft .NET | Tim Anderson’s IT Writing

Sure, memory leaks can crash programs, but security leaks can put companies out of business and if the business disappears so does the program. Darwinism in action with computer software!

However there might be hope, I dont have any DDR5 ram to test this with, but looking at the command encodings DDR5 SDRAM - Wikipedia I see there is a new write pattern.

The “Write Pattern” command is new for DDR5; this is identical to a write command, but the range is filled in with copies of a one-byte mode register (which defaults to all-zero) instead of individual data.

So has anyone with DDR5 in their computer, seen evidence to suggest the OS is now clearing memory beit uninitialized Auto stack variables or initialised heap variables in Clarion?

I cant find any security settings in windows to force cleaning of memory before its given over to an app for use, but maybe its a bios setting?

Anyone know?