Re: Memory Leaks in RPG (was: Is RPG 'DEAD")

Hi, David:

See my embedded replies below.

Mark

> David Gibbs wrote:

Rory Hewitt wrote:

But you can't save a pointer in a data queue entry and then send it and
expect it to still work afterwards... :-(

Here's where I'm confused ... what difference does it make WHERE you store a pointer if you can transfer it to another job and have the other job be able to use it?

WHERE you store a pointer makes a HUGE difference in the MI architecture. MI pointers (128-bits, or 16-bytes wide) must be stored on a 16 byte boundary, using the correct MI instructions so the tag bits will be set in memory for those two adjacent 64-bit words.

Put the pointer *IN* a user space: You're storing a value that happens to be a pointer in the user space. The user space doesn't KNOW it's a pointer. That has to be defined, in the program that stores & retrieves the value, that the value is a pointer.
Put the pointer in a data area: Ditto

In theory, you could RSLVSP to get a system pointer to a data area, then SETSPPFP to get a pointer to the first available usable byte within the data area, then store the pointer there. But, I think this only works on a system running at QSECURITY <= 30 or else you get domain violations!

Put the pointer in a data queue: Ditto

There is no guarantee that anything in a message queue will ever be on a 16-byte boundary. And the APIs that store data in a message queue do not use the correct MI instructions to store pointers and set the tags.

Put the pointer in a database field: Ditto.

Same as above; no guarantee of 16-byte alignment and no way to set the tags inside a database field.

My problem with all this is, if you're sending a pointer to non-shared memory (i.e., memory that was just allocated in a program, not created through a user space or shared memory api) to another job, and the other job can access the memory the pointer is referencing ... what's to stop someone from just creating a pointer independent of the other job and accessing arbitrary memory (that may, or may not, be in other jobs).

I think in part what you may be "missing" is, with 16-byte MI pointers to single-level storage, the whole address space IS inherently "shared." That's part of what "single-level storage" means; one very big address space. Of course, if you save an MI pointer that points to a temporary object that gets deleted, any subsequent attempt by another program in the same job or another job will fail with an exception such as "MCH3402 tried to refer to an object that no longer exists" or "MCH3601 pointer not set for location referenced" etc.

In ILE C, you have support for what IBM calls "short pointers" which are 64-bit integers. With these, you can only point to teraspace (which is inherently "temporary" and "goes away" at the end of job.) With recent releases, IBM has made changes to ensure that each job has a unique range of addresses for teraspace, to help ensure that one job cannot access the teraspace of another job. These short pointers are just 64 bit integers, with no tags, etc., so you can directly do address arithmetic on them, and all that nasty stuff that people do on other platforms in C. :-o (Not that I think that this is a "good" idea, mind you.)

Maybe I'm not getting something ... but I sure would like to understand.

Does that help?

david