Subject: vm_allocate failed

From: [email-masked] (Eric Schwartz)
Date: Wed, 24 Feb 1993 09:22:11 -0800

I've had this problem 2 or 3 times now in the past few days.  I'm  
quite new to this, so can someone give me some tips on resolving the  
problem?

Thanks,

Eric

Feb 24 00:39:11: CREATED: Dominator (#564) on 6 from 192.83.245.254
memory allocation error: vm_allocate failed
Feb 24 00:54:52: *** PANIC: memory allocation (size 760) failed!
Feb 24 00:54:52: PANIC-DUMPING on output.db.PANIC ...
memory allocation error: vm_allocate failed
memory allocation error: vm_allocate failed
Feb 24 00:55:04: *** PANIC: memory allocation (size 1280) failed!
Feb 24 00:55:04: *** RECURSIVE PANIC: aborting
IOT trap

---

From: [email-masked] (Jonathan Bradshaw)
Date: Wed, 24 Feb 1993 09:47:53 -0800

> Feb 24 00:55:04: *** RECURSIVE PANIC: aborting

Well, your the only other person who has this problem apart from me it
seems!!!!! In fact, its nice to know I'm not the only one. Maybe with
you, me and Pavel we could isolate the problem. The error is coming
from the kernel it appears. It is caused by a malloc() returning a 
nil pointer. It can happen at anytime that a malloc() is called. Although
normally it happens after a large memory request it does not always happen.
I have a feeling it may be due to fragmentation and contigous memory. There
is no one else using the machine at the time of the crashes (it makes no
difference) and plenty of virtual memory available. I am running a NeXT
Color Slab running 2.1 Nextstep with 12mb of memory. The reason for the
RECURSIVE panic is because when the database dumps the VERBS it needs
to allocate memory to write them (it expands them as they are written)
which causes the second panic. [Pavel - is this expansion needed?]

Pavel - Can we get this fixed somehow? I'm an idiot when it comes to
debugging. I would welcome giving you any needed resources to fix this.

Example from my current log:

Feb 22 15:18:21: CLIENT DISCONNECTED: Lister (#580) on 6 from 141.241.4.25
Feb 22 15:21:05: ACCEPT: #-30 on 6 from 137.82.43.9
Feb 22 15:21:07: DISCONNECTED: #-30 on 6 from 137.82.43.9
Feb 22 15:53:08: ACCEPT: #-31 on 6 from 128.210.10.8
Feb 22 15:53:08: CONNECTED: Phaedrus (#755) on 6 from 128.210.10.8
Feb 22 15:58:11: ACCEPT: #-32 on 7 from 128.54.30.38
Feb 22 15:58:26: CONNECTED: Usagi (#298) on 7 from 128.54.30.38
memory allocation error: vm_allocate failed
Feb 22 15:59:17: *** PANIC: memory allocation (size 496) failed!
Feb 22 15:59:17: PANIC-DUMPING on dump.PANIC ...
memory allocation error: vm_allocate failed
memory allocation error: vm_allocate failed
Feb 22 15:59:42: *** PANIC: memory allocation (size 24) failed!
Feb 22 15:59:42: *** RECURSIVE PANIC: aborting
.....(and later)......
Feb 23 14:35:55: ACCEPT: #-36 on 6 from 128.123.62.4
Feb 23 14:35:58: CONNECTED: Druid (#641) on 6 from 128.123.62.4
Feb 23 14:36:03: DISCONNECTED: Druid (#641) on 6 from 128.123.62.4
Feb 23 14:36:55: ACCEPT: #-37 on 6 from 128.210.10.8
Feb 23 14:36:56: CONNECTED: Phaedrus (#755) on 6 from 128.210.10.8
Feb 23 14:37:05: ACCEPT: #-38 on 7 from 130.160.232.75
Feb 23 14:37:07: DISCONNECTED: Phaedrus (#755) on 6 from 128.210.10.8
Feb 23 14:37:10: CONNECTED: Angelo (#409) on 7 from 130.160.232.75
memory allocation error: vm_allocate failed
Feb 23 14:40:06: *** PANIC: memory allocation (size 24) failed!
memory allocation error: vm_allocate failed
Feb 23 14:40:06: *** PANIC: memory allocation (size 12) failed!
Feb 23 14:40:06: *** RECURSIVE PANIC: aborting

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 24 Feb 1993 09:50:47 -0800

Your operating system refused a request for more memory by the server.  Perhaps
you have run out of swap space?  If you have the option LOG_COMMANDS turned on,
you should turn it off, since it uses a fair amount of memory unless you
checkpoint pretty frequently.

	Pavel

---

From: [email-masked] (Jonathan Bradshaw)
Date: Wed, 24 Feb 1993 09:53:06 -0800

>checkpoint pretty frequently.

Since the OS refused a request when my DB was half the size it is now,
and it still does. It does not seem the size is the problem (swap file
can grow on the NeXT to 160MB and its only at 20MB the default right now)
it seems the fragmentation of malloc() and release may be the problem.

-- 
 Jonathan Bradshaw | [email-masked] | PGP Key Available On Request
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
 "If a girl rejects you, don't doubt it's part of the plan" -Deborah Ann Gibson

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 24 Feb 1993 10:06:18 -0800

> Date:	Wed, 24 Feb 1993 09:47:53 -0800
> From:	[email-masked] (Jonathan Bradshaw)
> 
> The reason for the RECURSIVE panic is because when the database dumps the
> VERBS it needs to allocate memory to write them (it expands them as they are
> written) which causes the second panic. [Pavel - is this expansion needed?]

In the current database format, yes, since the verbs are maintained in compiled
form internally and in source form on disk.  The probability of needing to
allocate during checkpointing could be lowered by keeping track of a pool of
buffers, but it could not easily be reduced to zero.

However, since the disk-based server maintains verbs in compiled form on disk,
this problem won't exist any longer once that's released, so I'm none too hot
to try to fix it now.

> debugging. I would welcome giving you any needed resources to fix this.

The only way I could try to fix it would be to look at the kernel sources for
your machine, and that only if I had much more time than I do.  Have you
considered complaining to NeXT?

	Pavel