2011-12-07 13 views
2

私は64ビットLinux centos 5.7でansi Cにコンパイルしてgcc4.4.4とgdbを使用しています。なぜ私のコードがPDF == NULLの真偽をテストしてexit(2)を呼び出すのか不明です。無料-mを使用してCプログラムのmalloc代入がNULLを返す理由は?

void func(...) 
... 
double *PDF; 
... 
PDF = malloc(sizeof(double) * 1); 
if (PDF == NULL) { 
    exit(2); 
} 

プログラムが始まる前に、私が守っ:

   total  used  free  shared buffers  cached 
Mem:   2001  1955   46   0   71  975 
-/+ buffers/cache:  907  1094 
Swap:   4008  688  3319 
、プログラムが終了(2)の上に座っているとき。コードの行は、無料-mは、読み取ります。どちらの場合も

   total  used  free  shared buffers  cached 
Mem:   2001  1970   31   0   72  976 
-/+ buffers/cache:  921  1080 
Swap:   4008  688  3319 

、キャッシュ行で使用可能なメモリをたっぷり、(1バイトのための確かに十分な)自由の列があります。

その他の理由として、PDFがNULLになる可能性はありますか?これを引き起こす可能性のあるコード・バグは何ですか?

私は先週、gdbをたくさん使っていましたが、プログラムを終了する代わりに "q"と "y"を使用して終了しました(すべてのmallocメモリが終了するとfree()コードを実行する必要はありません)。

+0

問題を再現する[SSCCE](http://sscce.org)のサンプル( 'main()'、includes、およびgccフラグ)を見ることはできますか? – pilcrow

答えて

4

バッファの境界を超えて書き込みを行った場合、ヒープが破損している可能性があります。この場合、すべてのベットはオフになっています。

あなたがこのようなことをしていないことを確認するValgrind。呼び出し元プロセスがもはやメモリを割り当てることができないとき

+0

1バイト割り当てにも機能しません(上記の更新された質問)。 – ggkmath

+1

@ggkmath:問題ではありません。ヒープが破損している場合、ヒープは破損しています。 –

+0

実際、ヒープを信じる理由がすべて壊れています。 –

0

mallocリターンはあなたには、いくつかのメモリがある場合でも、その限界に達することができるsetrlimit

個々のプロセスによって設定されたもののようないくつかの限界に達しているため、おそらくmmapシステムコールが失敗したため、NULL他のプロセスが利用できる。

straceを使用して、システムコールをトレースし、どのコールが失敗しているかを調べることができます。

gcc -Wall -gでコンパイルしてください(デバッガgdbを使用してください)。

関連する問題