Re: Memory being reused by %alloc on second call to program. -- RPG400-L

Comments are inline below...

Hi Bryce,

If I F12 back to the first screen and change my search criteria to
something that shouldn't return results it still does but refined by
whatever I just searched by.

It's unclear to me whether this (the 'refine' stuff quoted above) is
what you intended? Or what you're complaining about?

But, if it's the error, then I'd say it _has_ to be a bug in your code.
I would step through the code to the point where it's starting the
search and see why it's "refining" the criteria further.

No, the 'refine' is not intended. That is part of the error. The subfile
should have only 1 record that I write out as an error message.

If I F3 out of ProgramA then all the memory used by the StoredProc is
released even if I don't do a RCLACTGRP of ProgramA's activation
group.

Sorry, I don't follow this. How do you know all of the memory is
released? Is it because you designed it that way, and have code to
release the memory, and have tested it and it works? Or is this an
oddity that you don't understand? And if it's an oddity, then how do
you know it's happening?

As I said in a previous message this morning, last night I found that the
memory allocations are working just fine as you eluded to below. I'm
doing it dynamically so I'm only using what I need and all the memory has
valid data that I have populated myself. So I think it has to do with the
caller, like I'm not clearing something in my CLI program properly or
something. I'll be looking into this today. I think I assumed it was a
memory issue because I figured that since I'm new to using pointers and
dynamically allocating memory that I had to have done something wrong. But
it seems as though that part is ok.

If I search a second time after doing the full exit by the criteria
that should not return results then it works and returns no results.
(no results could also be a search that is too generic to have good
results, this is handled by the StoredProc).

No idea what you're saying here -- unless you're just saying that it's
working as designed?

In the StoredProc I am doing the following Destroy call, the
DestroyArray() procedure just take a pointer to an array memory

address

and does a dealloc(n) pWholeArray;

pArrayElem = *null;
DestroyArray(pWholeArray);
pWholeArray = *null;

I nulled the pointers for good measure but that didn't do anything.

"Nulling" pointers doesn't deallocate memory... The only reason to
set a pointer to null is to cause the code to error-out if by mistake
you end up using the pointer again. Or perhaps as a flag to tell your
code that the memory isn't allocated.

Yeah, I know that nulling it doesn't deallocate it. I nulled it so that
it would be forced to reassign the pointer value the next time it was
used, just to make sure it was working properly. I had it with and
without the nulls and had the same behavior. This it turns out is because
there wasn't a problem in the code to begin with.

It looks like the second call is doing an %alloc and starting at the

same

memory address as the previous call had done.

Yes? The whole point of calling DEALLOC is so that the memory gets
reused. Why would it surprise you when it _does_ get reused?

So when I %alloc a block the memory already contains the data from
the previous call. How do I handle this?

Are you assuming that the memory will be set to a value before it's
given to you? When you allocate memory, it can have _any_ value in
it... the system makes no promises about what the bytes will contain.

Often times it's set to hex zeroes -- thats probably the most common
value. But there's no promise of that. The memory could have data from

your previous program call, or it could have data that was previously
set by another program in your job, or even parts of the OS. Never
assume the memory you're given will have a particular value.

Most of the time, it doesn't matter. If you're coding a dynamic array,
you have a static variable containing how many elements you've already
allocated. Each time you add a new element, you add 1 to that number.
You increase the memory size accordingly, and then you set the new
element to it's new value. So there's no need to blank out the memory
because you always set it to a value after allocating it.

But if you have a different scenario (and I can't think of one off the
top of my head) where you _do_ need the memory to always start at blanks

or zeroes or something else, you need to set it to that value yourself.

I guess the short version is that I started to second guess what I thought
I knew about this memory stuff. I knew what was going on but assumed I
didn't since I was new to it. The error has to be in the caller and not
the StoredProc. I debugged the StoredProc yesterday and the memory was
correct before returning so I'm going to find the bug in the caller. I
probably didn't clear the accepting array is my guess. This oversight has
sent me and you guys on a ghost hunt. Sorry about that. But I definitely
learned some more stuff.

Thanks for all your help guys.
Bryce

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. ---