Original question at the bottom.
Many thanks to those who responded:
Elizabeth Harvey-Forsythe
Rasal Kumarage
John Tan
Ric Moore
alan_at_nabeth.cxo.dec.com
Ram Rao
Danny Petterson
Colin Walters
Paul Roetman
Dr J Pelan
Solution came from Peter Webb at Mathworks:
"Try compiling without using the optimizer, ie. build a debug version by
adding the -g switch to your mcc command. If this works, then the problem
is probably in the interaction between the compiler's generated code and
the Alpha's optimizer."
Next best try came from Colin Walters. He's drafting a new section to the
Admin Guide and it follows:
Correcting an Apparent Lack of Swap Space
There limits on the amount of virtual memory that an individual
process can use. These limits are not related to the total amount
of available swap space. Consequently, you might see error messages
stating that a process has run out of virtual memory even though
a swap monitor (such as the dxsysinfo utility), does not display a
swap shortage. In some cases, a process might be automatically
killed when it exceeds its allotted virtual memory.
If there is an actual shortage of swap space, you will see one of
the following messages:
o The following message is displayed whatever swap mode you are
using:
swap space below 10 percent free
o If you are using lazy swap mode, you might see a message similar
to the following:
process (pid = 818) killed because of no swap space
o If you are using eager swap mode, you might see a message
similar to the following:
Unable to obtain requested swap space
Use the following command to verify that your swap space is
adequate:
# swapon -s
The data field titled "In-use space:" informs you if you are using
most of your available swap space.
If you are not using all your available swap space but you are
observing problems running large processes, you might need to
assign more resources to the process. There are several kernel
attributes in the proc subsystem that you can use to control the
per-process virtual memory resources:
o Stack limit
The per-proc-stack-size and max-per-proc-stack-size attributes.
o Data limit
The per-proc-data-size and max-per-proc-data-size attributes.
o Address space
The max-per-proc-address-space and per-proc-address-space
attributes.
If you encounter problems that appear to be due to a lack of memory,
consider the following options:
o Refer to the reference page that describes your command shell,
such as ksh1. Command shells have a limit or ulimit option that
enables you to modify the virtual memory resources for a process.
o Use the sysconfigdb command or the dxkerneltuner GUI to modify
the value of the per-process resource limits in the
/etc/sysconfigtab file. Instructions for modifying kernel
attributes are provided in The System Administration Guide,
Chapter 4.
o See the System Configuration and Tuning guide for information on
tuning virtual memory (vm) subsystem attributes, such as vm-maxvas.
All subsystem attributes are documented in sys_attrs(5) and related
reference pages.
Thanks again to all!
Jim
-----Original Message-----
From: Eiler, James A. [mailto:James.Eiler_at_alcoa.com]
Sent: Monday, January 29, 2001 5:14 PM
To: tru64-unix-managers_at_ornl. gov (E-mail)
Subject: Insufficient virtual memory to continue compilation
Hello,
I've got a user running Matlab Version 6 on a DS10 running Tru64 UNIX v5.1,
Patch Kit 2.
When he tries to compile his C applicaiton, he gets the error:
Fatal: Insufficient virtual memory to continue compilation.
I've tried compiling this program as root, thinking root has no virtual
memory limitations... but I get the same results.
Any suggestions?
BTW - I looked at the Kernel Tuner and the parameters for "vm" look askew.
Any ideas why? Or is this a feature with 5.1?
Thanks!
Jim
Received on Wed Feb 07 2001 - 14:44:43 NZDT