元スレCygwin + MinGW + GCC 相談室 Part 4
gcc覧 / PC版 / みんなの評価 : ☆
前へ
501 = :
どう失敗するのか書けよ。
ライブラリがないのか？ 実行時エラーか？ エラーメッセージは？
503 = :
普通にインストールしてればインポートライブラリは入ってるよ。
504 = :
もしかして、Cygwinのgccで確保出来るメモリ量って結構少ないですか？
膨大なソースで多分1日仕事になるであろうソースがあるんですが、
_cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
ってエラーが出てて、どうもmallocかけてる所が怪しいんです。
ちなみに、SolarisとFreeBSD(両方64bit版)では動いてます。
Windowsは、XP x64だけど、多分Cygwinは32bitのはず。
でも、32bitの領域食いつぶしてるとも思えないしなぁ・・・
505 = :
Ubuntu 9.04 で g++ 4.3.3 を使っているのですが、メモリ管理で質問があります。
std::list に例えば int 型のデータを例えば1000万個くらい突っ込み、topでメモリ使用量を確認すると、
150MBくらい使用しています。
その後、データが不要になったあとで clear() メソッドで中身を消去し、利用した関数を終了させて
list を完全に削除した後でも、top で確認するとメモリが開放されずに残ってしまいます。
このメモリが開放されるのは、アプリケーションが終了されるときのみです。
この理由を知りたいのですが、ご存知の方は教えていただけないでしょうか？
試行錯誤してるうちに、std::list 以外でも、例えば
new int[10000000] した後にデータを突っ込んだメモリは delete[] で消えますが、
for(int i=0 ; i<10000000 ; i++){
... = new double;
}
してデータを突っ込んだメモリはすべて delete しても
やはりメモリが残ってしまうことに気づきました。これも関係ありそうな気がします。
506 = :
逆アセンブルのリスト取ってsbrk()の呼び出してる箇所を見てみたら？
malloc()はsbrk()を大抵呼び出すがfree()は単に未使用ブロックとして
マークし直すだけの事が多いのでフリーリストのフラグメントが起きると
うまく再利用されない事がある
507 = :
>>505
あなたにメモリ管理についての知識が無いだけ。
例えばmallocの実装がどうなっているか、一度調べてみると良い。
>>504
実装にバグが無ければ
メモリが足りない時は、mallocはNULLを返す。
malloc呼び出しの内部で落ちるのは、
アプリケーションがmallocの管理領域を壊している可能性が極めて高い。
例えば、1byteはみだして書き込んでいる場合、
64bitだとアラインメントの都合ではみだしていることが表面化しない場合がある。
508 = :
>>505
単純にそれだけするテストをやってみたってこと？
一般に new (malloc) で確保したメモリを delete (free) した場合、
それらの領域は次に new したときに再利用される。
一旦確保したメモリはアプリケーション側で掴んでいるので、
そのアプリケーションが終了するまでは OS 側にしてみれば使用中に視える。
BSD 系のどれだったかでは一旦 OS に返すような実装のもあったような気がする。
509 = :
>>505
大きなメモリブロックはOSから直接もらってOSへ直接返し、
小さなメモリブロックは独自に管理するのでOSへ返さず掴んだまま、
という実装は十分ありうるので、一応説明は付く
510 = :
Cygwinって一応内部ではWin32呼んでるんだよね
こういうの組んでみたけど結構こまめにOSに返してるよ
#include <iostream>
#include <windows.h>
const int l = 10000000;
int main()
{
double** a;
MEMORYSTATUS ms;
a = new double*[l];
for (int i = 0 ; i < l; i++)
a[i] = new double;
GlobalMemoryStatus(&ms);
std::cout << ms.dwAvailPhys << std::endl;
for (int i = 0 ; i < l; i++)
delete a[i];
GlobalMemoryStatus(&ms);
std::cout << ms.dwAvailPhys << std::endl;
delete[] a;
GlobalMemoryStatus(&ms);
std::cout << ms.dwAvailPhys << std::endl;
}
511 = :
「OSからの取得」をどうやっているのか、にも依存するよ。
例えばHeapAllocで獲得しているのだとしたら、
それは事実上mallocの実装そのものだから
その内部で(システムコールを呼んで)カーネルに返しているかどうかは
HeapAllocの実装次第。
>>506の通りにsbrk()経由とするなら、その中で何が呼ばれてるかだね。
512 = :
OS によってメモリ管理に関する方針はかなり違うけど、
Linux の場合は「なるべくめいっぱい活用する」方針だったと思う。
普通に使ってたら空いてるメモリはほとんどなくなるはず。
513 = :
>>501-503ありがとう
どうやってもldが「undefined reference to ○○」言ってくるんですよ
>>500こうなったらもうインポートライブラリに頼らないで直接呼んじゃる！！！
という方針で書いてみた（といってもほとんどhttp://www.atmark.gr.jp/~s2000/r/rtl/shlwapi.html ）のが↓
514 = :
#include <windows.h>
#include <stdio.h>
typedef int (*TFUNC)(LPCTSTR,LPTSTR,UINT);
int main(int argc, char *argv[]) {
char str[100];
int ret;
HINSTANCE hInstDLL;
TFUNC DllFunction;
517 = :
>>513
gcc は実はインポートライブラリ無しでも dll とリンクできる。
-lshlwapi の変わりに /cygdrive/c/WINDOWS/system32/shlwapi.dll としてみれ。
519 = :
>>378, 379
TDM版MinGW使ってみた。なかなか良くてCode::Blocksとの相性もバッチリなんだが，
STLがやたら遅い(gccの問題だと思う)ので，STLPort5.2.1をビルドしようとしたら，
うまく行かない。
一応ドキュメントも読んだんだが，MSYS上からmake gcc.makってやっても「何もすることが
ない」って言われてビルドできない。
TDM版MinGWにはmake.exeはなくてmingw32-make.exeしかないけど，これは使っちゃいけないと
書いてあるので，MSYSにあるmake.exeでやってみたんだが．．．
やり方教えてもらえると嬉しい。
520 = :
>>519
make -f gcc.mak じゃね？
521 = :
>>520
> make -f gcc.mak じゃね？
そうそう、まずそれだった。普段IDEばかり使ってるんでmakeコマンドの使い方忘れてた。
で、まずは落ち着いてやってみようと思って、MinGWを通常の5.1.4に戻して、
>>331を参考にSTLport5.1.7をビルドしてみた。
gcc.makというファイルは二箇所にあるけど、\build\libの下のヤツを使って、
make -f gcc.mak depend
make -f gcc.mak install
でビルド成功。ちなみに>>331の、
> # if (__W32API_MAJOR_VERSION > 3) || ((__W32API_MAJOR_VERSION = 3) && (__W32API_MINOR_VERSION >= 12))
の = 3 のところは、== 3 が正解。で、ビルドは出来たんだけど、C++版Hello World!プログラム(iostream使うやつ)
で試してみたら、コンパイル時に「#includeのネストが深すぎる」ってエラーがでた。
今仕事場にいないので詳細はわからない。続きはまたあしたかな．．．
522 = :
MinGW5.1.4＋STLPort5.1.7でテストをしてて，STLPortのビルドは出来たけど（Thanks to >>331），
使うとうまく行かない。 以下のHello world!! C++版をコンパイルしてみた。
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
環境変数は入念にチェックして，MinGW標準のC++用ヘッダがインクルードされずに，stlportのヘッダが
読み込まれるようにしたんだが，コンパイルすると_cstddef.hの28行目の
# include _STLP_NATIVE_CPP_C_HEADER(cstddef)
のところで，
C:\MinGW\include\stlport\stl\_cstddef.h|28|../3.4.5/cstddef: No such file or directory
と言うエラーが出て，後はエラーの嵐。grepでいろいろ調べた結果，MinGWの場合
_STLP_NATIVE_CPP_C_HEADERの定義がうまく出来てないらしいことまではわかったんだが，
どうすればいいんだろ。教えてエライ人。
523 = :
何とか自己解決。
■ビルドはMSYS付属のmakeじゃなくて，WindowsのコマンドプロンプトからMinGWの
mingw32-makeでやる（ドキュメントをよく読んでたら書いてあった）。但し，MSYS使わ
ない場合はconfigure.bat -c gcc しろって書いてあるけど，これはウソ。
configureしてからメイクすると速攻エラーが出る。
mingw32-make -f gcc.mak depend
mingw32-make -f gcc.mak install
だけでOK。
■unitテストはロケール関係で少しエラーが出た。ehテストはso_stlgだけ，
EH TEST FAILURE !
[deque] :testing range insertion at random position (weak)
ERROR : 37 outstanding allocations.
となったが，so_gとsoはパス。ちなみにこのso_stlg, so_g, soというフォルダに3つ
同名のテストプログラムが出来るけど，違いは何なの？（unitテストsoとso_stlgの
2つのフォルダ内にexeができる)。
■STLPortのヘッダやライブラリを置いた場所や元のMinGWのフォルダ構成にあわせて，
stlport/stl/config/host.h を丁寧に書き換えてやる必要がある。
まぁ，いろんな環境に対応しなければならないので作る側の苦労はこんなもんじゃないと
思うが，ドキュメントはもう少し整備してまとめて欲しいなぁ．．．
524 = :
TDM-MinGW4.4.1出てるな
525 = :
>>524
・・・あの、4.4.0がインストールしてある場合、
アップデートするには
Create
: Create a new TDM/MinGW installation
Manage
: Manage an existing TDM/MinGW installation
Remove
: Remove a TDM/MinGW installation
のうちどれを選べば最も望ましいでしょうか？
528 = :
529 = :
>>524
これ使うと，サイトの上の方にピンクの囲みで書いてあるとおり，実行のものすごく遅い
プログラムが出来上がってしまう。
それでcoreとg++はサイトの下の方にある4.3.3を使ったら解決したよ。
531 = :
WARNING:
The 4.4.1-tdm-1 release is known to have a bug which causes drastically increased CPU usage in programs compiled with it. You are urged to use a previous release until this bug is fixed.
excite＆俺訳↓
警告:
4.4.1-tdm-1リリースにはそれでコンパイルされたプログラムがCPUパワーをものすごく使うようになってしまうバグがあるのが知られています。このバグが修正されるまであなたが前のリリースを使用することを推奨します。
マジかよ！おじさん、気付かず更新しちまったぜ
532 = :
みなさんありがとうございます。
どうやら
CreateとManageの違いは、
Manageの場合はインストール先のパスなどが引き継がれて便利ということ
だけっぽいです（完全に私の勘ですが）。
・・・ですが、インストールしてみたところに>>529さん、>>531さんのレスをみて
即刻以前のインストーラを使って元に戻しました。
533 = :
>>531のレスを見て疑問なのですが、
これはgcc4.4.1のバグでしょうか？
それとも 4.4.1-tdm-1 release独自のバグなのでしょうか？
ご教示いただけませんでしょうか？
よろしくお願い申し上げます。
534 = :
> gcc4.4.1
Fortran, C, and C++ for Windows
http://www.equation.com/servlet/equation.cmd?call=fortran
↑
こっちのは別に問題なさそうだけど。
535 = :
>>534
となるとTDMのバグの可能性が高そうですね。
ありがとうございます。
536 = :
どうせいずれ直るでしょ
俺は速度はそんなに気にしていない(コンパイルが通って動けばいい)派
なので気にしていない
537 = :
TDMが止めた方がいいっていってるんだから
俺は止めとこう。
・・・ってまあホント好き好きにすりゃ良い問題だよな。
538 = :
>>536
> 俺は速度はそんなに気にしていない(コンパイルが通って動けばいい)派
> なので気にしていない
それがさぁ、条件によっては実用にならない位遅くなるんだよ。
100行位のUNIDCODEのファイルを読み込ませて処理するソフトでテストしたら（STL使用）、
VC++やBCBでコンパイルしたものは数秒で終わるのに、TDM-MinGW4.4.1だと
10分位かかった。
で、>>529に書いたように、coreとg++だけ4.3.3をダウンロードして上書き解凍してコンパイルし
なおしたら、ちゃんと数秒で終わるようになった。
539 = :
>>538
そんなにひどいのか
じゃあ4.3.3に戻すか
簡単に戻せるしね
SourceForgeからDLできるのであっという間だし
541 = :
>>538
g++ (TDM-1 mingw32) 4.4.0に戻したのですが、
これもバグを抱えていますか？
4.3.3レベルまで戻す必要はありますでしょうか？
542 = :
>>541
ごめん、4.4.0は持ってないし試してないのでわからない。
けど、サイトにそうは書いてないから大丈夫なんじゃないのかな？
543 = :
>>542
ありがとうございます。
過去のサイト（Web魚拓みたいなもの）をあさって見たのですが
4.4.0リリース時点までは戻れなくて。。。
545 = :
TDMに限らずMinGWにはbashは入っていない
msysを落とせ
546 = :
>>545
トンクス
548 = :
>>507
メモリ不足でNULLが返るかというと微妙。
mallocは成功して、実際にメモリを使う時(読み書き)すると初めてメモリを割り当てて不足したらそこで止まるようなシステムもある。
Linuxなんかはそう。
549 = :
そんなのあるのか…manpageでバグ扱いされてるな
550 = :
>>548
ここはCygwinのスレであって、Linuxのスレではないし
落ちるのがmalloc内部と限定される場合には当てはまらない。
だいたい、「落ちる」と言っても
セグフォールトのような症状で落ちるのではなく
「有無を言わさずプロセスがkillされる」だけなのだから。
みんなの評価 : ☆
gcc一覧へ類似してるかもしれないスレッド
- Cygwin + MinGW + GCC 相談室 Part 8 (938) - [97%] - 2022/10/28 8:00
- Cygwin + MinGW + GCC 相談室 Part 7 (996) - [97%] - 2014/9/21 2:15
- Cygwin + MinGW + GCC 相談室 Part 6 (981) - [97%] - 2012/12/30 23:15
- Cygwin + MinGW + GCC 相談室 Part 5 (981) - [97%] - 2011/4/6 2:32
- Cygwin + MinGW + GCC 相談室 Part 3 (1001) - [97%] - 2008/9/12 0:04 ★
- 【激遅】AppleGCC【絶望】 (111) - [1%] - 2010/1/15 10:31
トップメニューへ / →のくす牧場書庫について