| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
'Cannot allocate memory' - help!
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 'Cannot allocate memory' - help! - Mar. 31, '06, 1:03:21 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
I seem to be getting a "cannot allocate memory" error a lot. Almost anything can cause it; usually it seems to be basic commands and API's (even when the shell tries to call getcwd right after I start it!). I am trying to set up Interix as a build platform and this is making any level of automation absolutely unreliable and unusable.
It seems to be completely random; that is, re-trying the same command several time in succession will sometimes work and sometimes fail. I am not out of memory; task manager shows total system usage floating around 300 mb, and I only have a few dozen running processes (33 right now, but maybe 40 when I see the problem).
Has anyone else seen this? Is it a bug in bash-3.1? In SUA?
I also saw something about being out of file handles on a google cache of this forum from 2003; how do I check that?
[EDIT: I should mention that I am on SUA 5.2 on Windows Server 2003 x64]
< Message edited by woehlkmp -- Mar. 31, '06, 1:19:32 PM >
|
|
|
|
 RE: 'Cannot allocate memory' - help! - Mar. 31, '06, 2:16:15 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
"Cannot allocate memory" isn't going to be a handle problem.
Just to be clear: these are the commands that come in the MSI from Microsoft
that are failing, right?
I get the impression this is with a build of bash you've done yourself.
Which compiler did you use?
When you run in another shell (ksh or csh) do you get these problems?
Have you tried running the /Tool 32-bit bash binary to compare?
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Mar. 31, '06, 2:45:02 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
As a note: I am running R2/64-bit with Interix 5.2 with the 32-bit bash with no problems.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Mar. 31, '06, 2:53:25 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
"Cannot allocate memory" isn't going to be a handle problem.
Ok, I'd seen that from a cached post from these forums (in 2003!) about the same problem.
I'm using bash-3.1 built from the latest available sources with 'cc' (gcc is broken on x64! ...you may recall that I've complained about this in other posts). I've seen bash fail to change directories due to this error (so I'm assuming getcwd() or something similar is what failed). I've also seen 'make' fail on stat(). Using someone else's version of 'make' is not an option; our build process depends on changes we have added to GNU make.
I can't get this to happen reliably (now that I'm trying, it won't happen, of course  ) so I can't be very specific, except that it might be a problem with the 'cc' Interix C runtime libraries used by anything I've built. The only thing I can think of where bash itself would be at fault is if it is doing something braindead like cutting a ulimit out from under me.
Like 'make', if I'm going to get this to work, I have to depend on a number of Interix-land utilities that are proprietary or have had proprietary modifications made; "use someone else's version" is not a viable solution. I need to be able to depend upon applications I build from source to not have these problems. (That said, if I can figure out how to cause it to happen, I will try playing around with other shells.)
FYI: I'm using x64 because I need to build for x64... but I'm starting to think that maybe I should give up and use a (ahem) stable platform with a cross-compiler? So far I'm not impressed with Windows x64!
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Mar. 31, '06, 3:29:58 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
Here's something...
make: execvp: sh: Cannot allocate memory
make: execvp: sh: Cannot allocate memory
make: *** [clean] Error 127 ...this is coming from 'make'?
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Mar. 31, '06, 8:27:37 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Yes, this is coming from make because make will
invoke a shell to get some of the recipies in the Makefile done.
Clearly the execvp() API is the failing call.
Which make is this that you are running? (the full path?)
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 2, '06, 7:15:10 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Sorry if I'm making useless post - I know nothing about 64-bit, you're probably very alone up there - so take this for what it is:
If I were you I would be very unconventional in the approach, getting to it from the low end to be sure the binaries are 64-bit.
* use Visual Studio 2005 with the 64bit compiler (or intel 64bit compiler and MS linker), apply the same switches as in the cc script and pray. The make build will give you a pretty good idea how to form an appropriate VS project.
[EDIT] Why use bash when everything is unstable? What's wrong with the Korn Shell?
< Message edited by jerker_back -- Apr. 2, '06, 7:23:54 PM >
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 3, '06, 10:33:37 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
Yes, this is coming from make because make will invoke a shell to get some of the recipies in the Makefile done.
Clearly the execvp() API is the failing call.
Correct... which is why I suspect that bash isn't the problem. I should also mention that GNUmakefile sets 'SHELL = sh', which evaluates to '/bin/ksh'. And, again, I have also seen stat() fail in 'make', so it isn't just execvp(). In fact, here's a stupid question: could this be a problem with pointers being truncated or some such nonsense? I.e. it only breaks if the upper DWORD of the pointer is NOT '0x00000000'?
quote:
Which make is this that you are running? (the full path?)
I am using '/w32dev/make'. I mentioned previously that this is a modified version of 'GNU make 3.80' that I have to use, because our build process requires it. I use the same source base for MKS and Cygwin without problems, so the problem isn't the source, but it may well be a problem in the compilation! (I haven't changed any makefiles or config stuff from 3.80, except to use an updated config.guess, and I have 'CC=/bin/cc'.)
quote:
If I were you I would ...<snip>... use Visual Studio 2005
The whole point of this exercise is to increase homogenity. I'm building on up to ten platforms. One of them is Windows. The others have no such thing as "Visual Studio". Trying to change things on Windows to not use make would take an unacceptably long amount of time. If I cannot resolve these problems soon, I am going to have to give up on 64-bit SUA and use something else; either 32-bit SUA, or MKS (which is what we have used historically), or even Cygwin (which is what I use in developement).
Sorry to be annoying, but this is really frustrating. We have customers pressuring us for a 64-bit Windows build, and so far this whole 64-bit thing has been one enormous frustration!
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 3, '06, 7:51:34 PM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
Just so I got this right,
- you are running SUA (on Win2003 server R2)
on a 64bit platform using a 64bit version of windows.
- you have your own compiled version of gmake (version 3.80)
built using SUA tools.
Q: did you build your version of gmake as a 32 or 64 bit program ?
Q: are you using a single-cpu or multi-cpu system ?
It looks like the error message you're seeing is in job.c (line 2363 in my copy).
Questions:
- for the command line being invoked in your Makefile,
a) do you have a sense for how large the command line is ? (how many bytes ?)
b) Do you have a sense for how large the environment is ? (in bytes)
In sfu3.5, there was a limit of 1Meg for all data/args/environment passed thru exec() functions.
Notes:
every Windows binary (win32 or Interix subsystem) has settings for its initial stack and heap.
There are options in /bin/cc to adjuct these settings.
It is possible that you may need to make these settings larger.
I don't think it'll help, but we won't know until you try.
The default values in SFU3.5 was 4Meg stack (400000) and 8Meg heap (800000).
(you can also use Window's DUMPBIN.exe to modify these settings directly on your 'make' binary
instead of using the /bin/cc options)
- More likely, the problem is in execvp() itself. Or rather, execve() which is what is
invoked eventually.
If the problem is here, then only Microsoft can fix this.
Possible work-around:
- given that your problem is intermittent, I'd suggest trying to modify your version of gmake
in job.c where execvp() is called. Check the error status and if it is ENOMEM then
try the execvp() again. Probably only a couple of times, then give up.
You could also try putting in a sleep(1) or (2) after each failure, just because.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 4, '06, 10:30:24 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
> you are running SUA (on Win2003 server R2) on a 64bit platform using a 64bit version of windows.
> you have your own compiled version of gmake (version 3.80) built using SUA tools.
Check and check (built using /bin/cc).
> Q: did you build your version of gmake as a 32 or 64 bit program ?
It's 64-bit. I wasn't able to get 32-bit programs to compile properly using /bin/cc or gcc (problems with 'ar').
> Q: are you using a single-cpu or multi-cpu system ?
Task Manager shows two VPU's, a peek inside the box reveals two chips... so multi-CPU. 'System Properties' says they're Xeon's, so HT must be turned off.
> - for the command line being invoked in your Makefile,
> do you have a sense for how large the command line is ? (how many bytes ?)
'wc' reports a line that failed as 289 bytes. This is the call to the wrapper script, but if I understand correctly, that's what would be causing the problem anyway?
> Do you have a sense for how large the environment is ? (in bytes)
'env | wc' reports 4096 bytes.
I'll investigate the work-around, but I've also seen stat() fail (once), so I know this won't be a complete fix (and I've seen other API's fail in other locations).
I also have vindication for everyone that has been blaming it on bash... I managed to run it under ksh last night, and it still died in execvp(), so the problem isn't bash. It's probably the C libs, as markfunk suggests.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 4, '06, 10:43:44 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
So... where the heck do I go to gripe at Microsoft, that won't cost me an arm and a leg? All I could find was http://support.microsoft.com/gp/contactbug, which only gives a phone number. Is that the only option?
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 4, '06, 12:41:49 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Having it fail using ksh makes it a lot easier to get MS support
to take on the report because ksh is MS's binary. Whenever a
problem exists, getting it replicated with what ships is best/easiest
because the non-MS binary can't be "blamed".
Generally speaking MS will not charge for a bug that is "their" bug.
That might take a while to determine. Certainly the fastest response
will be with the telephone, but you have to ante up a credit card
before MS support will look at it. It's the same situation with the
hotfixes when you get one.
The multi-CPU might be the problem.
I'll quote one of Mark's posting from back in February:
quote:
In the meantime, you could try one of the old multi-cpu fixes.
For instance, create the registry key
HKLM/Software/Microsoft/Services For Unix/ForkWait
which is a DWORD. Set it to a value of 250 for starters.
(valid values are between 0 and 2000).
Might be worth a try.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 4, '06, 2:51:18 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Well, it's interesting that it helped something.
I think the Multi CPU is looking to be the central cause of things.
I state this because the ForkWait worked on something and that on a
single (AMD) 64-bit CPU I haven't seen any of these problems.
Glibc isn't going to solve anything even if you could build it.
There's an underlying cause at the Kernel/HAL/driver/hdwr level I think.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 4, '06, 3:07:04 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
Ok, that's ugly... but thanks for all the help.
I'll see if I can get Microsoft involved without having to hand over my personal credit card number. Meanwhile, I'm installing 2003 R2 32-bit.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 5, '06, 12:45:55 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
tar (child): Cannot exec gzip: Cannot allocate memory
...And I've tripped yet another 'execvp' in make. Is this computer broken, or what? Now I'm having problems in 32-bit!
What causes ENOMEM other than insufficient address space? Is it possible my RAM is bad?
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 5, '06, 2:53:41 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
That tar error message is from GNU's tar.
The execlp() has failed.
Given that you have gotten an ENOMEM I'll lean towards the
conclusion that the call didn't make it to the subsystem.
So the ENOMEM happened while memory was asked for while
the arg list was getting arranged for passing to the subsystem.
So a ForkWait is unlikely to do anything here.
Why you're getting ENOMEM? I don't know.
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 7, '06, 6:12:17 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
Truthfully... are people actually using SUA 5.2? I've tried both x64 and x86 on one computer, and I'm now on my THIRD installation, this one clean and on a totally different computer, and I am still having the same problems. I can't understand what I'm doing that is so strange that no one else has had these problems!
The only thing I can think of that might make me unique is NFS. My $HOME points to an NFS volume, and, while I have seen problems while poking around local drives, I'm usually trying to do stuff on an NFS volume.
[EDIT] I did a little experiment, using both ksh with /bin/ls and bash-3.1 with /usr/gnu/bin/ls (the latter pair being both things I built myself from sources; GNU ls is from fileutils-4.1), running the command line 'while ls ; do : ; done' on an NFS volume. In both instances, it will run for a while and then fail with 'Cannot allocate memory' (Task Manager shows memory usage throughout the test to be about 142 MB). Interestingly, if I run both at the same time, they will fail at the exact same time.
< Message edited by woehlkmp -- Apr. 7, '06, 7:05:40 PM >
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 10, '06, 12:54:04 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
How "different" is the second machine. Is it too a Xeon multi-CPU?
|
|
|
|
|
RE: 'Cannot allocate memory' - help! - Apr. 10, '06, 1:33:14 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
It's also SMP, but it's ancient... dual 800 MHz chips (I guess they must be Xeon, as they're Intel, but I forget now; I dismantled it and am going to try with Win2K and SFU 3.5). Still, I can't imagine that dual-Xeon is such an "unusual" platform that it isn't supported!
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
RE: 'Cannot allocate memory' - help! - 
, as MSlibc seems to be the issue.)