予想外のコア・ダンプ

ちょっとびっくりしてしまったのですが、おそろしく簡単なコードで実行がはじけます。
↓このコードでプログラムが停止してしまうというのには、どのような原因が考えられますでしょうか？

char *p;
p=(char *)malloc( [SIZE] );

ちなみに、プログラムが終了するのは、
p=(char *)malloc( [SIZE] );
の処理中であり、その後行うメモリ操作のせいではないようです。

実行環境は、、redhatlinux5.2です。。。

全部でそれだけのコードなんですか？
その前になんかしてないの？

heapcheckとかの関数はないの？

SIZEを[]で囲んでいるの？

コンパイル通るの？

[SIZE]って、実際のコードじゃなくて、「ここに確保するメモリ容量の
具体的数字が入るんだよ」という意味の、疑似コードなんじゃないの？

>8
なーるーへーそー。
>1
当該のmalloc()を呼んでる関数が凄く深いところにあれば、
ポインタpが取られずに変なところに代入しようとするかもねー。

？ ローカルスタックが足らないって意味？可能性は少しだけあるけど
たぶんヒープを壊してるんだろうから、ヒープチェックしてみるべき

メモリは、かなりの量を確保していました。
とりあえずは、ヒープチェックを試させて頂きます。

pにNULLが入ってたかどうか確認した？
ちゃんとエラーチェックしなくちゃだめよん。

size_t の最大値(UINT_MAX?) を超えるサイズとか？

＞１２さん
NULLチェックは全てのメモリ確保につけています。
どうやら、本当にあの行で止まっているみたいです。

＞１３さん
おそらく大丈夫です。32KByteを確保しています。

[SIZE]、マイナスになってるとか。
まぁ、それで死ぬとは思えんけど。

あっ…エラーを書けば良かったのですね。

Segmentation fault (core dumped)

ちなみに、[SIZE]はどのくらいなんでしょ？
malloc(10)とかやっても逝ってしまうのかな。

> 14
12 さんも指摘してますが、

ptr = malloc(size);
if (!ptr)
fprintf(stderr＠｀ "out of memory\n");

とかやってみるとあっさりわかるんでは？

過去の悪業 だろう。 mallocした配列を負方向に扱ったとかね。

.

だから、malloc()の行で止まってるんでしょ？
戻り値チェックできないんじゃないの？

お、失礼。
じゃ、malloc の引数が壊れている、というのはどう？
変数じゃなく、直接数字を書き込んでみるとか。

ＣプログラミングＦＡＱ の7.9と18.2に malloc にまつわる問題が書いてあります。
上の書籍をあたったら、原因が分かるかもしれませんよ。
それと確認しますが p = (char *)malloc(sizeof(p)); では無いですよね？
的外れなら、ごめんなさい。

#define MAXBUFFER 0XFFFF

↑数値はこれを使っています
p = (char *)malloc( MAXBUFFER );

…です。

今、過去の悪行をチェックしております（なにぶんソースが大きいので手間ですが、、、）

処理系（コンパイラのメーカ、商標など）と、ＯＳは何ですか？
それと、MAXBUFFERでmallocをコールしたのは、エラー以前でも
有るんですか？

それはヘタしたら負の値が渡ってるのでは……。

12です。
それ俺も考えたんだけど、size_tってunsigned intだよね。
仮に１６ビットの処理系として、かつsize_tをint(signedとして）だと
してもmalloc()自体はunsigned intとして受け取るから問題は無さ
そう。
またmalloc()が負の値と認識したとしたら、戻り値がNULLになって
しかるべきでしょう。
そういう訳で、可能性としては残ってるけど指摘するのを躊躇してた
のだが、同じ様に感じた方が居て少し感激です。（笑）

PC/AT互換+djgppの環境では，同じ問題を再現出来ませんでした。
#define MAXBUFFER 0XFFFFU もしくは p = (char *)malloc((size_t)MAXBUFFER);
で，明示的に unsigned型を渡したら如何でしょう？いや，思いつきなんですけどね。

その処理系知らないからなんだけど、
HeapCheckとかHeapWarkとかに相当するのは無いの？
無ければ、mallocをラップして、
MyAlloc(size＠｀Name)とか作って、メモリ確保と同時にリンクリスト
で自分で管理してみたら？ 暴走する直前でリンクリストを追跡させ
たらいいと思うよ。 って出来るならやってるか

まあ大きなソフト作る時は、自前のalloc/free系をラップする関数
作って、そっちで処理する癖付ける事だね。

結局どうなったんだろう……

この 0xFFFF に凄く違和感を感じます。
わざわざ64K-1にする理由がわかりません。

#define MAXBUFFER 0xFFFF
p = (char *)malloc(MAXBUFFER + 1);

もしくは

#define MAXBUFFER 0x10000
p = (char *)malloc(MAXBUFFER);

だとしっくりくるのですが。

>31
16bitマシンだったらunsigned intの範囲を超えますね。

malloc関数が悪いんでしょ。
昔、dosのファンクションコールでメモリ確保したときに、
あまりにもでかい量を指定したら、戻ってくる前に
メモリアロケーションエラーで止まったりしたし。