Thread: Russian Adoption

Originally Posted by Ramil

Speaking in programmer terms, US as an app has accumulated many memory leaks and now the heap is nearly full of interlocked objects. You'll soon need to terminate and debug it. Or even reboot the whole system.

I think, when the app attempts to allocate another portion of memory, and runs across lack of free memory, the exception handler for this kind of thing will just run another process, copy the image into its address space, copy some critical information from the address space of the process having trouble, and the whole thing will start again. If there are some problems with system resources in general, the handler can always terminate a few other processes to get the resources it needs. It does have all the required privileges to do that.

Originally Posted by Eric C.

I think, when the app attempts to allocate another portion of memory, and runs across lack of free memory, the exception handler for this kind of thing will just run another process, copy the image into its address space, copy some critical information from the address space of the process having trouble, and the whole thing will start again. If there are some problems with system resources in general, the handler can always terminate a few other processes to get the resources it needs. It does have all the required privileges to do that.

Offtopic mode
Some questions:
1) As a programmer, do YOU always include exception handlers for the 'out of memory' error? Do you make them so sophisticated that they even try to terminate other processes? Do you handle 'access denied' errors within your 'out of memory' exception handler when it tries to terminate something? And how terminating other processes will help you in getting more virtual address space for your particular application?
2) Ever heard of interlocked (cross-referenced) resources with no accessible valid handlers?

Originally Posted by Ramil

Offtopic mode
Some questions:
1) As a programmer, do YOU always include exception handlers for the 'out of memory' error? Do you make them so sophisticated that they even try to terminate other processes? Do you handle 'access denied' errors within your 'out of memory' exception handler when it tries to terminate something? And how terminating other processes will help you in getting more virtual address space for your particular application?
2) Ever heard of interlocked (cross-referenced) resources with no accessible valid handlers?

1. Speaking about me, I don't ALWAYS do that. But technically it's absolutely real, and not as difficult and sophisticated as you may think. "Access denied" can be handled locally, without an exception handler for that; in addition, ever heard of such things as OS kernel, drivers, R0? If so, you must not have any questions on the further.

2. Specify the kind of resources.

Originally Posted by Eric C.

1. Speaking about me, I don't ALWAYS do that. But technically it's absolutely real, and not as difficult and sophisticated as you may think. "Access denied" can be handled locally, without an exception handler for that; in addition, ever heard of such things as OS kernel, drivers, R0? If so, you must not have any questions on the further.

2. Specify the kind of resources.

OS Kernel (what is it, by the way in your analogy?) would either terminate the buggy application or do nothing. It won't help the USA.exe to start working normally.
2.
COM object A has a reference to COM object B while COM object B has a reference to COM object A. No external references remain. A COM object is released when its reference counter is zero. Since object A still has at least 1 valid reference as well as object B, their reference counters cannot be zeroed. The memory won't be released until the system restarts. That IS called a memory leak. Fairly common among inexperienced programmers. And you cannot clear that memory because OS kernel won't let you. General protection fault on early systems or access denied on newer ones is guaranteed.

Back to the first off-topic. What makes you think that the USA 'developers' had put all these exception handlers before they compiled the whole stuff? What I saw in the past several weeks was more like 'dirty hacking' than even debugging.

Originally Posted by Ramil

OS Kernel (what is it, by the way in your analogy?) would either terminate the buggy application or do nothing. It won't help the USA.exe to start working normally.
2.
COM object A has a reference to COM object B while COM object B has a reference to COM object A. No external references remain. A COM object is released when its reference counter is zero. Since object A still has at least 1 valid reference as well as object B, their reference counters cannot be zeroed. The memory won't be released until the system restarts. That IS called a memory leak. Fairly common among inexperienced programmers. And you cannot clear that memory because OS kernel won't let you. General protection fault on early systems or access denied on newer ones is guaranteed.

Back to the first off-topic. What makes you think that the USA 'developers' had put all these exception handlers before they compiled the whole stuff? What I saw in the past several weeks was more like 'dirty hacking' than even debugging.

1. I meant you could run your code at the same privilege level as the kernel, and use kernel functions as well as accessing kernel objects directly. Then you usually have no problems with doing whatever you wish to any processes, etc.

2. As you might have noticed, I've been talking about a bit more low-level programming than COM programming. After all, you can always tell the OS a certain range of memory is to be freed.

Then, well, speaking in terms of COM programming, such memory leaks do really look lame. But what makes you think the developers are so unexperienced? And why do you think they would use COM model?

Originally Posted by Eric C.

After all, you can always tell the OS a certain range of memory is to be freed.

Sure, things like social security, pensions, aids etc. I'm sure they will.