GlobalAlloc returning "not enough memory"

NTDEV
1

We’re stuck using GlobalAlloc to allocate memory in certain circumstances
because of our need for compatibility with MS’s Structured Storage. One of
our apps is now occasionally getting an error value of 8
(ERROR_NOT_ENOUGH_MEMORY) when it calls GlobalAlloc. TaskMan reports that
the app does indeed have excessive allocated memory (which indicates a
memory leak) but the total amount is nowhere near physical memory - let
alone ALL of virtual memory. Meanwhile, calls to malloc continue to operate
properly, and other processes are running without problems.

So… what causes error value 8 within GlobalAlloc? According to MSDN, the
system will simply allocate more pages as the heap runs low. Since there’s
plenty of physical (and thus) memory available, why would the system refuse
to allocate the memory?

Thanks in advance for any guidance…

RLH

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

As I remember it, the panic button in response to an error like this was to
call GlobalCompact and try the GlobalAlloc again. GlobalCompact’s job was to
reorder pages in memory, moving unlocked pages up toward the top of the
memory address space, and potentially making more room in the middle of the
address space.

I used to be a GlobalAlloc whiz, but I haven’t followed it’s history since I
got malloc back.

According to the latest MSDN I have:
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read-write access that cannot be accessed by other
processes. "

That tells me that GlobalAlloc is probably not allocating from the system
pool, but is instead allocating from your process’s default heap. But that
supposition doesn’t jive with your observation that malloc succeeds where
GlobalAlloc fails. In any case, if GlobalCompact doesn’t do it, I’d try
expanding your process’s heap anyway (call GetProcessHeap, then
HeapReAlloc), and trying the GlobalAlloc again.

Please let me know if that helps.

ERX

-----Original Message-----
From: Richard Hartman [mailto:xxxxx@realresume.com]
Sent: Wednesday, January 17, 2001 2:44 PM
To: NT Developers Interest List
Subject: [ntdev] GlobalAlloc returning “not enough memory”

We’re stuck using GlobalAlloc to allocate memory in certain
circumstances
because of our need for compatibility with MS’s Structured
Storage. One of
our apps is now occasionally getting an error value of 8
(ERROR_NOT_ENOUGH_MEMORY) when it calls GlobalAlloc. TaskMan
reports that
the app does indeed have excessive allocated memory (which indicates a
memory leak) but the total amount is nowhere near physical
memory - let
alone ALL of virtual memory. Meanwhile, calls to malloc
continue to operate
properly, and other processes are running without problems.

So… what causes error value 8 within GlobalAlloc? According
to MSDN, the
system will simply allocate more pages as the heap runs low.
Since there’s
plenty of physical (and thus) memory available, why would the
system refuse
to allocate the memory?

Thanks in advance for any guidance…

RLH

You are currently subscribed to ntdev as: xxxxx@mediasite.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

> So… what causes error value 8 within GlobalAlloc? According to MSDN, the

system will simply allocate more pages as the heap runs low. Since there’s

The heap size is specified in the EXE’s header - SizeOfHeapReserve and
SizeOfHeapCommit.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

At 03:38 PM 01/17/2001 -0500, you wrote:

As I remember it, the panic button in response to an error like this was to
call GlobalCompact and try the GlobalAlloc again. GlobalCompact’s job was to
reorder pages in memory, moving unlocked pages up toward the top of the
memory address space, and potentially making more room in the middle of the
address space.

From the current version of MSDN:

“The GlobalCompact function is obsolete. It is provided only for
compatibility with 16-bit versions of Windows. It has no meaning in the
32-bit environment.”

A good idea, though. I’m amazed such a function ever existed - it’s almost
an admission of poor memory management design in the operating system.

Any more ideas?

Thanks!

RLH

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

No.
The MSVC documentation says:
"The GlobalCompact function is obsolete. This function is provided only for
compatibility with 16-bit versions of Windows. It has no meaning in the
32-bit environment.
"

----- Original Message -----
From: “Steadle, Eric”
To: “NT Developers Interest List”
Sent: Wednesday, January 17, 2001 11:38 PM
Subject: [ntdev] RE: GlobalAlloc returning “not enough memory”

