mainmake - Support: sr #104418, Random "Virtual Memory...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

sr #104418: Random "Virtual Memory Exhausted. Stop." error during $(eval)

Submitter:  None
Submitted:  Tue 12 Jul 2005 10:00:18 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  5 - Blocker Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  MS Windows

Wed 13 Jul 2005 01:12:45 PM UTC, comment #3: 

The latest (and all subsequent) beta is available on the FSF's prerelease site: ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.gz

The non-UNIX ports of GNU make are solely maintained by volunteers: the official GNU make maintainers do not have any experience with, or even access to hardware for, the non-UNIX ports.  So, no improvements are possible on these systems unless someone in the user community steps forward and makes them.

Note that GNU make is not in any way multithreaded, and it actually does not require very sophisticated multitasking (multiprocessing) capabilities.  All it wants to do is be able to spawn a process and be notified (asynchronously) when that process has completed.

However, GNU make IS maximally portable.  You suggest that support for Windows 95 is not needed, but in fact one of our most active maintainers of non-UNIX ports uses exclusively 16-bit MS-DOS!  In addition, GNU make supports Amiga, VMS, and OS/2, as well as DOS, Windows32 both native and MINGW.  You're right that these things cause a very uncomfortable level of ifdef'ing in the code; I'd dearly love to cut that down significantly... but I'm not willing to abandon any port that still has active and involved users to do it.  I want to get this release out ASAP so I'm not interested in reworking code just to reduce warnings until after 3.81 is released, although obviously I'm interested in any bugs that are found.  I'm also not that interested in changing perfectly legal code just to satisfy some random compiler writer's idea of proper style (one compiler complains about "while (1)" and suggests it be changed to "for (;;)" for example).

I'd appreciate it if you'd subscribe to the -email is unavailable- list and continue this discussion there: that's where all the issues surrounding the DOS/Windows/OS2 ports generally happen and I typically look for some kind of concensus from that list before applying patches for these ports.

Paul D. Smith <psmith>
Group administrator
Wed 13 Jul 2005 11:53:05 AM UTC, comment #2: 


I finally got the build to work and the "Virtual Memory Exchausted. Stop." error message appears to have disappeared for the makefile(s) I was testing. This is good news.

However, I have to say that, as a Windows User who uses a NATIVE build environment and not the mish-mash of inconsistent UNIX emulations that is MINGW/CygWIN, etc. it was the flakiest compilation and build I have ever seen. I have been writing systems-level software and build systems in multi-platform environments for over 15 years (tens of simulataneous UNIX and Windows 16/32/64-bit architectures) using single build code bases and I have never seen anything so worrying as this build. My builds even catered for simultaneous compilation on such platforms as HP/3000 and IBM AS/400/System 3X and I still managed a comparatively preprocessor-free source code base. This is the second time I have had to delve into GNU Make on NT and after the last time I was hoping things might have improved slightly.

GNU Make is fully multi-threaded and relies on some sophisticated multi-tasking operating system features. That given, why is the source, and especially the build, still geared for Windows 95? Even Windows NT 4.0, whilst still in use, is hardly used as a DEVELOPMENT platform.

I built using Borland's C++ compiler which flagged around 400 warnings, and that was in "lenient" mode let alone "strict mode". And the build script for NT was just gruesome.

HOWEVER...

I'm not in the habit of criticising without offering a good solution in it's place. Therefore, if anyone is interested, I have ported the 3.81 Beta 2 build so that it supports Borland C++/CBuilder 5 and above (only a few gotchas found here), and I have rewritten the build batch files so that they are completely pluggable compiler-wise (MS or Borland), support much more robust and flexible NT command-shell scripting features and are much more easily maintainable. I can send either a full build ZIP file or I can outline the changes, as only a handful of files have actually changed.

I will keep you updated with any run-time errors I find with this build, that I can identify as not being compiler specific.

Cheers.

Anonymous
Tue 12 Jul 2005 10:55:14 PM UTC, comment #1: 

Ok... I've download 3.81 beta 2 and am trying to compile it.

Anonymous
Tue 12 Jul 2005 10:00:18 PM UTC, original submission:  


Hi.

I'm receiving a "Virtual memory exhausted. Stop." error with GNU make 3.80 on Windows 2000 Server. The error only happens during an $(eval $(call ...)) macro invocation.

The number of macros I am defining is as follows:

Global Macros: around 30
Target-dependent macros: around 30 per explicit target with one explicit target defined, none defined on pattern targets.
Macro maximum length: around 50 characters (name examples: Options.*.Compile.cpp.Includes, Options.memdebug.lib.Compile.cpp.Includes)

My makefile is currently mid-development and doesn't actually do anything. However, I dumped the output of the $(eval...) that is causing the problem and attached it in a file. This output is the actual portion of expanded makefile that is causing GNU make fail during execution.

In the sample file I've marked a line with the sequence "[>>>>]". Removing this line removes the error and inserting this line produces the error.

In addition, could you please tell me under what circumstances this error is given? Is there a workaround to this problem?

I read a conversation on a board that you had fixed a similar "Virtual Memory Exhausted. Stop." problem on, or around, the 23rd June, 2003. However, no new release of GNU make newer than 3.8 (Oct 2002) appears to have been released.

Many Thanks in Advance,

Andre Sihera.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #4009:  dump.txt added by None (4KiB - text/plain - Output of expanded $(eval...) in a makefile that causes GNU make to crash with "Virtual Memory Exhausted. Stop." error)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-13 psmith StatusNone Done
    Open/ClosedOpen Closed
2005-07-12 None Attached File- Added dump.txt, #148
    Carbon-Copy- Added andre --AT-- nismo --DOT-- freeuk --DOT-- com

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code