O fato de seu programa chamar brk(2) tantas vezes (8843) me faz pensar que seu código está solicitando muita memória do sistema. E geralmente, no Linux, quando um programa solicita muita memória, ele é eliminado com SIGKILL .
Mais detalhes
brk(2) é uma das duas maneiras de um programa solicitar memória. A outra maneira é mmap(2) . As implementações de malloc(3) e amigos oferecidas pela Biblioteca GNU C usam uma combinação das duas.
De um modo geral, qualquer que seja a maneira como seu programa aloca memória, o Linux não reclama. Mesmo que não haja memória disponível, é possível que o kernel ainda retorne endereços válidos.
Isso porque o Linux aloca a memória preguiçosamente , no sentido de que a memória não é "fisicamente alocada" até que você comece a usá-la. Essa é uma ótima otimização de desempenho.
Agora, o que acontece quando você tenta usar alguma memória, mas a RAM e a troca do sistema estão cheias? Se o Linux alocou sua memória fisicamente, então não há problemas. Além disso, um componente chamado OOM killer inicia a eliminação de processos que consomem a maior parte da memória, com o objetivo de manter o sistema utilizável.
Sobre o acesso
Você observou que strace -c está relatando 4 access(2) de falhas. Isso certamente não é um sintoma de um problema. Está perfeitamente bem para uma chamada de sistema falhar. Problemas ocorrem quando o seu programa não lida com falhas.
Um exemplo:
$ strace -e trace=stat -- ls /abc
stat("/abc", 0x1df2e30) = -1 ENOENT (No such file or directory)
ls: cannot access /abc: No such file or directory
+++ exited with 2 +++
Eu disse a ls para listar o conteúdo de um diretório inexistente ( /abc ), portanto, a chamada para stat(2) falhou com ENOENT . Este não é um problema para o ls : ele detectou a falha e exibiu uma mensagem de erro.
Problemas teriam ocorrido se ls não tivesse verificado o valor de retorno de stat(2) .
Sobre o seu problema específico: é difícil saber por que o acesso falhou. A saída de strace -e trace=access ou strace -C fornecerá alguns resultados. No entanto, acredito firmemente que tais falhas não são um problema para você, pois elas provavelmente vêm da Biblioteca C do GNU:
$ strace -e trace=access -- ls
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
...