Red Hat Bugzilla – Bug 109169
msc.nastran fails to allocate >800MB
Last modified: 2007-11-30 17:06:59 EST
Description of problem: There is a problem with MSC.NASTRAN allocating>800MB of RAM on ia32 systems whihc is described here: http://www.msclinux.com/support/faq.html?action=view_qanda&selectedfile=28 Presumably, this problem should not occur when running the 32bit binary under an opteron with >2GB of RAM, however I am experiencing the issue here on an upgraded taroon system. I installed the latest kernel errata (2.4.21-4.0.1.ELsmp) as it appeared to be directly related, however the problem has not changed after the update. On the taroon list, Arjan van de Ven asked for the /proc/<pid>/maps file of the process before it fails, however even from a script I cannot get the pid fast enough. Thus I am attaching the maps file from a run where mem is limited to 800MB. Version-Release number of selected component (if applicable): 2.4.21-4.0.1.ELsmp How reproducible: using msc.nastran 2001; nastran scr=yes mem=896MB Steps to Reproduce: 1.run nastran with a mem request (or estimate result) >800MB 2. error appears in nastran's .log file Actual results: see attached files Expected results: allocation succeeds and the job runs Additional info:
Created attachment 95727 [details] msc.nastran 2001 logfile showing memory allocation error also tried with stack size =unlimited but that doesn't seem to matter...
Created attachment 95728 [details] /proc/<pid>/maps from a nastran job with mem=800MB since I can't get the maps file from a failing instance (tried scripting it but can't get the pid fast enough) here is the maps file from a successful instance, limited to 800MB by using the command line nastran mem=800MB
ok this shows the kernel is just fine, but that msc is broken. It doesn't use the glibc memory allocator but a broken own allocator, which doesn't know how to deal with linux well. There's nothing we can really fix here... MSC needs to fix their allocator to work properly with linux (eg fall back to mmap of /dev/zero if brk space runs out)
Is there any point in my looking at the 'tumb' patches described in the MSC FAQ: http://www.daimi.au.dk/~kasperd/linux_kernel/task_unmapped_base/
no; that has no relevance on amd64 really....