Диагностика ENOMEM с помощью вызовов popen () и system () в переполнении стека

Я имею дело с гигантским кодом C ++ для вычислительной физики (который я не писал), который вызывает другие исполняемые файлы, используя system() звонки. Иногда в середине симуляции эти system() вызовы не удастся даже для простых вызовов, таких как system("echo something); Когда они терпят неудачу, они немедленно возвращаются с возвращаемым значением -1.

Я создал версию кода, которая использует popen() вместо system() запустить эти другие исполняемые файлы. В этой версии popen () завершается ошибкой, а errno устанавливается в 12 (ENOMEM).

Это выполняется на компьютере с 96 ГБ ОЗУ, на котором работает CentOS 6.3 (через ROCKS 6.1) через систему Torque PBS.

Обратите внимание, что это поведение несколько необычно, но, по-видимому, это происходит для симуляций, которые используют большие объемы памяти — но намного меньше, чем объем доступной памяти.

В настоящее время у меня работает симуляция, которая демонстрирует это поведение. Он пытается сделать system() звонить каждые 30 секунд и не удается, что позволяет мне контролировать ресурсы памяти ОС. Содержание /proc/meminfo являются

MemTotal:       99195180 kB
MemFree:         1758804 kB
Buffers:           14612 kB
Cached:         46502432 kB
SwapCached:         7004 kB
Active:         60758772 kB
Inactive:       35238760 kB
Active(anon):   45458924 kB
Inactive(anon):  4024068 kB
Active(file):   15299848 kB
Inactive(file): 31214692 kB
Unevictable:        9752 kB
Mlocked:            9752 kB
SwapTotal:       1023992 kB
SwapFree:         999432 kB
Dirty:                16 kB
Writeback:             8 kB
AnonPages:      49483620 kB
Mapped:            10292 kB
Shmem:                 8 kB
Slab:             235356 kB
SReclaimable:     193468 kB
SUnreclaim:        41888 kB
KernelStack:        2120 kB
PageTables:        99536 kB
NFS_Unstable:          4 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    50621580 kB
Committed_AS:   49576180 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      482936 kB
VmallocChunk:   34307833876 kB
HardwareCorrupted:     8 kB
AnonHugePages:  43315200 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5568 kB
DirectMap2M:     2082816 kB
DirectMap1G:    98566144 kB

Содержание /proc/5939/status (что является рассматриваемым процессом)

Name:   BAD_EXECUTABLE
State:  S (sleeping)
Tgid:   5939
Pid:    5939
PPid:   5938
TracerPid:      0
Uid:    505     505     505     505
Gid:    505     505     505     505
Utrace: 0
FDSize: 256
Groups: 426 505 801
VmPeak: 49733876 kB
VmSize: 49482532 kB
VmLck:         0 kB
VmHWM:  49721496 kB
VmRSS:  49470248 kB
VmData: 49481080 kB
VmStk:       128 kB
VmExe:      1316 kB
VmLib:         0 kB
VmPTE:     96656 kB
VmSwap:    10624 kB
Threads:        1
SigQ:   0/774828
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed:   ffffff
Cpus_allowed_list:      0-23
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list:      0-1
voluntary_ctxt_switches:        57003
nonvoluntary_ctxt_switches:     1057385

Я немного растерялся из-за того, как отладить эту проблему, тем более что я не могу воссоздать ее с помощью небольшой симуляции. Мой симулятор говорит, что он использует 47 ГБ памяти, в то время как /proc/meminfo показывает, что менее 2 ГБ из 96 ГБ памяти свободны, и не должно быть ничего другого, работающего с использованием десятков ГБ памяти.

Этот форум кажется, указывает на то, что предыдущие ошибки памяти могли повредить кучу. Это действительная возможность? Что еще я мог бы посмотреть на это, чтобы помочь мне сузить эту проблему?