Maybe someone here can help me. I am having problems
with using the memory functions. What happens is I
allocate some memory with no problems, fill the memory
area with data and the problems begin. The problem is
that the memory area that was allocated overlaps the
same area where my local variables are stored and they
get over written. I've used the GlobalAlloc, LocalAlloc,
and HeapAlloc. I get the same results. I have never had
these problems with small 'utility' apps. But this is
a much larger commercial project. Just to get by for
now, I have just set up some rather large buffers but
this is a crude way to get around something that should
not even happen. If it helps, I am using W2K and W98se.
Posted on 2002-03-24 11:45:48 by anon
Did you try VirtualAlloc?

Hmm, I've never had any problem, putting data onto the newly allocated memory(using HeapAlloc...) before. How big is this data?
Posted on 2002-03-24 12:11:39 by stryker
No, I haven't tried VirtualAlloc. The data is variable in size, but
only ranges from 500 - 1800 bytes. I can successfully allocate,
fill, and release the memory. BUT my LOCALS are getting
destroyed. I also noticed that when I use GlobalAlloc with the
GPTR parameter that I get the requested memory, but it
should be filled with zeros. This is not happening either. I was
able to reduce the number of local variables and move the
variable that holds the pointer to the memory to a global variable
and the problem goes away when I allocate 500 to around
1500 bytes. But if I need more, the problem is back. Shouldn't
these functions be using an area of memory that isn't already
being used for something else ?
Posted on 2002-03-24 12:30:01 by anon
But if I need more, the problem is back.
If you need more memory, you can use HeapReAlloc or GlobalReAlloc.
Shouldn't these functions be using an area of memory that isn't already being used for something else ?
Yes, that's true. But I really have no idea why your locals keeps getting destroyed. I've never experienced this before... my locals are still intact even if I use any mem allocation function. :confused:
Posted on 2002-03-24 12:41:11 by stryker
I am calculating in the proc how much memory I need before
I allocate. No need to ReAllocate. It is just really annoying
that these apis are not doing what I think they should. I am
trying to rewrite the proc to use less locals (down to 17 right now)
I will probably have to split it up into 3-4 smaller procs. But why
should I have to do this ?
Posted on 2002-03-24 13:18:19 by anon
3-31-2002
I think your problem may arise from how you are accessing the memory.

if you assign a variable, say memHandle as

memHandle DD ?

Then, if you aassign to memHandle the pointer returned
by the memory allocation call, you must reference the]
memory as
mov esi,memHandle and use esi to access the meory.
If you try to access it as:
mov xyz,memHandle
then what you will get is what is at ebx*4 beyond the
location where memHandle is defined.
At least that is my experience.
Posted on 2002-03-31 19:20:21 by nolpak
What do you mean when saying your locals are destroyed? Trashed
after memory manipulation? - that could be a buffer overflow problem.
Not retaining values between proc invocations? - that's how locals work.

You ought to use Heap* functions instead of local/global* .
In win32, local and globalalloc are the same, and both end up
calling heapalloc - if you don't like the extra parms you have to
pass to heapalloc, write a small wrapper around it.
Posted on 2002-03-31 19:59:56 by f0dder
anon,
I don't knoww hat the problem is but i been concerned about the
Allocate funtions lately and got a lot more to learn.

I founded that sometimes after a proc that you must xor eax, eax. One thing out of place will trash your whole app. so that unwanted results comes in later. You got to take your time and rebuild it all over again piece by piece and Test every bid of it under all conditions before moving ti the next thing and do it over and over again if its important to you. When a proc return use a message box and see what you can see. Also Line your buffers up in order, DD First than DB from the smallest to the biggests.

Stay on it and you will find it. I wish i knew more.Rome was not Builded in a DAy.
Posted on 2002-03-31 21:32:14 by cmax
In my case they got to be at the bottom of it all. At lease one of them had to be or my app simply stop working it took me a whole day to realize that. Just because i stop checking as i build. One new thing screw the whole thing up...
Posted on 2002-03-31 22:10:37 by cmax
f0dder,

With some of the new revisions in our OOP model that are being hacked out, its now very possible to instanciate objects that are only 4 bytes long off the heap.

I understand what the heap is, but im uncertain if it is well adapted for many, very small allocations like 4 bytes. In you opinion would the mem system get grumpy if hundreds of 4 bytes allocations happen in a process???

Thanx for your thoughts..
:alright:
NaN
Posted on 2002-04-17 14:26:55 by NaN

I understand what the heap is, but im uncertain if it is well adapted for many, very small allocations like 4 bytes. In you opinion would the mem system get grumpy if hundreds of 4 bytes allocations happen in a process???


I did a small test once by allocating 500,000 small pieces of memory with HeapAlloc. I varied the sizes from 3 to 20, in this way:
size = 3
while (i<500000)
{
alloc(size)
size++;
if (size=20) size=3;
}
I also wrote to each byte of the allocated memory, to make sure all the memory was actually in use.
It took around 1 sec on my PC (TB1.4, win2K SP2). The memory usage of the program increased by around 20MB, while the real size (the sum of all sizes) was around 5MB. That's quite some overhead but not strange for that amount of allocations.

Thomas
Posted on 2002-04-17 14:36:52 by Thomas
Anon,

You aren't alone. I've experienced that same problem, and using MSVC under Windows98 even. I don't know what the conditions are to make that happen, but it only happens under certain circumstances I'm guessing.

I did exactly what you did; allocated memory, wrote to it, freed it... and my locals were trashed. My code was not errant, I made sure of it. When I debugged the program, sure enough HeapAlloc returned a pointer to the stack. I wrote a letter to Microsoft about it and I haven't received a reply.

Oddly enough when tested the exact same procedure on Win2000 it was fine.
Posted on 2002-04-17 15:54:28 by iblis
anon,
have you created your own heap before alloc'ing memory from it. I was having a problem recently when using a asm dll inside a VB app, and i was debugging the VB app, the debugging environment was doing bizarre things with the heap. So, as soon as i changed the asm dll to create its own heap first, i never had the problems again. Maybe this could help you?
Posted on 2002-04-17 17:28:36 by sluggy
Thanks guys for all the help.
I got called out of town unexpectedly after the first couple of
posts. And this is the first chance I've had to get back to the
board. Even though I had some free time while I was gone and
found the solution, nolpak had the correct answer to my problem.
Thanks Again !
Posted on 2002-04-27 12:09:19 by anon