I found a thread on bug-make, a year ago, about "*** virtual memory exhausted. Stop."
That involved 1000's of targets; it appeared that folks were taking it to be a
real case of memory overflow. The only response appeared to be that no leaks
were being found.
I am getting this message with a few dozen targets, and I'm getting it really fast.
This is with gmake 3.80, built from tarball under gcc 3.2 (same problem
when built under 2.96)
time make -f model_py_so.make
make: *** virtual memory exhausted. Stop.
0.020u 0.010s 0:00.52 5.7% 0+0k 0+0io 738pf+0w
It's hard to believe that this is really exhausting VM in 30 msec;
if it is, it's probably not actually doing anything with the memory.
I suspect that some internal line length limit, or something, is
being overflowed, or that something is mistakenly asking for
some ginormous amount of RAM and not getting it. We
sometimes run processes on this box which use 1.5 GB of VM
(Redhat 8.0)
I don't know exactly what "0+0k 0+0io 738pf+0w" means,
but I think it means that the process didn't use a lot memory.
I wish this was a small case I could send you, but it's spread over
four makefiles with dependencies in umpteen directories;
I am using this kind of construct:
>>>>>>>>>>>>>>>>>>>>>>>>
define CPP_TO_PY_template
$(SPCM_OBJ)/$(1).py.o: $(2).cpp
$(C++) -c $(PY__CPPOPTS) -I. -I$(SPCM_AUTO) -I$(PYTHON_HDIR) $(2).cpp -o $$@
$(SPCM_OBJ)/$(1).py.d: $(2).cpp
$$(call MAKE_DEPENDS,$(PY__CPPOPTS) -I. -I$(SPCM_AUTO)
-I$(PYTHON_HDIR),$(SPCM_OBJ)/$(1).py.o,$(1))
DEPEND_INCLUDES += $(SPCM_OBJ)/$(1).py.d
endef
$(foreach CPP, $(ALL_PY_CPP) $(AUTO_CPP),$(eval $(call CPP_TO_PY_template,$(notdir
$(CPP)),$(CPP))))
########################################
# make an _auto_XX.cpp from XX.h
#
define AUTO_GEN_template
$(SPCM_AUTO)/_auto_$(1).h: $(SPCM_AUTO)/_auto_$(1).cpp
$(SPCM_AUTO)/_auto_$(1).cpp: $(2).h
python $(SPCM_LOC)/genwrap.py -o$(SPCM_AUTO) $(2).h
endef
$(foreach M, $(SPCM_MODELS),$(eval $(call AUTO_GEN_template,$M, $M)))
<<<<<<<<<<<<<<<<<<<<<
Furthermore
- there are a fairly large number of .d files ( containing output from gcc -M)
generated and included. Maybe 5K files are named across 26 files, but many are
duplicate;
*however* the bug occurs even when they are removed, and the failing 'make' does
not generate the .d files.
- the same environment is working properly in another situation with the same
set of targets (actually, more) but in the other environment, the
definition of SPCM_AUTO is much shorter than in the failing one. A few
other output dir names are different. In general,
many of the source and target path names (both as expressed, and as absolute paths)
are
longer in the failing setup than in the working one.
- the environment which fails, will work with a slightly smaller number of targets.
- I ran into the same problem before ( in the failing environment ) when the number
of targets was smaller, and I solved it by shortening one of the output dir
names (from a ../../../yada/foo/bar/obj type thing to just ./obj) but it was
not clear whether it was (a) just the length, or (b) the fact that ./obj did not
have
a common prefix with another output dir.
Finally:
- I get the same error regardless of -p, -n or -d options; but when -p is
used,
a 1565-line database dump is generated. I can send that, if it is of interest.
The -d output is below
>>>>>>>>>>>>>>>>>>
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Reading makefiles...
Reading makefile `model_py_so.make'...
Reading makefile `maadi.mk' (search path) (no ~ expansion)...
Reading makefile `mnr.mk' (search path) (no ~ expansion)...
Got a SIGCHLD; 1 unreaped children.
Got a SIGCHLD; 1 unreaped children.
Got a SIGCHLD; 1 unreaped children.
Reading makefile `../../../shared/model/SPCM/share/mkmodels.mk' (search path) (no ~
expansion)...
make: *** virtual memory exhausted. Stop.
<<<<<<<<<<<<<
Maybe this is a known issue?
If someone can help me make this work rather than abandon a makefile I spent
several hours beating into functionality, I would appreciate it.
---------------------------------------------------------------------------------
This e-mail and any attachments may contain confidential information. If you are not
the intended recipient, please notify the sender immediately by return e-mail, delete
this e-mail and destroy any copies. Any use, review, dissemination, forwarding,
printing or copying of this email or any information or attachments contained herein
by a person other than the intended recipient is unauthorized and may be illegal.
Silicon Optix reserves the right to monitor all e-mail communications through its
networks for quality control purposes.
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-make