> As I remember it, the panic button in response to an error like this was
to
> call GlobalCompact and try the GlobalAlloc again. GlobalCompact’s job was
to
> reorder pages in memory, moving unlocked pages up toward the top of the
> memory address space, and potentially making more room in the middle of
the
> address space.
>
> I used to be a GlobalAlloc whiz, but I haven’t followed it’s history since
I
> got malloc back.
>
> According to the latest MSDN I have:
> "Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
> committed pages with read-write access that cannot be accessed by other
> processes. "
>
> That tells me that GlobalAlloc is probably not allocating from the system
> pool, but is instead allocating from your process’s default heap. But that
> supposition doesn’t jive with your observation that malloc succeeds where
> GlobalAlloc fails. In any case, if GlobalCompact doesn’t do it, I’d try
> expanding your process’s heap anyway (call GetProcessHeap, then
> HeapReAlloc), and trying the GlobalAlloc again.
>
> Please let me know if that helps.
>
>
>
> ERX
>
>
>
> > -----Original Message-----
> > From: Richard Hartman [mailto:xxxxx@realresume.com]
> > Sent: Wednesday, January 17, 2001 2:44 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] GlobalAlloc returning “not enough memory”
> >
> >
> > We’re stuck using GlobalAlloc to allocate memory in certain
> > circumstances
> > because of our need for compatibility with MS’s Structured
> > Storage. One of
> > our apps is now occasionally getting an error value of 8
> > (ERROR_NOT_ENOUGH_MEMORY) when it calls GlobalAlloc. TaskMan
> > reports that
> > the app does indeed have excessive allocated memory (which indicates a
> > memory leak) but the total amount is nowhere near physical
> > memory - let
> > alone ALL of virtual memory. Meanwhile, calls to malloc
> > continue to operate
> > properly, and other processes are running without problems.
> >
> > So… what causes error value 8 within GlobalAlloc? According
> > to MSDN, the
> > system will simply allocate more pages as the heap runs low.
> > Since there’s
> > plenty of physical (and thus) memory available, why would the
> > system refuse
> > to allocate the memory?
> >
> > Thanks in advance for any guidance…
> >
> > RLH
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@mediasite.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

> A good idea, though. I’m amazed such a function ever existed - it’s almost

an admission of poor memory management design in the operating system.

A remnant of Win16 with its memory defragmentation.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

7

>"The GlobalCompact function is obsolete. It is provided only for

compatibility with 16-bit versions of Windows. It has no meaning in the
32-bit environment."

A good idea, though. I’m amazed such a function ever existed - it’s almost
an admission of poor memory management design in the operating system.

Under Windows 2.x, memory management was all handled in software. There was
no memory mapping hardware. GlobalAlloc returned a opaque handle to a
memory block, and then you would do GlobalLock to get an actual pointer to
the memory.

Over time, memory would get fragmented, and you would periodically call
GlobalCompact to reorder memory. Handles you had didn’t change.

As a side note, memory STILL get’s fragmented, it’s just there is nothing
you can do about now. I haven’t measured it in some years, but in the past
had often seen cases where the 32-bit heap took twice as much memory as the
allocated blocks in it. Worst case allocation/freeing patterns can get a
LOT worse. I guess everybody decided it was ok for our apps to consume
twice as much memory as they really needed.

A big advantage of a language that uses compacting garbage collection
(typically like Java/Smalltalk/Visual Basic/others) is this fragmentation
is handled. Under C++/C, memory fragments, sometimes badly, and there is
nothing you can really do about it.

Also note that taking some random bunch of code it’s not possible to
predict what the end stable memory utilization factor will be, it will
depend on an interaction between the allocation/freeing patterns and the
specific memory allocator algorithms (which may be changed by the OS or
language developer). It’s also possible it will not be stable, and memory
consumption will grow forever.

Kernel memory also can get fragmented over time.

Probably the difference now vs. 16-bit Windows days is we commonly have 128
MByte instead of 0.5 MByte total available. In those days, loosing 0.25
MByte to fragmentation would have been unthinkable. Losing 64 MByte now
slows down you system, but generally not to a crawl.

  • Jan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com