bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make: *** virtual memory exhausted. Stop.


From: Gregory Smith
Subject: Re: make: *** virtual memory exhausted. Stop.
Date: Tue, 15 Jun 2004 17:15:46 -0400

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. 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]