mallocで割り当てたメモリの質問
Hiroki.Y
と思いますが、このfreeを行わないで、そのプログラ
ムを終了させたら、割り当てたメモリは残ってしまう
のでしょうか？
私はWindowsNT4+VisualC++6でプログラムを作っている
のですが、freeを使わない（コーディングミス）時は
どのようになるか疑問になりました。
少し調べたのですが、Windowsだと解放されない場合
があるような記事がありました。他のOS（UNIX）で
はどうなんでしょうか。
また、メモリの消費量を知る方法は何かありますでし
ょうか？
ご指導をいただければ幸いです。
--
ひろき
Shigeru HANADA
"Hiroki.Y" wrote:
in <_kXb6.1352$t74.1...@newsall.dti.ne.jp>
> mallocで動的に割り当てたメモリは、freeで解放する
> と思いますが、このfreeを行わないで、そのプログラ
> ムを終了させたら、割り当てたメモリは残ってしまう
> のでしょうか？
基本的には、プロセス終了後にOSが開放するはずです。
> 私はWindowsNT4+VisualC++6でプログラムを作っている
> のですが、freeを使わない（コーディングミス）時は
> どのようになるか疑問になりました。
freeしないからといって、即コーディングミスという訳ではない
と思います。
「終了直前にfree」なんかは、ほぼ意味無いですから。
# mallocするだけして、死んでいくCGIなんかもありますし。
> 少し調べたのですが、Windowsだと解放されない場合
> があるような記事がありました。他のOS（UNIX）で
> はどうなんでしょうか。
GDIリソースなんかは、リークすることがあったような…。
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From : Shigeru Hanada
Mail : mo...@jcom.home.ne.jp
nori
"Hiroki.Y" <hir...@da2.so-net.ne.jp> wrote in message
news:_kXb6.1352$t74.1...@newsall.dti.ne.jp...
> mallocで動的に割り当てたメモリは、freeで解放する
> と思いますが、このfreeを行わないで、そのプログラ
> ムを終了させたら、割り当てたメモリは残ってしまう
> のでしょうか？
>
ので通常ほとんど問題ないでしょう（終了するプログラムなら…）。
> 私はWindowsNT4+VisualC++6でプログラムを作っている
> のですが、freeを使わない（コーディングミス）時は
> どのようになるか疑問になりました。
> 少し調べたのですが、Windowsだと解放されない場合
> があるような記事がありました。他のOS（UNIX）で
> はどうなんでしょうか。
>
システムにリソースを要求しておいて返却しないとリソースリーク
になると思いますが…。
> また、メモリの消費量を知る方法は何かありますでし
> ょうか？
>
お使いの環境ならば、CRT ライブラリが役に立つでしょう。
例えば、下記のようなコードで、デバッグビルドしてデバッグ実行
すると、デバッグウィンドウにメモリリークを検出したことが報告
されます。
--- code start
#define _CRTDBG_MAP_ALLOC
#include <malloc.h>
#include <crtdbg.h>
void main()
{
char *buf;
_CrtSetDbgFlag( _CRTDBG_LEAK_CHECK_DF |
_CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ) );
buf = malloc(10000);
}
--- code end
nori
NODA Takashi
"Hiroki.Y" <hir...@da2.so-net.ne.jp> writes:
> 私はWindowsNT4+VisualC++6でプログラムを作っている
> のですが、freeを使わない（コーディングミス）時は
> どのようになるか疑問になりました。
> 少し調べたのですが、Windowsだと解放されない場合
> があるような記事がありました。他のOS（UNIX）で
> はどうなんでしょうか。
去年の前半にかけての fj.comp.lang.c の記事のうちすくなくとも
8割ぐらいはこのことについて議論してたような気がします。
せっかく記事の検索をしたのなら、是非御覧になってみてください。
# もしや、また始まるのかしら…。あの Thread が。
▼△ のだたかし (NODA Takashi)
▽▲ mailto:no...@mb.neweb.ne.jp
Shiroh Sado
no...@mb.neweb.ne.jp氏の発言 <867l3jm...@azure.mb.neweb.ne.jp> より引用
>> 去年の前半にかけての fj.comp.lang.c の記事のうちすくなくとも
>> 8割ぐらいはこのことについて議論してたような気がします。
>>
>> せっかく記事の検索をしたのなら、是非御覧になってみてください。
>>
>> # もしや、また始まるのかしら…。あの Thread が。
いえ、そのことについては早々に決着が付いて、その後は、
プログラミングスタイルとして、freeすべきかどうかごちゃ
ごちゃしていただけのはずです。
最初の質問からたしか 1,2週間以内に、太田さんがサマリ記
事を出してくださっているので、それを読めば、必要な情報
はほぼすべて得られるはずです。
---
佐渡詩郎 (さど しろう) / e-mail : sa...@smlab.tutkie.tut.ac.jp
Yoshiki Kataoka
> > 私はWindowsNT4+VisualC++6でプログラムを作っている
> > のですが、freeを使わない（コーディングミス）時は
> > どのようになるか疑問になりました。
> freeしないからといって、即コーディングミスという訳ではない
> と思います。
> 「終了直前にfree」なんかは、ほぼ意味無いですから。
オススメの実験があります。
この「意味無い」の根拠を尋ねてみましょう。
非常に高い確率で UNIX が出てきます。
> # mallocするだけして、死んでいくCGIなんかもありますし。
これを CGI のバグと言わないところなど涙が出ます。
free すると自爆する処理系もあるそうですが．．．
Junn Ohta
kat...@ka2.so-net.ne.jpさんは書きました。
> この「意味無い」の根拠を尋ねてみましょう。
> 非常に高い確率で UNIX が出てきます。
逆ですね。「意味がある」の根拠を尋ねてみると組み込
み環境とか不完全なOSの例が出てくるだけでしょう。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Shinobu Kumaoka
Junn Ohta wrote:
> fj.comp.lang.cの記事<956i03$as7$1...@news01bj.so-net.ne.jp>で
> kat...@ka2.so-net.ne.jpさんは書きました。
> > この「意味無い」の根拠を尋ねてみましょう。
> > 非常に高い確率で UNIX が出てきます。
>
> 逆ですね。「意味がある」の根拠を尋ねてみると組み込
> み環境とか不完全なOSの例が出てくるだけでしょう。
「意味ない」と「ほぼ意味ない」の違いくらいは汲み取ってあげましょうよ。
--
cog...@sp.hudson.co.jp
株式会社ハドソン
研究開発本部 研究開発課
熊岡 忍(Kumaoka Shinobu)
Sugihara Yoshimi
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:957p44$471$1...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<956i03$as7$1...@news01bj.so-net.ne.jp>で
> kat...@ka2.so-net.ne.jpさんは書きました。
> > この「意味無い」の根拠を尋ねてみましょう。
> > 非常に高い確率で UNIX が出てきます。
>
> 逆ですね。「意味がある」の根拠を尋ねてみると組み込
> み環境とか不完全なOSの例が出てくるだけでしょう。
不完全なOSってどういう意味でしょうか？
「mallocしたメモリはOSが確実に開放する」
という話はきいたことはないです。
とりあえず完全なOSがひつようなのなら、
「UNIXの場合」
とかをつけといてほしいです。
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> 不完全なOSってどういう意味でしょうか？
ここでは「ANSI C言語仕様をきちんとサポートできない
OS」程度の意味です。
> とりあえず完全なOSがひつようなのなら、
> 「UNIXの場合」
> とかをつけといてほしいです。
「ANSI Cが動くOS」でじゅうぶんですね。
# ANSIは必要に応じてISOやJISに読み替えてください。
Takemoto,Satoshi
# 議論満載だったスレッド2本のうち、
# スレッド「スレッド「malloc & free」が読めない」は
# 私の記事の後ろに連なってくれてたのですが、
# 私自身は途中から読む気力が無くなって居りました。
# スレッド「スレッド「malloc & free」が読めない」が読めない....
で、うろ覚えで申し訳ないのですが....
Junn Ohta wrote:
> 「ANSI Cが動くOS」でじゅうぶんですね。
そうでしたか?
確か、ANSI標準ライブラリのほんの一部(limits.hとstdarg.hかなんか)を
サポートしていればANSI標準準拠の処理系(ANSI C)を名乗れるのでは
無かったでしたっけ?
つまり、ブートコードのみのOSでも「ANSI Cが動くOS」であるような....
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部 技術5課
Junn Ohta
take...@cv.sony.co.jpさんは書きました。
> 確か、ANSI標準ライブラリのほんの一部(limits.hとstdarg.hかなんか)を
> サポートしていればANSI標準準拠の処理系(ANSI C)を名乗れるのでは
> 無かったでしたっけ?
それはfreestanding environment(OSのない環境)での話
ですよね。なので、「ANSI Cの動くOS」という表現では
そちらのことを考えませんでした。
hosted environment(OS上)ではmalloc()とfree()が必須
であって、malloc()したものをfree()する必要があると
はどこにも書いてない、ということだったと思います。
Keiichi Suzuki
>>>>> "S" == "Sugihara Yoshimi" <sugi...@kyosai.or.jp>さま曰く...
S> 「mallocしたメモリはOSが確実に開放する」
S> という話はきいたことはないです。
この件に関して、プログラミングのポリシーには興味がないので、あく
までも現実問題として質問したいのですが...
S> とりあえず完全なOSがひつようなのなら、
S> 「UNIXの場合」
S> とかをつけといてほしいです。
こういう(確実に解放される)環境って非常に多くて、「の場合」の前に
つく部分がとっても長くて大変そうなので、短くて済むのであれば、逆
に「～以外の場合」と表現したいと思っています。
以前の議論の時も、良く知られているような環境で、プロセスが終了し
たときに解放してくれないという環境というのにどういうものがあるの
か、結局把握することが出来ませんでした。
`malloc' 以外の関数なりシステムコールなりについては実際に使うと
きに個別に調べますので、あくまでも `malloc' という ANSI C 準拠の
関数でメモリを確保して、そのままプロセスを終了した場合に、メモリ
が解放されない(ことがある)環境を教えてください。
--
鈴木圭一 / kei...@nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B
Takemoto,Satoshi
Junn Ohta wrote:
> それはfreestanding environment(OSのない環境)での話
> ですよね。なので、「ANSI Cの動くOS」という表現では
> そちらのことを考えませんでした。
ああ、そうでした。思い出しました。
で、結局のところ、言葉尻を捕らえてイチャモンを付けているだけ
なのですが(^^;、
freestanding environment の要求を充たしたANSI Cで書いたコードが
例えばμITRON上で動いている事は、
私の日常では極めてありふれた光景なので、
ちょっと茶々を入れてみました。
> hosted environment(OS上)ではmalloc()とfree()が必須
> であって、malloc()したものをfree()する必要があると
> はどこにも書いてない、ということだったと思います。
で、更に混ぜっ返します。(^^)
これも、FAQなのでしょうが
freestanding environment の要求を充たした処理系で、
malloc() という名称の、標準と異なる仕様の関数を提供する事は
許されているのでしょうか?
それとも、そんな事をした瞬間、ANSI Cを名乗れなくなるのでしょうか?
# あの2本のスレッドだけでも誰かFAQ集にまとめてくれないかなぁ。
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部
MAEDA Atusi (前田敦司)
> freestanding environment の要求を充たした処理系で、
> malloc() という名称の、標準と異なる仕様の関数を提供する事は
> 許されているのでしょうか?
> それとも、そんな事をした瞬間、ANSI Cを名乗れなくなるのでしょうか?
うーん。規格だと、
1. freestanding environmentは、言語仕様のうち特定のものを使っていない
strictly conforming programが動かなければならない。
2. strictly conforming programが動かなくなるような拡張はダメ
となっていますね。
で、malloc()は上の1.で除かれる部分に入ってるわけですが...
「1.を充たすプログラムは独自仕様malloc()が処理系に入っていても動くから
構わない」と解釈するのかなあ。malloc()を使っているプログラムはどうせ元々
動かないし。
> # あの2本のスレッドだけでも誰かFAQ集にまとめてくれないかなぁ。
元々FAQには入ってるんですよね。
http://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/C-faq/C-faq-07.html#7.24
前田敦司
Kazuya Maebashi
前回もこの辺はごちゃごちゃになってったような...
Junn Ohta wrote in message <9584nb$7k2$1...@ns.src.ricoh.co.jp>...
>hosted environment(OS上)ではmalloc()とfree()が必須
>であって、malloc()したものをfree()する必要があると
>はどこにも書いてない、ということだったと思います。
そうです。確かにどこにも書いてないですが、プログラムの終了時に
領域が開放されるとも書いてありません。メモリリークの起きる起きないは、
言語仕様の範囲外です。
ところで、free()の方には、(JIS X3010 7.10.3.2)
| 機能 free関数は、ptrが指す領域を開放し、その後の割付けに使用できる
| ようにする。(後略)
と明記してあるんですよね。とすると、例えばGC付きのCインタプリタを
実装したとして(全データ型にポインタであるかどうかを判別できるフラグを
付ければ実装は容易なはず。激しく効率悪いけど)、そいつのfree()の
実装が、
void free(void *p)
{
/* 何もしない */
}
てな感じになってたら、その処理系は規格準拠を名乗れないんでしょうか?
> 詳しい方
------------------------------------------------------------
前橋 和弥 maeb...@cse.co.jp
http://member.nifty.ne.jp/maebashi/
------------------------------------------------------------
Junn Ohta
maeb...@cse.co.jpさんは書きました。
> そうです。確かにどこにも書いてないですが、プログラムの終了時に
> 領域が開放されるとも書いてありません。メモリリークの起きる起きないは、
> 言語仕様の範囲外です。
そういうことですね。きちんとfree()したってメモリー
リークするかもしれないし。
Yoshiki Kataoka
> そういうことですね。きちんとfree()したってメモリー
> リークするかもしれないし。
free は使ってはならない関数なのですね。
Yoshiki Kataoka
> 「ANSI Cが動くOS」でじゅうぶんですね。
>
> # ANSIは必要に応じてISOやJISに読み替えてください。
少なくとも JIS には、exit が free 相当の動作を行うとは
どこにも書いてありません。規格書を手元に置かずに
ANSI C を謳う議論なので、その程度の議論との認識と
予めご承知おきされることをおすすめします。
# 私と名前の似ているあの人でさえ、
# ここの証明はできていませんから
Junn Ohta
kat...@ka2.so-net.ne.jpさんは書きました。
> 少なくとも JIS には、exit が free 相当の動作を行うとは
> どこにも書いてありません。
「exitがfree相当の動作を行う」必要などどこにもない
ことは前回ちゃんと説明したのですけどね。
今回の話は
(1) ANSI Cの規格範囲内ではmalloc()したメモリーを明
確にOSに返す手段が存在しない。
(2) したがってANSI Cがきちんと動くOSならfree()しよ
うがしまいがメモリーリークなどするはずがない。
(3) 逆にメモリーリークするならそんなOSは「ANSI Cが
きちんと動くOS」ではない。
だけのことですね。
Kazuya Maebashi
Junn Ohta wrote in message <959ecl$kri$1...@ns.src.ricoh.co.jp>...
>(1) ANSI Cの規格範囲内ではmalloc()したメモリーを明
> 確にOSに返す手段が存在しない。
規格には、free()でOSに返してはいけないとも書いてないと思いますが。
>(2) したがってANSI Cがきちんと動くOSならfree()しよ
> うがしまいがメモリーリークなどするはずがない。
なぜですか?
>(3) 逆にメモリーリークするならそんなOSは「ANSI Cが
> きちんと動くOS」ではない。
なぜですか?
# 私は、「必ずfree()しろ」と主張したいわけではないです。
Junn Ohta
maeb...@cse.co.jpさんは書きました。
> 規格には、free()でOSに返してはいけないとも書いてないと思いますが。
はい。要するに、返すとも返さないとも書かれていない。
だから返却されることは期待できない、というわけです。
> >(2) したがってANSI Cがきちんと動くOSならfree()しよ
> > うがしまいがメモリーリークなどするはずがない。
> なぜですか?
free()がOSにメモリーを返すとは限らないのだから、そ
ういうメモリーもきちんと取り戻すのが「ANSI Cがきち
んと動くOS」の当然の務め、だからですね。
> >(3) 逆にメモリーリークするならそんなOSは「ANSI Cが
> > きちんと動くOS」ではない。
> なぜですか?
ANSI Cではfree()することを要求されていないのだから、
free()しないプログラムがあったくらいでメモリーリー
クする(つまりいずれOSごと落ちる)ようなOSは「ANSI C
がきちんと動くOS」とはいえない、からですね。
Dairyo Gokan
-----------------------------------------------------------------------
> (1) ANSI Cの規格範囲内ではmalloc()したメモリーを明
> 確にOSに返す手段が存在しない。
> (2) したがってANSI Cがきちんと動くOSならfree()しよ
> うがしまいがメモリーリークなどするはずがない。
> (3) 逆にメモリーリークするならそんなOSは「ANSI Cが
> きちんと動くOS」ではない。
なんだか前回の蒸し返しって(T_T)気がしますが ...
「ANSI-C」では規格準拠の実装として、「OS」上で稼働することを
求めていますか？ また「OS」の定義とは？
「ANSI C」では、malloc()関数が「OS」からメモリを取得すること
と限定しているのですか？
exit()の仕様は、プログラムの終了を宣言し、main()の呼び出し元
に対してexit()の引数として渡された値を返すだけだと思います。
それ以外の処理は、C言語で生成したコードを実行している「OS」が
たまたまそのような機能を持っており、勝手に行なわれる場合に過ぎ
ないことであって、それらは言語の機能ではありません。
exit()関数自体が、『確実にメモリを返すように』実装されている
なら、『確実にメモリを返さない』実装を選択することも可能なはず
ですが、プロセス終了時にOSがプロセスの使っていたメモリを自動的に
開放する機能を持っていれば、後者のような言語仕様として、実装を
つまり、exit()後にメモリ開放されるかどうかは、Cの実装に依存
しておらず、OSの機能に依存しているわけです。
+---------------------------------------------------------------------+
| From : Dairyo Gokan ( 後神 大陵 ) |
| Org. : Hitmark Computer Corporation ( ヒットマークコンピュータ ) |
| Adrs : 13256 Northup Way Suite 3, Bellevue WA 98005 |
| TEL:425-649-8808 FAX:425-649-9001 mailto:na...@can.bekkoame.ne.jp |
+---------------------------------------------------------------------+
MAEDA Atusi (前田敦司)
> なんだか前回の蒸し返しって(T_T)気がしますが ...
その割に前回の成果が反映されてない(T_T)のはなぜ?
> 「ANSI-C」では規格準拠の実装として、「OS」上で稼働することを
> 求めていますか？ また「OS」の定義とは？
前回も出てきた話です。前回のスレッドか規格書読んでください。
> 「ANSI C」では、malloc()関数が「OS」からメモリを取得すること
> と限定しているのですか？
前回も出てきた話です。前回のスレッドか規格書読んでください。
> exit()の仕様は、プログラムの終了を宣言し、main()の呼び出し元
> に対してexit()の引数として渡された値を返すだけだと思います。
ちゃいます。「仕様はこうだ」とおっしゃるなら当て推量せずにまず規格書読
んでください。
前田敦司
MAEDA Atusi (前田敦司)
> 前回も出てきた話です。前回のスレッドか規格書読んでください。
補足: 前回のスレッドを読んでない人は投稿するなという意味じゃないです。
前回のスレッドに参加してたにもかかわらず、なんで同じことを初めっから蒸
し返そうとするの？ という事。
前田敦司
Hoshi Takanori
In article <959jcq$mbl$1...@ns.src.ricoh.co.jp>
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> free()がOSにメモリーを返すとは限らないのだから、そ
> ういうメモリーもきちんと取り戻すのが「ANSI Cがきち
> んと動くOS」の当然の務め、だからですね。
ANSI C 規格 (正確には、ぼくが読んだのは JIS X 3010 だけど...)
が言及しているのは、「OS」でわなくて、「ホスト環境」です。
で、exit() 関数の説明には、「制御がホスト環境に復帰する。」と
書いてありますけど、その後ホスト環境がどうすべきかは、規格には
書いてありません。(書き忘れたわけぢゃなくて、C 言語の規格の
範囲外だから、あえて書かなかったんです。念のため。)
つまり、当該プログラムを再度実行できる必要もないし、別の
プログラムを起動できる必要もないし、それどころか、制御が戻って
きたら、マシンが爆発しちゃっても規格上は構わないわけです。
もちろん、ふつ～は leak しないことを期待しますが、それは
あくまで quality of implementation issue に過ぎません。
ほし
Takuya OKAHISA
<956i03$as7$1...@news01bj.so-net.ne.jp>の記事において
kat...@ka2.so-net.ne.jpさんは書きました。
>> この「意味無い」の根拠を尋ねてみましょう。
>> 非常に高い確率で UNIX が出てきます。
何と言いますか、Win32 がなかなか出て来ないところが、
Windows プログラマの伝説体質を如実に物語っているよう
な気がするのですね。と、いうわけで、プロセス終了でメ
モリが開放される環境に Win32 を付け加えておいてあげ
てください。あまりに Windows が哀れ...
# 組み込みのことはよく知らないです。
>> > # mallocするだけして、死んでいくCGIなんかもありますし。
>>
>> これを CGI のバグと言わないところなど涙が出ます。
うーん、プログラマがその環境なら OK であると意識し
ているのなら、それはバグとは言わないんじゃないでしょ
うか? 移植性が低いだけで。
移植性が低いとはバグのあることであるということなの
でしたらバグなのかもしれない。
>> free すると自爆する処理系もあるそうですが．．．
そういうプログラムを書く学生なら居ます(^^; ある環
境だと２重に free してもクラッシュしないのですが、そ
れを linux などに持ってきて、
「先生、プログラムが終了する直前にクラッシュします」
と苦渋に満ちた表情でのたまうのでありまする。あぁぁ。
いや、頑張ってる良いやつなんだけど(^^;;;
# いまシーズンたけなわ...
--
Email: oka...@cs.ehime-u.ac.jp
Sugihara Yoshimi
> fj.comp.lang.cの記事<958ull$18p$1...@nw041.infoweb.ne.jp>で
> maeb...@cse.co.jpさんは書きました。
> > そうです。確かにどこにも書いてないですが、プログラムの終了時に
> > 領域が開放されるとも書いてありません。メモリリークの起きる起きないは、
> > 言語仕様の範囲外です。
> そういうことですね。きちんとfree()したってメモリー
> リークするかもしれないし。
free()してもリークする環境だと
「free()してもそのメモリ領域はmalloc()出来ない」
ですよね。
ＡＮＳＩでは「free()したら再度malloc出来るようになる」
と定義されてるはずなので
ＡＮＳＩ準拠とはいえないのでは？
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> free()してもリークする環境だと
> 「free()してもそのメモリ領域はmalloc()出来ない」
> ですよね。
そんなことはないです。
# なるほど、sugiharaさんはここで勘違いされているの
# ね。それなら以下の説明で納得してもらえそう...。
UNIXで最初に提供されたmallocインターフェースは次の
ようなデザインで実装されていました。
# ANSI Cのmallocインターフェースの仕様も、このよう
# な実装を想定して書かれたプログラムがおかしな動作
# を起こさないように作られていますね。
(a) mallocインターフェースは独自の空きメモリープー
ルを管理している。
(b) malloc()は要求されたメモリーをこのメモリープー
ルから割り当てて返す。メモリープールに空きが足
りなければOSからメモリーをもらってメモリープー
ルを拡張する。
(c) free()は渡されたメモリーをこのメモリープールに
返す。
(d) mallocインターフェースはこのメモリープールをOS
にわざわざ返却することを期待されていない。プロ
セスが終了したときにOSが勝手に回収する。
こういうデザインで作られたmallocインターフェースで
は、「free()してもリークする」可能性があるのは(d)
の回収に失敗するときだけです。一方「free()したメモ
リーがmalloc()できない」のは(a)～(c)の流れに問題が
あったときです。このふたつの事象は独立なので、
> free()してもリークする環境だと
> 「free()してもそのメモリ領域はmalloc()出来ない」
という因果関係は、少なくともこういうデザインで実装
されたmallocインターフェースでは存在しないことにな
るでしょう。
Kazuo Fox Dohzono
In article <95amqu$vft$1...@csgw2.cs.ehime-u.ac.jp>
oka...@cs.ehime-u.ac.jp (Takuya OKAHISA) writes:
> # 組み込みのことはよく知らないです。
私が最近仕事で使っている環境では free した領域は再度 malloc で取得可能
ですが, プロセスが終了することを想定していないため後始末は実装してあり
ません. で,
> 「先生、プログラムが終了する直前にクラッシュします」
終了しないという手がありますね :-)
# 原因が
#
# > ２重に free
#
# ならこちらの環境では二回目の free (確か undefined behavior) で履歴を
# 表示して panic します.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(4/1449/3742)
KATAYAMA Yoshio
ho...@sra.co.jp (Hoshi Takanori) writes:
>> free()がOSにメモリーを返すとは限らないのだから、そ
>> ういうメモリーもきちんと取り戻すのが「ANSI Cがきち
>> んと動くOS」の当然の務め、だからですね。
>ANSI C 規格 (正確には、ぼくが読んだのは JIS X 3010 だけど...)
>が言及しているのは、「OS」でわなくて、「ホスト環境」です。
ISO:IEC 9899 では、
In a freestanding environment (in which C program
execution may takeplace whithout any benefit of an operating
system), 以下省略
と、operating system に「言及」しています。
＃ JIS X 3010 は手元にないので分かりません
>つまり、当該プログラムを再度実行できる必要もないし、別の
>プログラムを起動できる必要もないし、それどころか、制御が戻って
>きたら、マシンが爆発しちゃっても規格上は構わないわけです。
>もちろん、ふつ～は leak しないことを期待しますが、それは
>あくまで quality of implementation issue に過ぎません。
確かにそうですが、そのような処理系は非常に使い難いでしょうね。
malloc() でメモリーを獲得している状態で異常終了してしまうと、
（OS での）メモリーリークが起きてしまうことになります。
ライブラリーが（プログラマーに見えない形で）malloc() を使ってい
る場合もありますから、「malloc() を使っていないプログラムだから
安心」ということもないですね。
私はデバッグ無しで、一発でプログラムを正常に動作させるなんてこと
はできないので、このような処理系は使いたくないですね。
＃他のプログラムで解放できるリソースが残るのは我慢できますが、、、
--
片山＠ＰＦＵ
Sugihara Yoshimi
> fj.comp.lang.cの記事<95aodi$45p$1...@news.kyosai.or.jp>で
> sugi...@kyosai.or.jpさんは書きました。
> > free()してもリークする環境だと
> > 「free()してもそのメモリ領域はmalloc()出来ない」
> > ですよね。
> そんなことはないです。
> UNIXで最初に提供されたmallocインターフェースは次の
> ようなデザインで実装されていました。
・・・以下略・・
> > free()してもリークする環境だと
> > 「free()してもそのメモリ領域はmalloc()出来ない」
> という因果関係は、少なくともこういうデザインで実装
> されたmallocインターフェースでは存在しないことにな
> るでしょう。
ということで、それは「「「ＵＮＩＸ」」」に限定した話ですよね
＃多くのＯＳがＵＮＩＸと同じスタイルだとおもいますが
ＡＮＳＩの規格に
「「malloc()で取得したメモリブロックはプロセスの終了とともに開放される」」
とはないので、
malloc()で確保したメモリブロックがプロセスが終了した後も
存在しつづけたとしてもＡＮＳＩ準拠といえるのでは？
＃そういう環境が良いとか、あるとかというわけではないですが
ともかく
「「malloc()で取得したメモリブロックはプロセスの終了とともに開放される」」
という規定がＡＮＳＩに「「ある」」かのような説明が気に入らないだけですので
（＾＾；；
Takemoto,Satoshi
"MAEDA Atusi (前田敦司)" wrote:
> 元々FAQには入ってるんですよね。
> http://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/C-faq/C-faq-07.html#7.24
「え～っ!?、fj.comp.lang.c の FAQ が有るのぉ?」
と、喜び勇んで見に行ってしまいました。
.... comp.lang.c の FAQ ですね。(-_-;
comp.lang.c FAQ は皆さん、あちこちで翻訳されていて、
検索で引っかかる上位2つくらいは読ませていただいた事が有ります。
でも、ヌルポインタに割いている分量に比べてmalloc&freeの扱いは、
あまりにそっけなく感じます。
前田(敦)さんが上記の様におっしゃるという事は
「comp.lang.c FAQ に書いてある以上の情報はfjでは出ていない」
という事なのかもしれないのですが、あれだけ盛り上がったのですから
総括とういものが有っても良いじゃないかとは思います。
# 何か、こう「始末の心」といったような、
# 日本的なイズムも背景に有るような気がしましたし、
# その辺も含めて、どなたか....
# ....あくまで他人頼みな私。(^^:
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> リークしているのに再割り当てできるんですか？
というか「再割り当て」をしようとしている時点ではま
だいかなる「リーク」も発生していないわけです。だか
ら「リークしているのに再割り当て」という状況自体に
意味がないですね。
> ということで、それは「「「ＵＮＩＸ」」」に限定した話ですよね
違います。UNIXに限定した話ではない、ということを示
すためにいろいろ書いたのですが...。
> malloc()で確保したメモリブロックがプロセスが終了した後も
> 存在しつづけたとしてもＡＮＳＩ準拠といえるのでは？
「ANSI準拠」ではなくて「ANSIとは無関係」ですね。
> ともかく
> 「「malloc()で取得したメモリブロックはプロセスの終了とともに開放される」」
> という規定がＡＮＳＩに「「ある」」かのような説明が気に入らないだけですので
> （＾＾；；
そういう説明をしたつもりはないのですが。私の説明の
どの部分がそうですか?
私がいいたいのは
・ANSI Cの環境で
・free()すればメモリーリークしないのであれば
・free()しなくてもメモリーリークしないだろう
ということだけです。あとは枝葉です。
Narita Takaoki
Takemoto,Satoshi <take...@cv.sony.co.jp> wrote in message news:3A792720...@cv.sony.co.jp...
> 竹本です。
：
> 「comp.lang.c FAQ に書いてある以上の情報はfjでは出ていない」
> という事なのかもしれないのですが、あれだけ盛り上がったのですから
> 総括とういものが有っても良いじゃないかとは思います。
>
> # 何か、こう「始末の心」といったような、
> # 日本的なイズムも背景に有るような気がしましたし、
> # その辺も含めて、どなたか....
> # ....あくまで他人頼みな私。(^^:
もしかして・・・「私のこの心に引っかかっているリークっぽい
代物を free してくれ」とか？もしくは、「私のこの話題に関す
る心のプロセスを exit してくれ」とか？
やっぱり自分で free するか exit してみるのがかっちょええん
ではなかろか。他人に kill -KILL されて脳死したりしたら大変
だし。(^^;;;;;;;;;;;;
--
Narita Takaoki @A.I.SOFT,INC.
『１０分間で決断し、短い理由を添えよ』
Hiroshi Toyoshima
では、
--
Hiroshi Toyoshima mailto:hiroshi@t_h_r_o_w.s_p_a_m.lib.bekkoame.ne.jp
MAEDA Atusi (前田敦司)
> でも、ヌルポインタに割いている分量に比べてmalloc&freeの扱いは、
> あまりにそっけなく感じます。
うーん。そうですか？ 5章ヌルポインタ20問、7章メモリ割り付けのうち
malloc/free/allocaのたぐいが出てくるのは15問。まあそんなに差はない気が
します。
> 前田(敦)さんが上記の様におっしゃるという事は
> 「comp.lang.c FAQ に書いてある以上の情報はfjでは出ていない」
そこまで一般化するつもりは毛頭ございませんが(^^;)。
今回に限って言えば、私としてはあのFAQの答 以上の内容は結局出なかったん
じゃないかと思います。
> という事なのかもしれないのですが、あれだけ盛り上がったのですから
> 総括とういものが有っても良いじゃないかとは思います。
総括はしてたんじゃないですか? 何度も何度も(笑)。
;;; 筑波大学 電子・情報工学系(学術情報処理センター)
;;; 前田敦司 (MAEDA Atusi) ma...@cc.tsukuba.ac.jp
KATAYAMA Yoshio
ma...@cc.tsukuba.ac.jp (MAEDA Atusi (前田敦司)) writes:
>> という事なのかもしれないのですが、あれだけ盛り上がったのですから
>> 総括とういものが有っても良いじゃないかとは思います。
>総括はしてたんじゃないですか? 何度も何度も(笑)。
竹本さんが仰りたいことは、
In article <95amqu$vft$1...@csgw2.cs.ehime-u.ac.jp>,
oka...@cs.ehime-u.ac.jp (Takuya OKAHISA) writes:
>な気がするのですね。と、いうわけで、プロセス終了でメ
>モリが開放される環境に Win32 を付け加えておいてあげ
>てください。あまりに Windows が哀れ...
が入った FAQ がほしいということでわないかと。
--
片山＠ＰＦＵ
Junn Ohta
ka...@pfu.co.jpさんは書きました。
> >な気がするのですね。と、いうわけで、プロセス終了でメ
> >モリが開放される環境に Win32 を付け加えておいてあげ
> >てください。あまりに Windows が哀れ...
> が入った FAQ がほしいということでわないかと。
というか、前回の議論では、free()しないとリークする
OSの実例なんてのはひとつも出てこなかったんですから、
まとめるまでもないんです。Win32だろうがWin16だろう
がMS-DOSだろうがみんな大丈夫。
malloc()/free()でリークする例として出てきたのは特
殊な組み込み環境だけで、もちろんANSI Cではないのだ
から名前がmalloc()/free()だっただけのこと、それ以
外はどれも何ちゃらAlloc()/何ちゃらFree()のたぐいで、
malloc()/free()ではありませんでした。
Yoshiki Kataoka
> 「exitがfree相当の動作を行う」必要などどこにもない
> ことは前回ちゃんと説明したのですけどね。
>
> 今回の話は
>
> (1) ANSI Cの規格範囲内ではmalloc()したメモリーを明
> 確にOS
はい、さようなら。
私が調べた範囲では malloc / free は OS を前提としません。
↑
規格書をね。 ANSI C としきりに言う誰かさんと違って。
コメントしようにも、こんな作り話では箸にも棒にもかかりません。
うっかりミスならともかく、今のあなたは違いますよね。
元記事の環境に限定するなら LIBC*.LIB/MSVCRT.DLL でしょうが、
突然「OS」になっているところにも恣意的なものを感じます。
こちらにも言いたいことはありますが、
内容以前の欠陥を直してきて頂くのが先です。
Junn Ohta
kat...@ka2.so-net.ne.jpさんは書きました。
> 私が調べた範囲では malloc / free は OS を前提としません。
規格の中には出てきません。でもmalloc/freeというイ
ンターフェースはOSの存在が前提としてあるからこそあ
あいう仕様になっている、という話。だからそれでは反
論になってません。
前回もそうだったけど片岡さんてばぜんぜん人の書いた
記事を理解してないのね。
> 元記事の環境に限定するなら LIBC*.LIB/MSVCRT.DLL でしょうが、
違うでしょ。リークするかどうかはOSにとっての話。実
行時ライブラリーじゃありません。
Kusakabe Youichi
せっかく期待したのですから、
このさい竹本さんが中心になって作るというのはどうでしょう? :)
> でも、ヌルポインタに割いている分量に比べてmalloc&freeの扱いは、
> あまりにそっけなく感じます。
きっと日本人の好みなのでしょう :)
malloc&freeのほうがナルポインターよりも。
というわけで、日本人...というかfjユーザー向きのFAQを作ってください > 竹本
さん
> # 何か、こう「始末の心」といったような、
> # 日本的なイズムも背景に有るような気がしましたし、
でもBASICで「DIM」で確保したのを終了時に解放したがるひとは見たことないし、
(あれ?MSじゃない環境ではあれは宣言文であって途中には書けないんでしたっけ?)
# とりあえずこの「malloc&free」の分、1件分だけでもいいので、
# 「過去の記事を読め」ではなく「この文章を読め」で済むような
# (とりあえず現時点までのものでもいいので)「まとめ」があったほうが
# いいのでは?
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shiroh Sado
スレッド「Re: (FAQ listを)竹本さんが中心になって作るというのはどうでしょう?」での
vo...@merope.pleiades.or.jp氏の発言 <void-02020...@newshost.ryukyu.ad.jp> より引用
>> せっかく期待したのですから、
>> このさい竹本さんが中心になって作るというのはどうでしょう? :)
(略)
>> きっと日本人の好みなのでしょう :)
>> malloc&freeのほうがナルポインターよりも。
>> というわけで、日本人...というかfjユーザー向きのFAQを作ってください > 竹本
>> さん
(略)
>> # とりあえずこの「malloc&free」の分、1件分だけでもいいので、
>> # 「過去の記事を読め」ではなく「この文章を読め」で済むような
>> # (とりあえず現時点までのものでもいいので)「まとめ」があったほうが
>> # いいのでは?
今月17日で、件のthred発足から、めでたく1周年を迎えますが、
queenを漁って、現時点どころか、thred開始から、たったの2週
間分ぐらいを元に、自分がいい加減ですが cut & paste して、
図々しく edit させていただいたものを下記につけます。
何かの足しになれば幸いですが、私の注意力不足により、デマが
発生していましたら、大変申し訳ありません。
---------------------------------------------------------- ここから
［最初の質問］
Q. C言語の本をにはたいていmallocしたメモリーをもう使わない
なら放っておけば終了時に自動的に解放されるので明示的に
freeしなくても良いと書いてあるのですが、先日ある雑誌を
見ると明示的にfreeしないとメモリーリークになると書かれ
ていました。どちらが正しいのでしょうか。
<38AB7D...@geocities.co.jp>
［最初の回答］
A. まともなOSなら、malloc()から呼ばれたシステムコール
で確保されたメモリーはプログラムの終了時には解放さ
れるはずです。なぜかというと、OSをそのように作って
おかないといろいろな問題が起きて困るからです。した
がって、陽にfree()する必要はない、というのが一般解
です。
<88g10k$j01$1...@ns.src.ricoh.co.jp>
［プログラミングスタイルとして］
A1. 終了時に解放されるかどうかはOSの機能次第ですが、長時間動き
続けるソフトを書くときそんなことをしたらえらいことになるの
で、必ず解放する習慣をつけるべきです。
<88fvdm$b...@utogw.gssm.otsuka.tsukuba.ac.jp>
A2. そういう習慣を身につけることの正しさはともかくとし
て、何でも安全側に振っておけば問題ないとしてシステ
ムを理解しようとしない、あるいは理解せずにすませて
しまう姿勢にも問題があるよなあ、と私はつねづね思っ
ているのでした。
で、こういう質問にはやっぱり「システムがきちんとめ
んどうはみてくれるけど、だからってさぼっちゃだめだ
よ」と答えるべきなんでしょうか...。
<88gghd$naa$1...@ns.src.ricoh.co.jp>
A3. 基本的にはいらなくなったら free ですが、結構しつこく再
利用出来ないかとか考えるので、実際にはそんなに単純
にポイするわけではありません。結構骨までしゃぶろうとす
る方かも。場合によっては、アロケータの自作も考慮します
が、そんなにあることではないかな。
あと、広義のリークを防ぐ注意点として、基本的に使い終わ
ったら free を心がけるのもありますが、もっと大切なのは、
制御の流れをリークしていたら何処が漏れているかすぐ分
かる様なものに設計しておくということの方が、ずっと重要
ですね。どちらかというと、malloc せざる得なくなった時は、
こっちの方に注意がいっているかも。
どんなに注意していても、何千行も書いていると、大抵リー
クする（もしくはオーバーランやら何やらする）。だから、これ
らがすぐどこで起こるか分かる様に設計するというのがあと
あとの労力を削減してくれます。これはモジュール別のテス
トなども視野に入れた上での話です。
<8a6tub$831$1...@epsongw6.epson.co.jp>
A4. どんなときにfree()が必要かはトップダウンに決まって
くるわけで、それに従って書いていれば必要なfree()は
書かれて、不要なfree()は書かれません。
<8b2muk$16q$2...@ns.src.ricoh.co.jp>
［規格(1)］
A.規格では「malloc() で獲得した領域を free() で解放しなければなら
ない」のような規定はありません。規定されていない以上、free() で
解放するかしないかは、プログラマーの自由です。
<KATE.00Fe...@yamato.trad.pfu.co.jp>
［規格(2)］
malloc() で割付けた領域を OS に返すことについては、規格(*)では一
切述べていません。それどころか、malloc() で割付けた領域を解放し
なければならないとも規定していません。
* ISO/IEC 9899 や JIS X 3010 などの C 言語規格（以下同じ）
規格は、プログラムに対する規定と処理系に対する規定の両方を含んで
いますが、プログラムに対する規定のことでしょうか。いずれにしても、
「暗黙のうちに定められて」いるものはありません。あるとするならば、
それは規格の不備です。
malloc() で割付けた領域を解放しなければならないと規定されていない
のですから、解放せずに終了するプログラムでも strictly conforming
program にできます。
conforming hoted implemetation は、すべての strictly conforming
program を受け付けなければなりませんから、malloc() で割付けた領
域を解放せずに終了するプログラムも受け付けなければなりません。
受け付けた結果、プログラム終了後に何が起こるかは規格の範疇外です。
その実装の環境（OS など）で規定されるべきことです。
極端な話、exit(0)（main() から return 0;）以外ではリブートしてし
まうような環境であっても、conforming hoted implemetation とする
ことは可能です。
しかし、そのような環境が実在しても「互換性のために exit(0) しな
ければならない」という議論にならないのと同様に、「互換性のために
free() してからプログラムを終了しなければならない」という議論に
はなりません。
<KATE.00Fe...@yamato.trad.pfu.co.jp>
［規格(3)］
Q. ところで、「互換性」ではなく「移植性」を考慮した場
合でも主張に変化はありませんか?
A. 今回の件に関していえば、
conforming hosted implementation は strictly conforming
program を何回実行しようとも、ダウンしたり動作が不安定になっ
たりしないものである
という仮定は合理的な仮定であると考えていますので、主張に変化はあ
りません。
<KATE.00Fe...@yamato.trad.pfu.co.jp>
［質の悪い環境］
Q. 少なくとも、freeを使う事により、使える環境が増えるのなら、
移植性が向上したといえます。freeを使ってメモリーを開放す
ることにより、使えなくなる環境は、ないと思いますが。
A. 「質の悪い」実装でもプログラムがまともに動くように
するために、そのインターフェースが本来意図していた
設計思想を曲げて利用することをもって「移植性が向上
した」とおっしゃるのでしょうか?
そういう「質の悪い」実装でプログラムをまともに動か
すためには、その実装で考慮すべき問題(free()のほか
にもきっとたくさんあるでしょう)を切り分けて、条件
コンパイルなどで対応すべきだと思います。それでこそ
「移植性の高い」プログラムではないですか?
「より多くの環境で同じ字面のプログラムが(効率を無
視して)そのまま動く」ことをもってプログラムの「移
植性が高い」とする見かたには賛成できません。
<88o3qp$6ua$3...@ns.src.ricoh.co.jp>
［exitの説明］
Q. exitの説明には、全てのメモリを解放することはかか
れていないと思うのですが。
A. 書かれている環境もあります。書かれていないとすれば、
それはプロセス終了時にOSが後始末として行うべき処理
のひとつであって、ユーザープロセスの側で行う処理で
はないからでしょう。
「exit()を行うとそのプロセスが占めていたメモリー空
間はすべてOSに返却される」というのと同じレベルの話
ですから、exit()の説明にわざわざ書かれていなくても
おかしなことではありません。
<88onmk$chu$1...@ns.src.ricoh.co.jp>
［OSに依存?］
Q. free しなくてもメモリリークしないとかいう人がいますが、
それは自分の使うＯＳ（UNIX や NT） に偏った話を
しているからじゃないですか？
A. free()というのはそもそもOSにメモリーを返却するため
の関数ではなくて、malloc()/free()パッケージにメモ
リーを返却するための関数です。
<88kdgt$2e2$1...@ns.src.ricoh.co.jp>
［malloc は freeする仕様?］
Q. でも malloc は free する「仕様」の関数です。
A. これは正しくないのではないですか?
malloc()がシステムからメモリーをもらってくる関数で
あることは正しいのですが、free()はその逆をする関数
ではないのです。free()はむしろ、そのあとでmalloc()
を行ったときに再確保されるメモリーを用意する関数と
とらえたほうがいいでしょう。
つまりmalloc()とfree()は対称で対等な関係にあるわけ
ではないということです。
malloc()したものは無条件にfree()すべきだと教えるこ
とは、その非対称性に気づくチャンスを奪うことにもつ
ながりますよね。
# もちろん、malloc()で使い終わったメモリーはその段
# 階でfree()するのがよい習慣だという点については何
# の異議もありません。
<88h0ce$rgp$2...@ns.src.ricoh.co.jp>
［実装］
Q. 要するに、freeを使わないためにトラブルが起こった
場合は、プログラマーの責任だと思います。
A. 「プロセスの終了前に自分ですべてfree()すればOSにす
べてのメモリーを返却したことになる」というmalloc()
/free()の実装にはどんなものがあり得るか考えてみま
した。可能性があるとしたらこんなものでしょう。
(1) malloc()とfree()はじつはOSのメモリー確保/解放
のシステムコールをそのまま呼んでいるだけ。
これでは細かいメモリー確保/解放のタイミングで
システムコールが発生するわけで、まったく非効率
です。しかも解放にfree()を使う以上、正しく解放
されたかどうかをチェックする方法が存在しないわ
けで、危険このうえない。こんな形でシステムコー
ルにmalloc()/free()の皮をかぶせるというのはあ
ってはならないことです。
(2) malloc()は必要に応じて大きな単位でOSからメモリ
ーを確保して、それを細切れにして呼び出し側に返
す。free()は返されたメモリーがまとまった単位に
なるとOSにそれを返す。
境界条件が存在することになり、その境界で細かい
malloc()/free()を繰り返すと効率が落ちます。こ
のときの効率はmalloc()が内部でメモリー管理をし
ている分だけ(1)よりさらに悪くなります。
(3) (2)と同じだが、free()ですべてのメモリーが解放
されたときだけOSにそれらのメモリーを返す。
本質的に(2)と同じで、メモリーがひとつも確保さ
れていない状態で細かいmalloc()/free()を繰り返
すと(2)と同じ状態になります。
<88mle0$mnm$1...@ns.src.ricoh.co.jp>
［道徳］
Q. malloc()したものはfree()するのが当然であって、
それはルールとして守らなければならない。free()
しなかったときにどうなるかなどと考えたりしては
いけないのではないか?
A. 技術を道徳に置き換えて論ずるのは百害あって一利なし
です。やめたほうがいいでしょう。
［個別の環境ではどうなるか］
Q. freeせずに終了すると、個別の環境ではどうなるか?
A1. いままで出た情報をまとめると、malloc()したメモ
リーをfree()せずに終了した場合、
(a) UNIX、MS-DOS、Windows95/98/NTならメモリーリー
クは起きない
(b) ANSI Cならメモリーリークは起きない
(c) (malloc()/free()という関数仕様から)まともなOS
とまともな言語処理系の組み合わせならメモリーリ
ークは起きないと期待してよい
(d) 上記のいずれでもない環境ではメモリーリークを起
こす可能性がある(しかしfree()したからといって
メモリーリークが起きないとは保証できない)
といったところでしょうか。
<88qimd$1hu$1...@ns.src.ricoh.co.jp>
［MS-DOSでも大丈夫?］
Q. 私、Unixであれば大丈夫なのは知っていますがDOSな
んかだと怪しそうなんで絶対安全サイドで作っちゃうと思うな。
A. じつはDOSの場合は、free()せずに終了してしまっても
まったく安全なんです。
DOSは640～768KBのコンベンショナルメモリーというも
のをもっていて、すべてのプロセスはその中で実行され
ます。そのコンベンショナルメモリーの先頭にはDOSの
システムやデバイスドライバー、コマンドインタプリタ
ーなどが常駐していて、プログラムを実行するとそれら
を除いた空きスペース全体がどかんとプロセスに渡され
ます。プロセスはその内部をmalloc()などで自由に使っ
てよいわけです。
プログラムが終了すると、そのプロセスが使っていた先
頭アドレス以降のメモリーは有無をいわせず解放され、
システムが再利用できるようになります。free()されて
いない領域があろうが関係ありません。
<88i8id$bi2$1...@ns.src.ricoh.co.jp>
［メモリーリークを意図的に起こすには］
Q. 逆に言えばメモリーリークを意図的に起こさせるには
どうするのでしょうか。
(意図的にハングアップさせて強制終了とかWindowsのMMF
とかでなく、単にmallocを使うだけで正常に終了している
限りメモリーリークを起こすことはないはずだというのが
皆様の議論の主旨のようですので。)
A. <38AFB2D7...@mail.ecc.u-tokyo.ac.jp> によれば、
WindowsのWin16 APIでGlobalAlloc/GlobalFreeを使い、
GlobalFreeを呼び忘れた場合
があるようです。ただしmalloc()/free()がこのAPIを直
接呼び出すようなコードを生成する処理系があるかどう
かは不明です。
<88jtrm$898$1...@pooh.isoternet.org> によれば、
malloc()相当のものが共有メモリーの割り当てと等価
になっているOSがある
そうで、この環境でfree()相当の関数を呼び忘れるとメ
モリーリークを起こす可能性があります。ただし右松さ
んの記事にはメモリーリークが起きると書かれているわ
けではありません。また、用意されている関数はmalloc
()/free()ではない可能性があります。
<88opnc$3to$3...@newsjp.mbn.or.jp> によれば、
組み込み用のOSでは「ヒープの管理は全部アプリケー
ション側でやってね」と言うスタンスのものが少なく
ない
そうです。この環境でfree()相当の関数を呼び忘れると
メモリーリークが起きそうです。これも用意されている
関数はmalloc()/free()ではない可能性があります。ま
た、このような環境ではmalloc()/free()がANSI C仕様
に準拠している可能性はなさそうです。
<88qimd$1hu$1...@ns.src.ricoh.co.jp>
---------------------------------------------------------- ここまで
Dairyo Gokan
-----------------------------------------------------------------------
> > 私が調べた範囲では malloc / free は OS を前提としません。
>
> 規格の中には出てきません。でもmalloc/freeというインター
> フェースはOSの存在が前提としてあるからこそああいう仕様に
> なっている、という話。だからそれでは反論になってません。
『アーウー』は故大平総理ですが、『ああいう仕様』と仰しゃる
『ああいう』とは具体的に、「仕様」のどの部分を指しているんで
しょうかねぇ？
ひょっとして、「特定のOS」向けに作られた限定的なライブラリの
実装を、汎用的な「仕様」と拡大解釈されてるんでわ？
もちぃと、ロジカルに話してもらわへんと ...。
-----------------------------------------------------------------------
> 違うでしょ。リークするかどうかはOSにとっての話。実
> 行時ライブラリーじゃありません。
-----------------------------------------------------------------------
『exit()すればリークしない』って仰しゃるんだから、当然exit()
そのものにリークを防ぐ機能が含まれていることと「仕様」に盛り込ま
れてないとおかしぃッスよね？
sasaki tadao
Junn Ohta wrote:
> fj.comp.lang.cの記事<95c18i$dip$1...@news01dh.so-net.ne.jp>で
> kat...@ka2.so-net.ne.jpさんは書きました。
> > 私が調べた範囲では malloc / free は OS を前提としません。
>
> 規格の中には出てきません。でもmalloc/freeというイ
> ンターフェースはOSの存在が前提としてあるからこそあ
> あいう仕様になっている、という話。だからそれでは反
> 論になってません。
OSを書くのにCを使ったときに、そのCは、どんなOS上で
動作しているのでしょうか？
Shiroh Sado
hir...@da2.so-net.ne.jp氏の発言 <_kXb6.1352$t74.1...@newsall.dti.ne.jp> より引用
>> mallocで動的に割り当てたメモリは、freeで解放する
>> と思いますが、このfreeを行わないで、そのプログラ
>> ムを終了させたら、割り当てたメモリは残ってしまう
>> のでしょうか？
mallocで動的に割り当てたメモリを、freeで解放するのは、
次回のmallocで使用できるようにするためですよね。
>> 私はWindowsNT4+VisualC++6でプログラムを作っている
>> のですが、freeを使わない（コーディングミス）時は
>> どのようになるか疑問になりました。
その環境の場合、mallocで動的に割り当てられたメモリは
freeで解放されなくても、プログラム終了後に影響は残り
ません。
UnixやWindows95/98/NTなどのそれなりにきちんとしたOSが
ある場合や、MS-DOS、Human68kなどのDOS環境では、malloc
で動的に割り当てられたメモリがfreeで解放されなかった
からといって、プログラム終了後に影響するような例は、
どうやら存在しないそうです。
僕は、mallocで動的に割り当てたメモリは、必ずfreeで解
放するようにしています。しかし、使い捨てのデータ構造
(解体するコストが組み立てるコストと比べて著しく大き
なもの) を用いる場合など、freeしないことが必ずしもコ
ーディングミスで無い場合もあります。また、積極的にfree
しないことを主張する人もいます。
一方、一部の組み込み環境では、mallocしたら必ずfreeし
なければいけない場合があるそうです。
議論が長引いているのは、
* それなりにきちんとしたOSがある場合に終了直前にfree
しなくもOSに対するメモリリークが起きないこと
が、規格から導けるかどうかなど、規格にを厳密に解釈す
るとどうなるかということだと思います。質問の環境で、
割り当てたメモリが残ってしまうかどうかということは、
議論の結果によって左右されません。
---
佐渡詩郎 (さど しろう) / e-mail : sa...@smlab.tutkie.tut.ac.jp
Shiroh Sado
ta...@ga.sony.co.jp氏の発言 <3A79E7EE...@ga.sony.co.jp> より引用
>> OSを書くのにCを使ったときに、そのCは、どんなOS上で
>> 動作しているのでしょうか？
OSを書くのにCを使ったときに、そのCは、OS上で動作しているのですか?
sasaki tadao
Shiroh Sado wrote:
私にはわかりません。しているかも知れないし、していないかも知れない。
ただ、OS上で動くCと、組み込み用のCを区別して議論をしている人が
いるようですけど、そんな区別は意味が無いのではないかと思ったまでです。
UNIX が malloc するときに必要なメモリは誰が用意してくれるんでしょうか。
UNIX が exit したときは誰が後始末してくれるんでしょうか。
NOGUCHI Yusuke
> > 規格の中には出てきません。でもmalloc/freeというイ
> > ンターフェースはOSの存在が前提としてあるからこそあ
> > あいう仕様になっている、という話。だからそれでは反
> > 論になってません。
>
> OSを書くのにCを使ったときに、そのCは、どんなOS上で
> 動作しているのでしょうか？
私は、OS の中で、ライブラリ関数の malloc(3) を呼んでいる例を見たことが
ありません。具体的には、どうのような OS のことを想定しておられるのでしょ
うか?
--
nog...@swlab.csce.kyushu-u.ac.jp
Grad. School of Info. Sci. and Ele. Eng., Kyushu Univ., Fukuoka, Japan
Hoshi Takanori
In article <95c3h3$h9u$1...@ns.src.ricoh.co.jp>
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> 規格の中には出てきません。でもmalloc/freeというイ
> ンターフェースはOSの存在が前提としてあるからこそあ
> あいう仕様になっている、という話。
だからぁ、C 言語や malloc/free が最初に作られた時は
そうだったかも知れないけど、ANSI C として規格化された
時には、OS を前提としないように抽象化されたんだってば。
いんた～ふぇいすがそのままなのは、互換性を保つため。
> 前回もそうだったけど片岡さんてばぜんぜん人の書いた
> 記事を理解してないのね。
あなたこそ、規格とは何なのかを、ぜんぜん分かってません。
ほし
sasaki tadao
NOGUCHI Yusuke wrote:
>
> 私は、OS の中で、ライブラリ関数の malloc(3) を呼んでいる例を見たことが
> ありません。具体的には、どうのような OS のことを想定しておられるのでしょ
> うか?
>
分からないから質問したんですけど、
CでOSを書くときに malloc を使用してはならない、というような
規定があるのでしょうか。
malloc を使用しないとしたら、必要なメモリをどうやって
確保しているんでしょうか。
Sugihara Yoshimi
> fj.comp.lang.cの記事<95b80c$5ho$1...@news.kyosai.or.jp>で
> sugi...@kyosai.or.jpさんは書きました。
> > リークしているのに再割り当てできるんですか？
> というか「再割り当て」をしようとしている時点ではま
> だいかなる「リーク」も発生していないわけです。だか
> ら「リークしているのに再割り当て」という状況自体に
> 意味がないですね。
うーむ・・
これってなんか混線してるようなので、これ以上は続けない
ことにします。
＃「リークしているメモリブロック」の定義が違うような気もする
> > ということで、それは「「「ＵＮＩＸ」」」に限定した話ですよね
> 違います。UNIXに限定した話ではない、ということを示
> すためにいろいろ書いたのですが...。
一番最初に「ＵＮＩＸ」が出てきてたもので。
メモリプールという考えがＡＮＳＩにあるということで
いいのでしょうか？
＃実装では多くがＵＮＩＸと同じような実装だと思いますが。
> > malloc()で確保したメモリブロックがプロセスが終了した後も
> > 存在しつづけたとしてもＡＮＳＩ準拠といえるのでは？
> 「ANSI準拠」ではなくて「ANSIとは無関係」ですね。
ここでは「無関係か」ということではなく
「そういう実装でもＡＮＳＩ準拠といっていいのか」
ってことです。
> > ともかく
> > 「「malloc()で取得したメモリブロックはプロセスの終了とともに開放され
る」」
> > という規定がＡＮＳＩに「「ある」」かのような説明が気に入らないだけですの
で
> > （＾＾；；
> そういう説明をしたつもりはないのですが。私の説明の
> どの部分がそうですか?
>
> 私がいいたいのは
> ・ANSI Cの環境で
> ・free()すればメモリーリークしないのであれば
> ・free()しなくてもメモリーリークしないだろう
> ということだけです。あとは枝葉です。
の
「 ・free()しなくてもメモリーリークしないだろう」
部分なのです。
規定がＡＮＳＩに無い以上そのような動作を期待している
のはどうかとおもうだけです。
＃多くの実装で問題ないというのは認めますが。
Hoshi Takanori
＃ 以下、規格の話しです。規格の話しを最初に持ち出したのは太田さん
＃ なので、「もともとは特定の処理系の話しだったのに、規格の話しに
＃ すりかえやがって。」などの文句は太田さんへどうぞ。
In article <KATE.01F...@sims211.trad.pfu.co.jp>
ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
> >ANSI C 規格 (正確には、ぼくが読んだのは JIS X 3010 だけど...)
> >が言及しているのは、「OS」でわなくて、「ホスト環境」です。
>
> ISO:IEC 9899 では、
>
> In a freestanding environment (in which C program
> execution may takeplace whithout any benefit of an operating
> system), 以下省略
>
> と、operating system に「言及」しています。
それは失礼しました。
> ＃ JIS X 3010 は手元にないので分かりません
JIS X 3010 では、5.1.2.1 フリースタンディング環境のところに、
フリースタンディング環境では、オペレーティングシステムの
いかなる支援もなしに C プログラムの実行を行う。
と書いてありました。(他にもあったらごめんなさい。)
＃ なんか、原文とニュアンスがちょっと違うような...
ただ、7.10.4.3 には、exit() が制御を戻す相手は「OS」ではなく、
「ホスト環境」と書いてありますので、わたしの主張は変わりません。
＊＊
> >もちろん、ふつ～は leak しないことを期待しますが、それは
> >あくまで quality of implementation issue に過ぎません。
>
> 確かにそうですが、そのような処理系は非常に使い難いでしょうね。
「使い難い」というのは主観的な評価です。なので、規格にはなじみ
ません。だからこそ quality of implementation issue なんです。
規格というのは、なるべく余計な仮定を排除することによって、対象
(ここでは C 言語) の応用範囲をむやみに制限することがないように
書かれているんです。
ほし
Sugihara Yoshimi
"Shiroh Sado" <sa...@smlab.tutkie.tut.ac.jp> wrote in message
news:95cjf3$il3$1...@news.tut.ac.jp...
> いつもお世話になっております、佐渡です。
・・中略・・
> ［個別の環境ではどうなるか］
> Q. freeせずに終了すると、個別の環境ではどうなるか?
> A1. いままで出た情報をまとめると、malloc()したメモ
> リーをfree()せずに終了した場合、
> (a) UNIX、MS-DOS、Windows95/98/NTならメモリーリー
> クは起きない
> (b) ANSI Cならメモリーリークは起きない
> (c) (malloc()/free()という関数仕様から)まともなOS
> とまともな言語処理系の組み合わせならメモリーリ
> ークは起きないと期待してよい
> (d) 上記のいずれでもない環境ではメモリーリークを起
> こす可能性がある(しかしfree()したからといって
> メモリーリークが起きないとは保証できない)
> といったところでしょうか。
> <88qimd$1hu$1...@ns.src.ricoh.co.jp>
の(b)は、ANSI Cでメモリーリークしないという規定が無い以上はずしてほしいで
す。
Junn Ohta
na...@can.bekkoame.ne.jpさんは書きました。
> 『ああいう仕様』と仰しゃる
> 『ああいう』とは具体的に、「仕様」のどの部分を指しているんで
> しょうかねぇ？
具体的には
(a) malloc()は「どこか」からメモリーをもらってくる
(どこからかは明記されていない)が、free()はその
「どこか」にメモリーを返すと書かれていない。
(b) malloc()したメモリーはfree()しなければいけない
とはどこにも書かれていない。
(c) free()したメモリーについてはmalloc()で再利用さ
れるとしか書かれていない。
という点です。
つまり、malloc()がどこからメモリーをもらってくるに
せよ、ANSI Cの仕様ではそのどこかにメモリーを返す手
段は定義されていないし、返せとも書いてない、という
ことです。それが「ああいう仕様」。
> 『exit()すればリークしない』って仰しゃるんだから、当然exit()
> そのものにリークを防ぐ機能が含まれていることと「仕様」に盛り込ま
> れてないとおかしぃッスよね？
私が主張したのは「exit()すれば」ではなくて「プログ
ラムが終了すれば」だけですよ。exit()が呼ばれようが
呼ばれまいが関係ないです。
Shinobu Kumaoka
Sugihara Yoshimi wrote:
> > 私がいいたいのは
> > ・ANSI Cの環境で
> > ・free()すればメモリーリークしないのであれば
> > ・free()しなくてもメモリーリークしないだろう
> > ということだけです。あとは枝葉です。
>
> の
> 「 ・free()しなくてもメモリーリークしないだろう」
> 部分なのです。
> 規定がＡＮＳＩに無い以上そのような動作を期待している
> のはどうかとおもうだけです。
> ＃多くの実装で問題ないというのは認めますが。
規格には、free()しなければならない、とは書いてありませんよね。
書いていない、ということは、free()しなくてもシステム上の大きな問題は発生しないと
考えられます。
多くのOSにとって、メモリーリークはシステム上の大きな問題ですから、
メモリーリークも発生しないと考えてよいかと思います。
--
cog...@sp.hudson.co.jp
株式会社ハドソン
研究開発本部 研究開発課
熊岡 忍(Kumaoka Shinobu)
Junn Ohta
ho...@sra.co.jpさんは書きました。
> だからぁ、C 言語や malloc/free が最初に作られた時は
> そうだったかも知れないけど、ANSI C として規格化された
> 時には、OS を前提としないように抽象化されたんだってば。
それはANSI Cプログラムを書く側にとっての話でしょう。
プログラマーはANSI Cの仕様に従ってプログラムを書い
ている限り、OSの存在を考慮せずに自分の書いたプログ
ラムがANSI Cの仕様どおりの動きをすると期待できるわ
けです。
処理系を書く側にとっては、ANSI C仕様に従って書かれ
たプログラムが、その処理系がターゲットとする環境で
仕様どおりの動きをするようにする、そのための指標が
ANSI Cである、と。
> いんた～ふぇいすがそのままなのは、互換性を保つため。
インターフェースがそのままなのは、処理系作成者に実
装方針を示唆するためでもあります。malloc()しっぱな
しでfree()しないプログラムもANSI Cに厳密に従ってい
るのだから、処理系作成者はそのようなプログラムでも
ターゲット環境でまともに動くようにmalloc()/free()
を実装する必要がある。
私にとってはそれもANSI C規格の意図、規格の要請です。
ほしさんはquality of implementation issueで片付け
ていますけどね。だからほしさんんとの間ではあまり争
点はないのではないかと思っているのです。
Shinji KONO
In article <3A7A1162...@ga.sony.co.jp> ,
sasaki tadao <ta...@ga.sony.co.jp> writes
>> 私は、OS の中で、ライブラリ関数の malloc(3) を呼んでいる例を見たことが
>> ありません。具体的には、どうのような OS のことを想定しておられるのでしょ
>> うか?
>分からないから質問したんですけど、
そんなもの Free のOSで、grep malloc *.c してみれば一発です。
これらの malloc() は、sys/malloc.h で定義されているものです。
もちろん free() もあります。これらの malloc() は必ず free()
する必要があります。
これらは、当然、ライブラリのmalloc(3) とは異なります。こちら
は、malloc.h をincldue します。
なんだけど、今の問題は exit() と free() の関係ですよね。
なので、おそらく聞くべき質問は、
> 私は、OS の中で、exit() を呼んでいる例を見たことがあるか
ってことになるのだと思います。Micro Kernel とかだとあるので
すよね。そういうMicro Kernelの外の部分をOSと呼ぶとすれば...
>malloc を使用しないとしたら、必要なメモリをどうやって
>確保しているんでしょうか。
僕が自分で書いた時には、MMUにアクセスしてfree blockを見つけ、
それを自分のメモリ空間にマップしていました。get_page()とかな
んかそんなアセンブラのentryとかtrap とかを作りました。ちなみ
に、exit はどうしたかは思い出せないです。free_all() は作った
と思う。
このレベルをユーザプログラムで扱うことはほとんどないです。
なので、malloc()/free()にしているわけだけど...
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Tsuyoshi FUKUI
On Fri, 2 Feb 2001 11:03:00 +0900,
Sugihara Yoshimi <sugi...@kyosai.or.jp> wrote:
>> 私がいいたいのは
>> ・ANSI Cの環境で
>> ・free()すればメモリーリークしないのであれば
>> ・free()しなくてもメモリーリークしないだろう
>> ということだけです。あとは枝葉です。
>
>の
>「 ・free()しなくてもメモリーリークしないだろう」
>部分なのです。
>規定がＡＮＳＩに無い以上そのような動作を期待している
>のはどうかとおもうだけです。
>＃多くの実装で問題ないというのは認めますが。
「～ならば～である」の「～である」の部分だけ取り出しても、
それは太田さんの主張とは違うものだと思うのですが。
--
FUKUI Tsuyoshi
tfu...@kansai.oki.co.jp
Sugihara Yoshimi
"Shinobu Kumaoka" <cog...@sp.hudson.co.jp> wrote in message
news:3A7A1894...@sp.hudson.co.jp...
> 熊岡です。> > 「 ・free()しなくてもメモリーリークしないだろう」
> > 部分なのです。
> > 規定がＡＮＳＩに無い以上そのような動作を期待している
> > のはどうかとおもうだけです。
> > ＃多くの実装で問題ないというのは認めますが。
> 規格には、free()しなければならない、とは書いてありませんよね。
ですね
> 書いていない、ということは、free()しなくてもシステム上の大きな問題は発生し
ないと
> 考えられます。
ただシステムで問題が発生するかどうかはＡＮＳＩ Ｃにとってはどうでも良い
ことだとおもいます。それが先の
「free()しなかったらメモリリークするような実装の場合でもANSI準拠とよべるのか
？」
という質問になったわけです。
ただ、malloc()が何らかの形でメモリを「「確保」しているのだから
「開放」してあげるほうが良いと考えているます。
free()ではmalloc()で確保したメモリを再確保できるようにする。
とあるのだから、malloc()が何らかの形で「確保」したメモリを
free()が何らかの形で「開放（または未使用）」にしてくれている
と考えています。
それがどのように扱われているのかなんて一切興味ないです。
ただfree()の規定が「malloc()で確保したメモリを開放」してくれる
というように読み取れるので、free()したほうが良いという判断に
いたっているわけです。
> 多くのOSにとって、メモリーリークはシステム上の大きな問題ですから、
> メモリーリークも発生しないと考えてよいかと思います。
確かにメモリリークするようであれば信頼性にかけますが
それとC言語の規格とは別の話とおもいます。
また信頼性を言うのでであればfree()したほうが、より安全になると思うので
それだけ信頼性の高いソフトになると いえるのでは？
Sugihara Yoshimi
> fj.comp.lang.cの記事<3A79E17C...@can.bekkoame.ne.jp>で
> na...@can.bekkoame.ne.jpさんは書きました。
> 具体的には
> (a) malloc()は「どこか」からメモリーをもらってくる
> (どこからかは明記されていない)が、free()はその
> 「どこか」にメモリーを返すと書かれていない。
> (b) malloc()したメモリーはfree()しなければいけない
> とはどこにも書かれていない。
> (c) free()したメモリーについてはmalloc()で再利用さ
> れるとしか書かれていない。
> という点です。
「malloc()は「どこか」からメモリをもらってくる。」
「free()はmalloc()で再利用できるようにする。」
のつながりで
free()はmalloc()が「どこか」からメモリを確保できるように
するため、メモリを「どこか」に返している
と読み取れるのでは？
「free()しなければならない」
というのはmalloc()したメモリがリークしようがしまいが、
ANSIにとってどうでも良いことなので書いてない
と読み取っています。
> つまり、malloc()がどこからメモリーをもらってくるに
> せよ、ANSI Cの仕様ではそのどこかにメモリーを返す手
> 段は定義されていないし、返せとも書いてない、という
> ことです。それが「ああいう仕様」。
「返さなくてもメモリリークしない」
とも書いてませんよね
KATAYAMA Yoshio
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>> Q. freeせずに終了すると、個別の環境ではどうなるか?
>> A1. いままで出た情報をまとめると、malloc()したメモ
>> リーをfree()せずに終了した場合、
[...]
>> (b) ANSI Cならメモリーリークは起きない
[...]
>> <88qimd$1hu$1...@ns.src.ricoh.co.jp>
>の(b)は、ANSI Cでメモリーリークしないという規定が無い以上はずしてほしいで
>す。
佐渡さんの記事は過去に投稿された記事を集めたものなので、太田さん
の記事を勝手に書き換えるわけにはいかないでしょう。
それに「いま（21 Feb 2000 05:33:01 GMT）まで出た情報」では、ANSI
C でメモリーリークが起きる処理系はなかったのですから、間違いでは
ありませんし、その後もそのような処理系の報告はなかったようです。
ANSI C でメモリーリークが起きる処理系（freestanding を除く）の実
例を示されれば、太田さんは訂正されるでしょう。
--
片山＠ＰＦＵ
Junn Ohta
fj.comp.lang.cの記事<95d4fp$bmp$1...@news.kyosai.or.jp>で
sugi...@kyosai.or.jpさんは書きました。
> うーむ・・
> これってなんか混線してるようなので、これ以上は続けない
> ことにします。
> ＃「リークしているメモリブロック」の定義が違うような気もする
sugiharaさんのおっしゃる「リーク」は「プログラムで
はもう使われていないのにmalloc()できない状態」とい
う意味ですか? それなら理解できます。
私にとっては「プログラム中で不要になった領域は、再
利用したければfree()すればよいのだし、その必要がな
ければ放置しておいてよい」です。その放置された状態
を「リーク」とは呼ばない立場、ですね。
> メモリプールという考えがＡＮＳＩにあるということで
> いいのでしょうか？
free()の定義に「free()したものはmalloc()で再び割り
当て可能になる」と書かれています。その「再び割り当
て可能」という状態のメモリーを、malloc()される前の
メモリーとは異なる状態にあるという意味で、仮にメモ
リープールと呼んでいるだけです。べつの呼びかたをし
てもらってもかまいません。
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> ただシステムで問題が発生するかどうかはＡＮＳＩ Ｃにとってはどうでも良い
> ことだとおもいます。それが先の
> 「free()しなかったらメモリリークするような実装の場合でもANSI準拠とよべるのか
> ？」
> という質問になったわけです。
「システムで問題が発生するかどうかはANSI Cにとって
はどうでもよい」という立場からは、「free()しようが
しまいがメモリーリークするような実装でもANSI準拠と
呼べる」が答えになると思います。
ただ、それではANSI Cが処理系作成者に期待している要
求仕様を無視することになるでしょうね。
> ただ、malloc()が何らかの形でメモリを「「確保」しているのだから
> 「開放」してあげるほうが良いと考えているます。
気分の問題ですね。「わたしゃそのほうが気分がよい」
ということなら止めはしません。
> また信頼性を言うのでであればfree()したほうが、より安全になると思うので
「free()したほうがより安全になる」には何の根拠もな
いでしょう。OS側がきちんとメモリー管理をしていれば
free()しようがしまいが関係ありませんし、OSのメモリ
ー管理に問題があるなら、free()したほうが安全なこと
もあるししないほうが安全なこともあります。
そのあたりの実例は前回の議論のときにいろいろと出て
いるので、興味があったら見直してみてください。
Shinobu Kumaoka
Shinobu Kumaoka wrote:
> > 「free()しなかったらメモリリークするような実装の場合でもANSI準拠とよべるのか
> > ？」
> > という質問になったわけです。
>
> 私なら、「バグ」と呼びます。
>
メモリーリークがシステムにとって重要な問題とはならないシステムの場合には、
私も、「バグ」とは呼びません。
Shinobu Kumaoka
Sugihara Yoshimi wrote:
> ただシステムで問題が発生するかどうかはＡＮＳＩ Ｃにとってはどうでも良い
> ことだとおもいます。それが先の
> 「free()しなかったらメモリリークするような実装の場合でもANSI準拠とよべるのか
> ？」
> という質問になったわけです。
私なら、「バグ」と呼びます。
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> 「malloc()は「どこか」からメモリをもらってくる。」
> 「free()はmalloc()で再利用できるようにする。」
> のつながりで
> free()はmalloc()が「どこか」からメモリを確保できるように
> するため、メモリを「どこか」に返している
> と読み取れるのでは？
そう読み取る必要があるわけではないです。
malloc()はいったん「どこか」からもらってきたメモリ
ーを自分の手もとで管理していてかまわないわけですし、
free()はメモリーを「どこか」に返さずに「malloc()の
手もと」に返すだけでじゅうぶんです。
> 「free()しなければならない」
> というのはmalloc()したメモリがリークしようがしまいが、
> ANSIにとってどうでも良いことなので書いてない
> と読み取っています。
そう読んだとして、「free()したほうがよい」理由はど
こかから出てきますか?
Tomoaki NISHIYAMA
> 「malloc()は「どこか」からメモリをもらってくる。」
> 「free()はmalloc()で再利用できるようにする。」
>
> のつながりで
> free()はmalloc()が「どこか」からメモリを確保できるように
> するため、メモリを「どこか」に返している
> と読み取れるのでは？
読み取れません。
mallocはAまたはBからとってくる、
freeはBに置くでもいいわけですから、
おおもとに「返す」必然性はありません。
> ただ、malloc()が何らかの形でメモリを「「確保」しているのだから
> 「開放」してあげるほうが良いと考えているます。
> free()ではmalloc()で確保したメモリを再確保できるようにする。
> とあるのだから、malloc()が何らかの形で「確保」したメモリを
> free()が何らかの形で「開放（または未使用）」にしてくれている
> と考えています。
だけど、free()が「解放」するという規定はないのですね。
> ただfree()の規定が「malloc()で確保したメモリを開放」してくれる
> というように読み取れるので、
勝手な思い込みですね。
--
Tomoaki Nishiyama
e-mail:tom...@nibb.ac.jp
National Institute for Basic Biology
KATAYAMA Yoshio
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>> > リークしているのに再割り当てできるんですか？
>> というか「再割り当て」をしようとしている時点ではま
>> だいかなる「リーク」も発生していないわけです。だか
>> ら「リークしているのに再割り当て」という状況自体に
>> 意味がないですね。
>これってなんか混線してるようなので、これ以上は続けない
>ことにします。
>＃「リークしているメモリブロック」の定義が違うような気もする
「メモリーリーク」に、OS でのリークと、プロセスでのリークの２種
類あることを認識していますか。このスレッドで議論の対象となってい
るのは前者のことです。「リークしているのに再割り当てできるんです
か」は後者ですね。
>メモリプールという考えがＡＮＳＩにあるということで
>いいのでしょうか？
ここで言うメモリープールとは、ライブラリーが管理しているメモリー
プールのことと思いますが、規格はそのような実装を否定していないだ
けですね。
全く異なる実装であっても構いませんが、多くのシステムでは、このよ
うな実装より利点が少なさそうです。
>> > malloc()で確保したメモリブロックがプロセスが終了した後も
>> > 存在しつづけたとしてもＡＮＳＩ準拠といえるのでは？
>> 「ANSI準拠」ではなくて「ANSIとは無関係」ですね。
>ここでは「無関係か」ということではなく
>「そういう実装でもＡＮＳＩ準拠といっていいのか」
>ってことです。
C 言語の規格で規定しているのはプログラムの終了までですから無関係
です。つまり、「そういう実装でもＡＮＳＩ準拠」となりえます。
OS でメモリーリークが起きるような C 言語の実装が許されるかは、そ
の OS の規約や、その OS が従っている規格（があれば）等によります。
>> ・ANSI Cの環境で
>> ・free()すればメモリーリークしないのであれば
>> ・free()しなくてもメモリーリークしないだろう
>> ということだけです。あとは枝葉です。
>の
>「 ・free()しなくてもメモリーリークしないだろう」
>部分なのです。
>規定がＡＮＳＩに無い以上そのような動作を期待している
>のはどうかとおもうだけです。
>＃多くの実装で問題ないというのは認めますが。
そのスタンスであれば、
・free() すれば OS でメモリーリークしない
ということが規定されていないので、このような動作を期待してはいけ
ません。
--
片山＠ＰＦＵ
KATAYAMA Yoshio
sasaki tadao <ta...@ga.sony.co.jp> writes:
>ただ、OS上で動くCと、組み込み用のCを区別して議論をしている人が
>いるようですけど、そんな区別は意味が無いのではないかと思ったまでです。
C 言語規格（ISO/IEC 9899）の freestanding environment と hosted
environment が根拠です。freestanding environment では、規格で規
定されているライブラリー関数すべてが使えるとは限りません。C99 で
は、更に 6. Language で規定されている機能の一部も使えるとは限り
ません
>UNIX が malloc するときに必要なメモリは誰が用意してくれるんでしょうか。
>UNIX が exit したときは誰が後始末してくれるんでしょうか。
C 言語だけでなく、OS のお勉強もした方がよいですね。
--
片山＠ＰＦＵ
Shiroh Sado
スレッド「Re: mallocで割り当てたメモリの質問」での
ko...@ie.u-ryukyu.ac.jp氏の発言 <4923.98...@rananim.ie.u-ryukyu.ac.jp> より引用
>> これらは、当然、ライブラリのmalloc(3) とは異なります。こちら
>> は、malloc.h をincldue します。
malloc(3) は stdlib.h を include するのですよね?
Sugihara Yoshimi
"Tomoaki NISHIYAMA" <tom...@nibb.ac.jp> wrote in message
news:86r91hvf...@koke.nibb.ac.jp...
> "Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>
> > 「malloc()は「どこか」からメモリをもらってくる。」
> > 「free()はmalloc()で再利用できるようにする。」
> > のつながりで
> > free()はmalloc()が「どこか」からメモリを確保できるように
> > するため、メモリを「どこか」に返している
> > と読み取れるのでは？
> 読み取れません。
> mallocはAまたはBからとってくる、
> freeはBに置くでもいいわけですから、
> おおもとに「返す」必然性はありません。
「おおもとに返す」ではなく
malloc()で再利用できるようになることを
「返す」と表現してるに過ぎません。
malloc()で確保したメモリはプログラマーの管理下なり、
free()によりプログラマーの管理下でなくなり、malloc()で
再利用できるようになる。
と理解して以上を「確保」＆「開放（返す）」と表現しています。
そもそもfree()すればmalloc()で再利用できることが規定されている
わけですが、free()しなくてもプロセスさえ終了すれば再利用できる
と規定されているのでしょうか？
＃と気にしているのはこの部分なんで・・
Sugihara Yoshimi
"KATAYAMA Yoshio" <ka...@pfu.co.jp> wrote in message
news:KATE.01F...@sims211.trad.pfu.co.jp...
> In article <95d4fp$bmp$1...@news.kyosai.or.jp>,
> "Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
> 「メモリーリーク」に、OS でのリークと、プロセスでのリークの２種
> 類あることを認識していますか。このスレッドで議論の対象となってい
> るのは前者のことです。「リークしているのに再割り当てできるんです
> か」は後者ですね。
いえ、前者でもいいです。
ようは「リークしているのに再割り当てできるのか？」
ってことです。
前者でも後者でも「リーク」していたら再割り当てできない
とおもうのですが。
＃後者だとプロセスが終了すればメモリはすべて開放されるので
＃再割り当てできる。と反論がきそうですが、それってプロセスが
#終了してすべてOSが開放しちゃったら「リーク」とは呼ばないのでは？
> >「 ・free()しなくてもメモリーリークしないだろう」
> >部分なのです。
> >規定がＡＮＳＩに無い以上そのような動作を期待している
> >のはどうかとおもうだけです。
> >＃多くの実装で問題ないというのは認めますが。
> そのスタンスであれば、
> ・free() すれば OS でメモリーリークしない
> ということが規定されていないので、このような動作を期待して
>はいけません。
malloc()で再割り当てできるようになるのだから、
「メモリリーク」はないとおもいます。
「メモリリーク」って「再割り当てできない(使えない)メモリ領域」
と認識していますが・・
＃malloc()に限った話ではなくて「リーク」そのものの
＃定義になってきてる（＾＾；；
ちがうのかな？
Shiroh Sado
ka...@pfu.co.jp氏の発言 <KATE.01F...@sims211.trad.pfu.co.jp> より引用
>> >の(b)は、ANSI Cでメモリーリークしないという規定が無い以上はずしてほしいで
>> >す。
>>
>> 佐渡さんの記事は過去に投稿された記事を集めたものなので、太田さん
>> の記事を勝手に書き換えるわけにはいかないでしょう。
こちらは全くその通りです。
ただ、cut&paste の関係、および、無理やり Q. A. 対応づけを
したため、文の意味が万一変わっているところがありましたら、
悪いのは私です。
また、特に太田さんの記事からの大量に引用しており、その点
で問題等ありましたら申し訳ありません。＞太田さん
message-idは、
http://galaxy.rwcp.or.jp/
http://queen.heart.ne.jp/
等で、記事の文脈が確認できるようにと残してあります。
KATAYAMA Yoshio
ho...@sra.co.jp (Hoshi Takanori) writes:
>> ISO:IEC 9899 では、
>>
>> In a freestanding environment (in which C program
>> execution may takeplace whithout any benefit of an operating
>> system), 以下省略
>>
>> と、operating system に「言及」しています。
>JIS X 3010 では、5.1.2.1 フリースタンディング環境のところに、
> フリースタンディング環境では、オペレーティングシステムの
> いかなる支援もなしに C プログラムの実行を行う。
>と書いてありました。(他にもあったらごめんなさい。)
索引で oprating system を調べると 7.10.4.5 も出ているのですが、
ここには host environment しかありません。:-)
＃ C99 も同様です
>ただ、7.10.4.3 には、exit() が制御を戻す相手は「OS」ではなく、
>「ホスト環境」と書いてありますので、わたしの主張は変わりません。
例えば、C プログラムを動作させるプロセスを起動し、そのプロセス内
部で実行させるような処理系なども許すために「ホスト環境」という語
を用いているのだと考えています。しかし、「ホスト環境」が提供する
機能は、OS 配下で動作するプログラムが OS から提供される機能と同
様なものでしょう。
このことと、ホスト環境 = OS である実装が多いことを考えると、「ホ
スト環境」と「OS」を厳格に区別しなければならない文脈以外では、拘
らなくてもよいのではないかと思いますがいかがでしょうか。
> ＊＊
わざわざ区切りのマークを入れて下さり有難うございます。
>> 確かにそうですが、そのような処理系は非常に使い難いでしょうね。
>「使い難い」というのは主観的な評価です。なので、規格にはなじみ
>ません。だからこそ quality of implementation issue なんです。
規格の話ではなくなっているので主観を述べました。:-)
しかし、意味もなく主観を述べたわけではなく、このような処理系はい
かに実用的でないかということを示したかったのです。
もちろん、実用的である／ないというのも規格とは関係ありません。
--
片山＠ＰＦＵ
Kusakabe Youichi
(Shiroh Sado) wrote:
> mallocで動的に割り当てたメモリを、freeで解放するのは、
> 次回のmallocで使用できるようにするためですよね。
次回「以降」のmallocで使用できることを「期待」するため?
> UnixやWindows95/98/NTなどのそれなりにきちんとしたOSが
> ある場合や、MS-DOS、Human68kなどのDOS環境では、malloc
> で動的に割り当てられたメモリがfreeで解放されなかった
> からといって、プログラム終了後に影響するような例は、
> どうやら存在しないそうです。
そういうえばMacの環境の例がちっともでてきませんね。
(あまり参加する人がいない?)
> 僕は、mallocで動的に割り当てたメモリは、必ずfreeで解
> 放するようにしています。
そういえばmallocしたものを全部freeしないと気が済まないのに、
fopenは全部fcloseする、というわけもないという変なひとをみたことあります。
そういう人もいるのですね。
> また、積極的にfreeしないことを主張する人もいます。
これはどういう理由からでしたっけ?
(以前の記事で読んだ気がするけど見つからない...)
> 議論が長引いているのは、
>
> * それなりにきちんとしたOSがある場合に終了直前にfree
> しなくもOSに対するメモリリークが起きないこと
>
> が、規格から導けるかどうかなど、規格にを厳密に解釈す
> るとどうなるかということだと思います。
規格に「freeしなかったからといってメモリーリークするというわけではない」と
親切に書いてもらえばいいのですね ;)
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tomoaki NISHIYAMA
> そもそもfree()すればmalloc()で再利用できることが規定されている
> わけですが、free()しなくてもプロセスさえ終了すれば再利用できる
> と規定されているのでしょうか？
プロセス終了後は利用のfree()しようがしまいが、
利用しようがないのでは？もうそのプロセスは存在しないのだから。
他のプロセスにとって利用できるかどうかは、free()するかどうか
とは独立でしょう。free()はもとのプログラムにとって再利用できるように
するだけで、他のプロセスに利用できるようにするという規定は
ないのですから。
Kusakabe Youichi
開放と解放はちがうと思うし、
freeはmalloc()で使えるようにするということですよね。
> free()ではmalloc()で確保したメモリを再確保できるようにする。
(中略)
> ただfree()の規定が「malloc()で確保したメモリを開放」してくれる
> というように読み取れるので、free()したほうが良いという判断に
> いたっているわけです。
終了時には「再確保」のことを考えなくていいのでは?
なのになぜ「したほうがよい」になるのでしょう?
Sugihara Yoshimi
"KATAYAMA Yoshio" <ka...@pfu.co.jp> wrote in message
news:KATE.01F...@sims211.trad.pfu.co.jp...
> >「 ・free()しなくてもメモリーリークしないだろう」
> >部分なのです。
> >規定がＡＮＳＩに無い以上そのような動作を期待している
> >のはどうかとおもうだけです。
> >＃多くの実装で問題ないというのは認めますが。
> そのスタンスであれば、
> ・free() すれば OS でメモリーリークしない
> ということが規定されていないので、このような動作を期待してはいけ
> ません。
の部分ですが、
free()したのにOSでメモリーリークしたら
malloc()で再利用できないはずだから
free()が規格を満たしていないと思うのですが
それでもANSI準拠と呼べるのでしょうか？
Shiroh Sado
vo...@merope.pleiades.or.jp氏の発言 <void-02020...@newshost.ryukyu.ad.jp> より引用
>> > mallocで動的に割り当てたメモリを、freeで解放するのは、
>> > 次回のmallocで使用できるようにするためですよね。
>>
>> 次回「以降」のmallocで使用できることを「期待」するため?
そうですね。
>> そういうえばMacの環境の例がちっともでてきませんね。
>> (あまり参加する人がいない?)
Machintosh の人は、上記環境の人よりは C言語を使わないのでは
ないでしょうか。
( Pascal や Fortran ばかりかと思っていました。)
>> そういえばmallocしたものを全部freeしないと気が済まないのに、
>> fopenは全部fcloseする、というわけもないという変なひとをみたことあります。
>> そういう人もいるのですね。
リセットスイッチを押すのは危ないと言い、電源をON→OFF→ONする人
もいますね。
>> > また、積極的にfreeしないことを主張する人もいます。
>>
>> これはどういう理由からでしたっけ?
>> (以前の記事で読んだ気がするけど見つからない...)
主に、
* freeするたびにpage inする危険がある
* 計算量の非対称性
* そもそもプロセスが長命なのが間違い
ということだったと思います。
>> 規格に「freeしなかったからといってメモリーリークするというわけではない」と
>>
>> 親切に書いてもらえばいいのですね ;)
それはわかりやすいですね。
Kusakabe Youichi
<sugi...@kyosai.or.jp> wrote:
> 「malloc()は「どこか」からメモリをもらってくる。」
> 「free()はmalloc()で再利用できるようにする。」
>
> のつながりで
> free()はmalloc()が「どこか」からメモリを確保できるように
> するため、メモリを「どこか」に返している
そうはとれないでしょう。
実際の実装でも、返さずにプールしておいてそこから「再割り当て」したり
しますよね?
規格で「mallocしたものはfreeしなければいけない」と規定されていない以上、
freeしなかったからといってメモリーリークするような実装は規格に合っている
とは言えないでしょう。
たとえばprintfを3回連続使ったら暴走するような実装があったら、
それは規格に合っていると言わない、ってのと同じだと思います。
> 「返さなくてもメモリリークしない」
> とも書いてませんよね
printfは3回連続つかっても平気、とか書いてないのと同じことだと思います。
Takemoto,Satoshi
# ふう、一日チェックしていない間に、山のような記事が....
# やはり malloc & free が話題になるとスレッドの成長が速い速い。
Kusakabe Youichi wrote:
> せっかく期待したのですから、
> このさい竹本さんが中心になって作るというのはどうでしょう? :)
うっ、さすがは師。一番突っ込まれたくないと思っていたところを
お約束通り突いてくださって有り難うございます。(^^;
既に佐渡さんが、非常に網羅的で詳細なFAQ集を投稿して下さいました。
少なくとも私には、これを超えるものは書けません。
有り難うございます > 佐渡さん。
> きっと日本人の好みなのでしょう :)
> malloc&freeのほうがナルポインターよりも。
> というわけで、日本人...というかfjユーザー向きのFAQを作ってください > 竹本
> さん
佐渡さんのFAQ集を読んでみて、ただのFAQ集だけでは
議論が繰返されるのを止められないような気がしてきました。
少しずつ論点がずれていくのか、色々な広がりが有る。
皆さん、規格書の行間や、OSの違いや、心のひだの間などに
どんどん踏み込んでいく。(^^;
やはり、「動的にメモリ領域を取得する」という行為に、
どこか日本人の心の琴線に触れるものが有るのでしょうか?
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部
Furuta
リが独立していないシステムでは(ANSI C準拠のものがあるかは知らない)、freeを使
うことによりほかのプログラムでメモリを再利用できるようになるシステムもあるか
もしれないと考えます。
というわけで、
freeした方がリークする環境が少なくなると考えます。
Junn Ohta
sa...@smlab.tutkie.tut.ac.jpさんは書きました。
> >> > また、積極的にfreeしないことを主張する人もいます。
> >> これはどういう理由からでしたっけ?
> ...
> * freeするたびにpage inする危険がある
> * 計算量の非対称性
> * そもそもプロセスが長命なのが間違い
あと
* あとでfreeするためにはそのようにデータ構造を設計
しておく必要がある(freeしなくてよければデータ構
造をもっと簡単にできる可能性がある)
という理由がありました。
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> そもそもfree()すればmalloc()で再利用できることが規定されている
> わけですが、free()しなくてもプロセスさえ終了すれば再利用できる
> と規定されているのでしょうか？
その質問は無意味です。
「free()したあとで再利用する」といったとき、誰が再
利用したいのかといえば「そのプロセス」です。プロセ
スが終了したあとではそもそも「再利用」したがってい
る主体が存在しません。
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> いえ、前者でもいいです。
> ようは「リークしているのに再割り当てできるのか？」
> ってことです。
> 前者でも後者でも「リーク」していたら再割り当てできない
> とおもうのですが。
「リーク」の意味が違ってますね。
> ＃後者だとプロセスが終了すればメモリはすべて開放されるので
> ＃再割り当てできる。と反論がきそうですが、それってプロセスが
> #終了してすべてOSが開放しちゃったら「リーク」とは呼ばないのでは？
OSがプロセスに渡したメモリーを「プロセスが終了して
OSが開放」しても取り戻せなかった場合が「OSのメモリ
ーリーク」です。
> malloc()で再割り当てできるようになるのだから、
> 「メモリリーク」はないとおもいます。
プロセスの生存中はmalloc()で再割り当て可能になって
いても、そのメモリーをmallocインターフェースがかか
えた状態であればプロセス終了時にOSに返せない可能性
は残ります。そのような状態を「free()したのにメモリ
ーリークする」と呼んでいます。
Junn Ohta
sa...@smlab.tutkie.tut.ac.jpさんは書きました。
> また、特に太田さんの記事からの大量に引用しており、その点
> で問題等ありましたら申し訳ありません。＞太田さん
いえいえ、怠惰な私に替わっていろいろしてくださって
ありがとうございます。問題がありそうなら訂正を入れ
ますので...。
KATAYAMA Yoshio
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>> 「メモリーリーク」に、OS でのリークと、プロセスでのリークの２種
>> 類あることを認識していますか。このスレッドで議論の対象となってい
>> るのは前者のことです。「リークしているのに再割り当てできるんです
>> か」は後者ですね。
>いえ、前者でもいいです。
>ようは「リークしているのに再割り当てできるのか？」
>ってことです。
やっと意味が分かりました。「OS の中でリークしているのに、それを
（どこかのプログラムで）使うことができるのか」ということですね。
それでしたら、
誰もそんなことは議論していません。OS の中でどのように動いて
いるか気にしている人は（Sugihara さん以外）誰もいません。議
論になっているのは、OS でのメモリーリークの結果システムダウ
ンが起きる、つまり C プログラムを実行した結果システムダウン
が起きるのは、規格に準拠した動作であるかについてです。
が答です。
>#終了してすべてOSが開放しちゃったら「リーク」とは呼ばないのでは？
C プログラム内でのリークとは、
まだ malloc() を行なわなければならないのに、不要になった領域
を free() していないこと
です。この結果、領域不足でプログラムが続行できなくなってしまうこ
とが問題になります。
ここで議論しているのはそういうことではなく、「終了してすべてOSが
解放」するのかということです。しない（できない）部分があれば OS
内部でのリークとなります。
>> >「 ・free()しなくてもメモリーリークしないだろう」
>> >部分なのです。
>> >規定がＡＮＳＩに無い以上そのような動作を期待している
>> >のはどうかとおもうだけです。
>> >＃多くの実装で問題ないというのは認めますが。
>> そのスタンスであれば、
>> ・free() すれば OS でメモリーリークしない
>> ということが規定されていないので、このような動作を期待して
>>はいけません。
>malloc()で再割り当てできるようになるのだから、
>「メモリリーク」はないとおもいます。
ここの「メモリーリーク」は OS 内部での話です。リークの原因となっ
た C プログラムは既に終了しています。この領域が再度使われるかは、
「malloc()で再割り当て」とは関係ありません。「malloc()で再割り当
て」は、free() で返却されたメモリーについてのことです。リークの
原因となった C プログラムは終了していて、現在実行中の C プログラ
ムとは全く関係ありません。更に付け加えるなら、free() で返却され
なかったメモリーがリークの原因ですから、「free() で返却されたメ
モリー」とは全く無関係です。
--
片山＠ＰＦＵ
KATAYAMA Yoshio
vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes:
>規格で「mallocしたものはfreeしなければいけない」と規定されていない以上、
>freeしなかったからといってメモリーリークするような実装は規格に合っている
>とは言えないでしょう。
規格が規定しているのは、プログラムが起動された瞬間から停止した瞬
間までです。このメモリーリークはプログラム終了後の OS 内部ことで
すから、何が起ころうと規格とは関係ありません。
＃規格とは関係ないところでバグと呼ばれるかもしれませんが、、、
>たとえばprintfを3回連続使ったら暴走するような実装があったら、
>それは規格に合っていると言わない、ってのと同じだと思います。
これは実行の途中で動作が継続できなくなっていますから、abstract
machine とは異なる動作になりますので規格準拠ではありません。
両者は「同じ」ではありません。
--
片山＠ＰＦＵ
Narita Takaoki
Takemoto,Satoshi <take...@cv.sony.co.jp> wrote in message news:3A7A6AD7...@cv.sony.co.jp...
> 竹本です。
>
> # ふう、一日チェックしていない間に、山のような記事が....
> # やはり malloc & free が話題になるとスレッドの成長が速い速い。
：
> Kusakabe Youichi wrote:
> > きっと日本人の好みなのでしょう :)
> > malloc&freeのほうがナルポインターよりも。
> > というわけで、日本人...というかfjユーザー向きのFAQを作ってください > 竹本
> > さん
：
> やはり、「動的にメモリ領域を取得する」という行為に、
> どこか日本人の心の琴線に触れるものが有るのでしょうか?
日本人特有の重箱の隅をつつくような匠の技とか、見えない
お洒落な技とかが発揮し易くって、みんなそれぞれ蘊蓄があ
るのかも。
# malloc & free 世界名人芸コンテスト(どんなんだ ^^;)と
# かやったらダントツで日本人の応募が多かったりして。(^^;
## ほとんど茶々です。;-)
--
Narita Takaoki @A.I.SOFT,INC.
『１０分間で決断し、短い理由を添えよ』
Sugihara Yoshimi
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:95dr4l$5mf$2...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<95dj19$cvp$1...@news.kyosai.or.jp>で
> sugi...@kyosai.or.jpさんは書きました。
> > そもそもfree()すればmalloc()で再利用できることが規定されている
> > わけですが、free()しなくてもプロセスさえ終了すれば再利用できる
> > と規定されているのでしょうか？
> その質問は無意味です。
> 「free()したあとで再利用する」といったとき、誰が再
> 利用したいのかといえば「そのプロセス」です。プロセ
> スが終了したあとではそもそも「再利用」したがってい
> る主体が存在しません。
「そのプロセス」だけに限定できるわけではないとおもいます。
それは、すべてのプロセスから使えるようなグローバルなメモリから
malloc()がメモリを確保してもＡＮＳＩには準拠しているといえますよね。
そのような場合は、ほかのプロセスといえどもその領域が使えなく
なると思います。
プロセスが終了したからそのプロセスが使用していたメモリを
ＯＳがちゃんと回収してくれるかどうかはＣ言語とは関係ない
というのはこのスレッドに参加している全員が一致していると思いますが、
ANSI Cでmalloc()したメモリはプロセスの終了により確実にＯＳ
に返却されると規定されているかのような表現があるのが気に入らない
だけです。
上記のような実装でもＯＫなわけですから、機種依存する表現と
受け取れます。前のスレッドでも必ず「ＵＮＩＸ」ではとか「ＷＩＮ３２」
ではとかってあるし・・
Shinji KONO
fj.comp.lang.cの記事<95dlhv$ovu$1...@news.tut.ac.jp>で
sa...@smlab.tutkie.tut.ac.jpさんは書きました。
> >> > また、積極的にfreeしないことを主張する人もいます。
> * freeするたびにpage inする危険がある
> * 計算量の非対称性
> * そもそもプロセスが長命なのが間違い
In article <95dqsr$5mf$1...@ns.src.ricoh.co.jp> ,
oh...@src.ricoh.co.jp (Junn Ohta) writes
>* あとでfreeするためにはそのようにデータ構造を設計
> しておく必要がある(freeしなくてよければデータ構
> 造をもっと簡単にできる可能性がある)
あと、
* 全部、free するのは、結構、計算量がかかる
* どうせ、一括してfreeできるように、memory pool とかを設計するのが普通
(そういうシステムではmalloc/free は対応しない)
なんてのもありました。
さらに、free しなくて大丈夫な根拠には、
Process が異常終了して free できなかった場合に
対処できないから、exit時に free を要求するような実装はない
ってのもあったと思います。
個人的には、
malloc したら free する
みたいなおまじないにすぎないものを単純に信じるようなプログラム
態度が嫌いです。そこで「何故?」「どうして?」を追求するべきだと
思う。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Sugihara Yoshimi
> "Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
> やっと意味が分かりました。「OS の中でリークしているのに、それを
> （どこかのプログラムで）使うことができるのか」ということですね。
> それでしたら、
> 誰もそんなことは議論していません。OS の中でどのように動いて
> いるか気にしている人は（Sugihara さん以外）誰もいません。議
> 論になっているのは、OS でのメモリーリークの結果システムダウ
> ンが起きる、つまり C プログラムを実行した結果システムダウン
> が起きるのは、規格に準拠した動作であるかについてです。
> が答です。
プロセスが終了したらそのプロセスが使用したメモリは
ＯＳがちゃんと回収してくれる。
とかあったんで、てっきり
「ＡＮＳＩではそのようなＯＳを想定している」
と受け取っていました。
＃とりあえずこれに反論してるつもりだった。
> ここで議論しているのはそういうことではなく、「終了してすべてOSが
> 解放」するのかということです。しない（できない）部分があれば OS
> 内部でのリークとなります。
そこなんですがＡＮＳＩでは
「OSが解放する」と「「想定」」しているのでしょうか
・・・中略・・
> ここの「メモリーリーク」は OS 内部での話です。リークの原因となっ
> た C プログラムは既に終了しています。
プロセスが終了していないときは「リークしてる」とは言わないと
思います。なぜなら、プロセスが生きているならそのメモリ領域は
プロセスが「利用」している状態だと理解しているからです。
Sugihara Yoshimi
"Narita Takaoki" <tak...@aisoft.co.jp> wrote in message
news:95dtom$60k$1...@epsongw6.epson.co.jp...
> 成田です。
> # malloc & free 世界名人芸コンテスト(どんなんだ ^^;)と
> # かやったらダントツで日本人の応募が多かったりして。(^^;
その前に動作させる環境がＯＳじゃないとかと言う議論で
収集つかなくなる可能性が大（汗）
Tomoaki NISHIYAMA
> "Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
> news:95dr4l$5mf$2...@ns.src.ricoh.co.jp...
> > fj.comp.lang.cの記事<95dj19$cvp$1...@news.kyosai.or.jp>で
> > sugi...@kyosai.or.jpさんは書きました。
> > > そもそもfree()すればmalloc()で再利用できることが規定されている
> > > わけですが、free()しなくてもプロセスさえ終了すれば再利用できる
> > > と規定されているのでしょうか？
> > その質問は無意味です。
> > 「free()したあとで再利用する」といったとき、誰が再
> > 利用したいのかといえば「そのプロセス」です。プロセ
> > スが終了したあとではそもそも「再利用」したがってい
> > る主体が存在しません。
>
> 「そのプロセス」だけに限定できるわけではないとおもいます。
おもうのは勝手ですが、free()することによって再利用できる
と期待できるのはそのプロセスに限定されます。
他のプロセスにとってどうなるかは規定されていません。
> それは、すべてのプロセスから使えるようなグローバルなメモリから
> malloc()がメモリを確保してもＡＮＳＩには準拠しているといえますよね。
> そのような場合は、ほかのプロセスといえどもその領域が使えなく
> なると思います。
だから、free()したからって他のプロセスに使えるようになる
とは限らないんだって。
Shiroh Sado
>> fj.comp.lang.cの記事<95dk8f$ol9$1...@news.tut.ac.jp>で
>> sa...@smlab.tutkie.tut.ac.jpさんは書きました。
>> > また、特に太田さんの記事からの大量に引用しており、その点
>> > で問題等ありましたら申し訳ありません。＞太田さん
>>
>> いえいえ、怠惰な私に替わっていろいろしてくださって
>> ありがとうございます。問題がありそうなら訂正を入れ
>> ますので...。
太田さんの記事にはいつも勉強させていただいております。
問題点の訂正等、ぜひお願いします。
スレッド「ひぃ、お許しを(Re: (FAQ listを)竹本さんが中心になって作るというのはどうでしょう?)」での
take...@cv.sony.co.jp氏の発言 <3A7A6AD7...@cv.sony.co.jp> より引用
>> 既に佐渡さんが、非常に網羅的で詳細なFAQ集を投稿して下さいました。
>> 少なくとも私には、これを超えるものは書けません。
>>
>> 有り難うございます > 佐渡さん。
いえ、元記事の大部分は、太田さんと片山さんの投稿です。
私は、運良くQUEENがすいていたので拾い集められただけです。
元記事を出された皆さんから、問題点等の修正をして頂ければ、
「malloc and free」のよくある誤解とその回答集が得られるの
ではないかと思っております。
Kazuya Maebashi
Kusakabe Youichi wrote in message ...
>たとえばprintfを3回連続使ったら暴走するような実装があったら、
>それは規格に合っていると言わない、ってのと同じだと思います。
printf() 3回でおかしくなるような環境はそうそうないと思いますが、
fprintf()で、ファイルに向かって無限ループで出力を続けたら、
そのうちシステム全体がまともに動かなくなるOSはあると思うん
ですけど。
fprintf()を続けるプログラム自体が暴走したら、それは処理系が
規格を満たしていないということになるのでしょうが、おかげで他の
プロセスが困ったとしても、そんなことはCの規格の範囲外です。
よって、
規格に反していないプログラムを実行して困ったことになるような
環境は、規格を満たしていない。
なんて主張は、明らかに間違っていると思います。
------------------------------------------------------------
前橋 和弥 maeb...@cse.co.jp
http://member.nifty.ne.jp/maebashi/
------------------------------------------------------------
Kazuya Maebashi
Junn Ohta wrote in message <95b92u$9pp$1...@ns.src.ricoh.co.jp>...
>私がいいたいのは
>・ANSI Cの環境で
>・free()すればメモリーリークしないのであれば
>・free()しなくてもメモリーリークしないだろう
>ということだけです。あとは枝葉です。
なぜですか?
規格には、
・終了時にmalloc()した領域を開放するなんてことはどこにも書いてない
・free()すればその領域をOSに返すとも書いてない
・free()すれば、後のmalloc()で使えるようになる、とだけ書いてある
わけですが、
**** 以下規格とは無関係の実装上の話です ****
ある環境が、
・終了時にmalloc()した領域を開放しない
・いくつものプロセスを(同時でなくても)実行できる
のであれば、そういう環境の作成者は、
free()すれば遅くともプログラムの終了時にはOSにメモリを返す
ような実装にするであろう
ことは(それなりには)期待できると思います。
終了時に勝手にやってくれもせず、free()してもだめだったら、
メモリリークを防ぐ手段が *ない* ことになっちゃいますから。
そういう環境では、exit()前でもfree()することに意味がありますね。
# 今まさに書いてる、WindowsのAPI呼び出しまくり、
# 最低必要メモリ128Mバイトのプログラムで、
# exit()前にfree()しなきゃいけないかどうかはまた別の話。
井町智彦
## sugi...@kyosai.or.jp wrote on 19:02, Feb. 02,'01 (Fri)
>> 「free()したあとで再利用する」といったとき、誰が再
>> 利用したいのかといえば「そのプロセス」です。プロセ
>> スが終了したあとではそもそも「再利用」したがってい
>> る主体が存在しません。
>
>「そのプロセス」だけに限定できるわけではないとおもいます。
>それは、すべてのプロセスから使えるようなグローバルなメモリから
>malloc()がメモリを確保してもＡＮＳＩには準拠しているといえますよね。
>そのような場合は、ほかのプロセスといえどもその領域が使えなく
>なると思います。
A. あるプロセスがfree()したメモリ領域は、free()が完了した時点で
他のプロセスが使える様になる。
B. あるプロセスがfree()したメモリ領域は、free()が完了した時点では
他のプロセスが使える様にはならない。
プロセスが終了した時に、そのプロセスが使っていた全てのメモリ領域が
他のプロセスで使える様になる。
C. あるプロセスがfree()したメモリ領域は、free()が完了した時点では
他のプロセスが使える様にはならない。
プロセスが終了した時に、そのプロセスでfree()されていたメモリ領域のみが
他のプロセスで使える様になる。
このうち、杉原さんがお考えの動作に一番近いのはどれでしょうか。
========================================================= )| /
井 町 智 彦 Imachi Tomohiko (~' -
~)(~
e-mail: ima...@totoro.ec.t.kanazawa-u.ac.jp ,_(m_m
URL: http://totoro.ec.t.kanazawa-u.ac.jp/~imachi
MAEDA Atusi (前田敦司)
> そこなんですがＡＮＳＩでは
> 「OSが解放する」と「「想定」」しているのでしょうか
なんか出発点に戻ったような...
In <95b92u$9pp$1...@ns.src.ricoh.co.jp> oh...@src.ricoh.co.jp (Junn Ohta) writes:
> ・ANSI Cの環境で
> ・free()すればメモリーリークしないのであれば
> ・free()しなくてもメモリーリークしないだろう
言い換えると「free()しないとメモリリークしちゃうようなOSだと、free()し
たってメモリリークする」ということです。ANSI CにはどんなOSがまともかな
んて規定はもちろんありませんが、そんなOS(どうやったってメモリリークが
起きるOS)は実用的じゃないのは確かでしょ? (まあそういう例が1つも出てな
いのに、ありそうもない話ばかり心配し続けるのはあまり健全とは言えません
が。)
> プロセスが終了していないときは「リークしてる」とは言わないと
> 思います。なぜなら、プロセスが生きているならそのメモリ領域は
> プロセスが「利用」している状態だと理解しているからです。
検索エンジンでX-Windowのメモリリークとかデーモンのメモリリークとかを引
いてご覧なさい。
;;; 筑波大学 電子・情報工学系(学術情報処理センター)
;;; 前田敦司 (MAEDA Atusi) ma...@cc.tsukuba.ac.jp