Existe a necessidade de verificar se há NULL após alocar memória, quando o Kernel usa memória de compensação excessiva

Question

É prática geral verificar se a memória é alocada com sucesso) após um malloc (), algo como

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}  

Com o comando de memória superado ativado no kernel, há uma chance de ficar nulo? Devo seguir a prática de verificar religiosamente nulo para cada alocação? Maloc retornará NULL, apesar do mecanismo de comprometimento excessivo agressivo (acho que o valor 1)?

De fato, o kernel do Android usa compensação excessiva de memória (não tenho certeza sobre o valor, adoraria conhecê -lo (valor sobrecomitora) e seu significado). Alguns do código da fonte da estrutura (C/C ++) no Android (pode ser a terceira partida) não verificam o NULL nem captura BAD_Alloc após as alocações. Estou esquecendo de algo?

Existem alguns threads em relação à memória excessiva, mas nenhum deles resolveu minha confusão.

EDITAR: Se a Comcommit agressiva estiver sendo empregada nula não será devolvida (Assunção 1). Quando não houver memória física disponível e tentar acessar a memória alocada (escreva na memória alocada), a OOM matará algum processo e alocará memória para o aplicativo até que seja morto por sua vez (suposição 2). Em ambos os casos, eu não vejo necessidade de parecer nulo (a memória sendo alocada ou o processo sendo morto). Estou certo em minhas suposições?
A portabilidade não é uma preocupação para esta questão.

Answer 1

Sim, você ainda deve verificar se há falhas devolvidas por malloc. Em um ambiente que sobrecomita a memória, você não poderá detectar e se recuperar de falhas devido ao ambiente que fica sem armazenamento físico necessário quando você escrever em partes do espaço de endereço que foram alocadas ao seu programa por uma chamada anterior para malloc.

No entanto, este não é o único problema que causaria um malloc falhar em um ambiente tradicional. Uma solicitação para um bloco particularmente grande de memória quando o espaço de endereço do seu programa se tornou fragmentado pode falhar, mesmo que haja memória física total potencialmente suficiente para satisfazer a solicitação. Porque não existe uma faixa contígua de espaço de endereço livre malloc deve falhar. Este tipo de falha deve ser sinalizado por malloc retornando NULL, se o ambiente está ou não compensando a memória.

Answer 2

Você deve verificar o valor de retorno para nulo todo Tempo. Qualquer função da biblioteca pode falhar. Até o FClose () do (no NFS desconectado compartilham e o erro do arquivo fclose do NFS significa que os dados não foram salvos).

A maioria do software é mal escrita e não contém todas as verificações.

Malloc não pode devolver algo diferente de nulo ou ponteiro. Tudo ou nada. Você não pode obter 1 byte de Malloc se pedir 10.

Answer 3

Seria aconselhável verificar se há NULL religiosamente em todas as chamadas de funções que podem retornar nulas, independentemente de o kernel ter uma memória excessiva ou não.

Este segmento de código seguinte abaixo mostra como verificar se a chamada para malloc funcionou ou não ...

void *ptr = malloc(10);
if (ptr != NULL){
   /* Do something here with ptr */
}else{
   /* Do something here if it fails */
}

Operações de arquivo, operações de memória para nomear, mas alguns retornarão um nulo após a falha.

Espero que isso ajude, cumprimentos, Tom.

Answer 4

Bem ... no Linux, já que a memória não é apoiada pela página (inicialmente) e só cria o apoio da página após a primeira leitura/gravação, o sistema operacional sempre conseguirá lhe dar memória (a menos que você esgote o espaço de endereço, algo que não é possível em sistemas de 64 bits ). Portanto, se ele ficar sem memória e não puder fornecer a memória prometida, o OOM Killer apenas matará seu aplicativo ou algum outro aplicativo para oferecer o apoio da página necessário. Então, se você faz o cheque nulo ou não, o resultado é o mesmo, um acidente .......

Answer 5

Não, não há necessidade de verificar o resultado do Malloc.

Muito antes de Malloc falhar, o sistema operacional já havia encontrado muitos problemas.

"Oom-Killer e Overcomit" seria uma escolha melhor.

O que? Seu sistema operacional não suporta "Oom-Killer e Overcomit"?

É por isso que você deve mudar para o Linux （ou Android)!