GlancePlus fatal error. Errno: 12 (Not enough space)

[Rich Powell]

GlancePlus has been working fine for me without any issues until I run a tt_instance loop inside an adviser script. When I execute a script like this, I get the following error after GlancePlus crashes:

== Fatal Nums Error == C.03.35.00 06/15/01 ==
User: rwerhun(/dev/pts/ta) Date: Wed Mar 3 12:31:35
File: db.C Line: 452 Product id: Gpm
System: spmw530a B.11.00 9000/800
Errno: 12 (Not enough space)

Abort signal 6 possible new bad allocation error
== End of Error Msg =============================

Thanks in advance for your time,

Rich

[A. Clay Stephenson]

The first thing that I would look for is a runaway loop; iff you are satisfied that your code will not enter an endless loop then you are probably hitting the maxdsiz kernel limit. It's also possible that it's maxssiz but I'm going to make the silly assumption that since the error specifically mentions "allocation" that them there programmers do not overuse the stack. In extremely rare cimcumstances you could be limited by swap space but I would suspect: endless loop, maxdsiz --- in that order.

[Sridhar Bhaskarla]

Hi RIch,

I would also take a look at the swap space utilization.

swapinfo -t and see if the total utilization is near 100%.

-Sri

[Jeff Schussele]

Hi Rich,

Did it create a core file when it aborted?
If it did run
file core
to possibly get some more detail on just why it aborted.

Rgds,
Jeff

[Bill Hassell]

from /usr/include/sys/errno.h:
define ENOMEM 12 /* Not enough core */

from man 2 errno:
[ENOMEM] Not enough space. During a system call such as exec(), brk(), fork(),or sbrk(), a program asks for more space than the system is able to supply. This may not be a temporary condition; the maximum space size is a system parameter. The error can also occur if there is not enough swap space during a fork().

In other words, this is a memory issue. Most likely, all virtual memory has been used (swapinfo -tm). You can add some swap space temporarily with swapon.

[James Randall]

As I work with Rich....I'll see if I can answer a few of the questions you are posting here:

#1) - No swap size is not getting even close to max.

#2) - No CORE file is generated when this condition occurs.

#3) - We do have NUMEROUS transactions on these systems....So it might be blowing out the maxdsiz.

James Randall

[Jeff Schussele]

Hi James,

You *are* looking down in the reservation area of a swapinfo -tam command I assume...
There *must* be space available in the reservation table before *any* process can start.

Rgds,

[Bill Hassell]

This may also be a shared memory problem too. Glance and midaemon use shared memory (32bit) to communicate values. Try shminfo to see if the 32bit shared memory area is heavily fragmented. ftp:/contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/

[Rich Powell]

Here is the summary information from shminfo:

Private 32-bit shared quadrants:
================================

Shared space from Window id 0 (global):
Space Start End Kbytes Usage
Q2 0x0754f800.0x40000000-0x7fffffff 1048576 FREE
Q3 0x05b38800.0x80000000-0xbfffffff 1048576 FREE

Shared space from Window id 1 (q3private):
Space Start End Kbytes Usage
Q2 0xffffffff.0x40000000-0x7fffffff 1048576 OTHER
Q3 0xffffffff.0x80000000-0xbfffffff 1048576 OTHER

Limits for 32-bit SHMEM allocation:
===================================

Maximum shmem segment: 1048576 Kbytes (shmmax)
Largest free segment: 1048576 Kbytes (Window id 0 (global) quadrant 2)
Available swap : 2979120 Kbytes (swapspc_cnt)
Available pseudo-swap: 7499108 Kbytes (swapmem_cnt)

Allocation policy for 32-bit shared segments
============================================

1. First-fit on quadrant 2 (SHMEM_MAGIC only)
2. First-fit on quadrant 4
3. First-fit on quadrant 3

[Rich Powell]

We have tested this issue with Glance version 3.70, and there is no problem. Thank you all for your time.

Rich Powell