C++相談室 part129

1 名前：デフォルトの名無しさん(ﾜｯﾁｮｲ dfcf-HvS5) mailto:sage [2017/01/09(月) 14:49:27.56 ID:p96WJVyd0.net] 次スレを立てる時は本文の1行目に以下を追加して下さい !extend:on:vvvvv:1000:512 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part128 echo.2ch.net/test/read.cgi/tech/1480172629/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.100【環境依存OK】 echo.2ch.net/test/read.cgi/tech/1478440682/ ■長いソースを貼るときはここへ。■ 　codepad.org/ 　https://ideone.com/ [C++ FAQ] https://isocpp.org/wiki/faq/ www.bohyoh.com/CandCPP/FAQ/ (日本語) VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 830 名前：�捉えられない人にマトモな設計は難しい int intTypeVar=-1; [] [ここ壊れてます] 831 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 534f-v8EU) mailto:sage [2017/03/22(水) 08:29:35.78 ID:IQHE94uk0.net] 変数名に型を載せないほうがカッコいいと思ってるの？ それって逆にカッコ悪いと思う。 832 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddf-8YZg) mailto:sage [2017/03/22(水) 08:42:36.10 ID:rgAwiSmKd.net] 変数名に型情報いるか？って話だな そんな情報載せようとするぐらいなら変数名や関数名に拘れ 833 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddf-rwfr) [2017/03/22(水) 08:52:48.82 ID:gPjbW80sd.net] メンバのm_ と同じくらい無意味というか害悪 834 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 53bf-tW1y) [2017/03/22(水) 08:59:06.14 ID:iUoKjy2X0.net] >>814 m_ は好きだけどな。 手で握られてる感じが。 835 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 534f-v8EU) mailto:sage [2017/03/22(水) 09:01:02.66 ID:IQHE94uk0.net] 違いの分かる男 (ｽﾌﾟｯｯ Sddf-rwfr) 836 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddf-8YZg) mailto:sage [2017/03/22(水) 12:11:09.58 ID:rgAwiSmKd.net] フルページヒープしようとしてるがうまくつかえんぞなんだこれ gflag設定して対象ファイル実行するだけでなんとかなるんちゃうのか 837 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 18:09:01.13 ID:dqBQr4XV0.net] メモリ管理ってどうやってしてる？ テスト設計で必要なのだが調べても情報が少なくて使い方もあやふやで困ってる 自分のコードならまだしも人のコードだから品質保証するために必要なので困ってる助けて 838 名前：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM1f-vDuW) mailto:sage [2017/03/22(水) 19:28:52.80 ID:6SOT+CpTM.net] c++の場合、設計段階できっちりメモリ管理しないと死ぬ。 テスト段階だとどうだろ？どんなツールがおすすめかね？ 839 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 19:40:51.16 ID:dqBQr4XV0.net] >>819 昔からのコードだから俺にはなんとも言えないんだなぁ... タスクマネージャー開いて無限ループさせてたら地味にメモリ増えていくからたぶんリークなりメモリ破壊なりなんかしてそうなんだ 840 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f3c8-tpgq) mailto:sage [2017/03/22(水) 19:50:51.39 ID:E1Td5RgZ0.net] >>820 どこでリークが発生していて、どこでfreeするべきかをツールで発見したいって事？ そりゃ無理だろ。 それが出来ないからGC言語に逃げているわけだし、 それが出来ればRAIIすらゴミになるでしょ。 841 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cf1f-9jmm) [2017/03/22(水) 19:54:38.25 ID:0C1B3gPp0.net] メモリ管理はPHPとかのほうがムズい。 設計時でもコード書くときでも実動時でもメモリ消費を制御するのはムズい。正常動作でも想定外が起こる。 消費量が判ったところで実働時に減らすことはムズい。 "php 　メモリ　画面　真っ白　メモリ"とか定番ネタ 842 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 20:09:07.97 ID:dqBQr4XV0.net] >>821 いやそこまでは出来なくても良い ただ品質として確保したいだけ リークがあるかないかを判断できればおけおけ 843 名前：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM57-3fK7) mailto:sage [2017/03/22(水) 20:13:28.89 ID:svIchgSfM.net] >>818 環境がわからんからアドバイスのしょうがないんだが ソースがあってビルドできるならとりあえず valgrind とかで調べたら？ valgrind.org/ 844 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 336e-8FG5) mailto:sage [2017/03/22(水) 20:15:04.43 ID:i8R0t7KQ0.net] それならプログラム終了時にすべてのメモリが解放されたかチェックすればOK 845 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 20:15:57.49 ID:dqBQr4XV0.net] >>824 ふぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉまた英語か... 環境と言えるのはなんだろ visualstudio2008 Windows7 テストしたいのはdll 846 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ bf67-lir9) mailto:sage [2017/03/22(水) 20:25:44.20 ID:rzLKjPpj0.net] >>826 昔だったら、ぴゅりふぁい　っていうツールがあったけど。 847 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 737a-12+v) mailto:sage [2017/03/22(水) 20:26:09.25 ID:kq8u5G9J0.net] まともな開発環境なら名前以外から変数のスコープと型情報くらい分かるはずだよね 848 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f3c8-tpgq) mailto:sage [2017/03/22(水) 20:26:35.66 ID:E1Td5RgZ0.net] >>826 > テストしたいのはdll それって単にdllの呼び方間違えているだけじゃね？ dll 849 名前：呼んだ直後で片っ端からfreeしてみたら直るんじゃね？ なおVS2008にはプロファイラが付いてないが、最新VSには付いていたはず。 (俺は使ったこと無いけど) だからとりあえず最新VSでコンパイル通るか試して、そっちでデバッグするのも手だよ。 [] [ここ壊れてます] 850 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cf1f-9jmm) [2017/03/22(水) 20:31:15.79 ID:0C1B3gPp0.net] メモリ確保をすべて乗っ取って動作させてログ吐き出すやつでいいのでは? 851 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 336e-8FG5) mailto:sabe [2017/03/22(水) 20:35:57.13 ID:i8R0t7KQ0.net] お前ら意地悪だな VisualStudioならプログラム終了時にすべてのメモリが解放されたか チェックしてくれるDebug版お便利mallocがあるだろ _CrtSetDbgFlag で検索してみるとよい あと、ヒープ破壊を心配しているようだが Debug版mallocにはヒープ破壊検出機能もついてる もしオーバーランしていたりしたらfree時に怒られる 852 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cf1f-9jmm) [2017/03/22(水) 20:36:51.91 ID:0C1B3gPp0.net] これとか LinuxC | GC メモリ周りの基本的操作とテクニック Boehm GC 問題のあるプログラム #include <stdio.h> #include <stdlib.h> void memory_test(void){ char *p; p = malloc(1024); } int main(void){ memory_test(); return 0; } 実行するとエラーも出ず問題なく実行できます。 これは当然で、プログラム終了時にはOSがすべての資源(メモリやファイルディスクリプタ等)はすべて回収してくれるからです。 しかしこれは問題です。 Boehm GCの基本的な使い方 ではこのプログラムでBoehm GCを使います。 Boehm GCはmalloc(3)、realloc(3)の代わりにGC_malloc(),GC_malloc_atomic(),GC_realloc()を使います。 malloc(3)、reallc(3)、free(3)をそれぞれ置き換える作業だけです。 linuxc.info/memory/gc/ 853 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 20:37:32.91 ID:dqBQr4XV0.net] >>827 可愛らしいな聞いたことない >>829 dllの呼び方間違えてるとは？ 呼び出すドライバについては片っ端からのfreeはちゃんとしてあるぜ 新しい環境については会社での統一環境だから移行できんな... 854 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 20:41:03.02 ID:dqBQr4XV0.net] >>831 ちょっと調べてみる 一応確認だけどもdll呼び出すドライバの最後にちょろっとやればええんかな >>832 なんぞこれ 855 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ bf67-lir9) mailto:sage [2017/03/22(水) 20:41:15.04 ID:rzLKjPpj0.net] dllのソースもってるのかな？ 856 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 336e-8FG5) mailto:sage [2017/03/22(水) 20:45:10.10 ID:i8R0t7KQ0.net] ああ、dllのソースがないとだめだよ dllのソースがないのにメモリリークが有るか無いかしらべるのは さすがにムリゲーだよ 857 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 20:45:12.77 ID:dqBQr4XV0.net] >>835 持ってる むしろそのdllを今書き換えてるところかな んでテストする段階で悩んでるところです 858 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f3c8-tpgq) mailto:sage [2017/03/22(水) 21:00:54.62 ID:E1Td5RgZ0.net] >>837 とりあえず仮定を確認しよう。 1. dll以外の部分では今のところリークしていない 2. dllと組み合わせるとリークする んだよな？ そして書き換えているのは本体ではなく、dllなのか？ （これは俺の想定と逆だった） だったらお前がバグ入れただけじゃん。 859 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3392-8YZg) mailto:sage [2017/03/22(水) 21:06:53.51 ID:dqBQr4XV0.net] >>838 1 2 両方とも正しい んでもって俺が加えたのは型を修正しただけだからたぶん関係ない と言うか関係ない おそらく以前からある現象で以前のdllを利用しても同じ感じになる 2については組み合わせるとと言うよりテストのための実行ファイルを適当に作っただけかな 今回触れてない部分が大半なんだけどバージョンアップするから メモリ破壊なりも調べる観点が必用で umdhやらcrtデバッグやらページヒープやら調べてるんだけど...ってところ 860 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cf1f-9jmm) [2017/03/22(水) 21:34:34.94 ID:0C1B3gPp0.net] Boehm GCはオールCのはずでwindowsでもその他でも動作するし昔から定番だったはず。 だれもこれだしてないが・・ 861 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 5375-gO1F) [2017/03/22(水) 21:38:38.83 ID:sj71GTBZ0.net] Linux上でWine+valgrindやろ やったこと無いけど。 862 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f3c8-tpgq) mailto:sage [2017/03/22(水) 22:27:39.33 ID:E1Td5RgZ0.net] >>839 それは業務でやってるんだろ？ だったらまず、「以前の本体と以前のdllの組み合わせで、今のテスト」を行って、 リークしているようなら上司にどうするか聞いた方がいい。 このリークを直せというのは確実に手こずる。 そして逆に言えば、今それで出荷出来ているんならそれでも使い物になるんだよ。 だからリークがある状態で新機能付けて出荷も出来るはず。 ちなみに64bitアプリか？だったらリークはとりあえず無視する手もあるぞ。 863 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ bf67-lir9) mailto:sage [2017/03/22(水) 23:03:40.64 ID:rzLKjPpj0.net] 期末のこの時期に、メモリリーク。。こわい。。 UMDH調べてるなら、方向はいいとおもうけど。 上に、あげといた方がいいだろな。 時間食うかもしれん。 メモリ壊してると、動作不定になるからな。 864 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 63b7-rEFK) mailto:sage [2017/03/23(木) 00:17:11.61 ID:oAoB0YCS0.net] ttps://vld.codeplex.com なんかで調べてたときはこれ使ってたな。 めちゃくちゃ遅くなるけど。 865 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM4a-TrMc) mailto:sage [2017/03/23(木) 03:06:19.64 ID:52JJY4k+M.net] >>839 バグ修正は「おそらく」「たぶん」とかいう自信のない根拠を持たずに チマチマ地道に調べて積み重ねると早く解決するよ 866 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9375-iMo4) [2017/03/23(木) 03:37:19.31 ID:mYb1ScGd0.net] Linuxでも動かせるならvalgrindが最も簡単かつ実効速度以外最強なんだけどね。 Windowsのメモリエラー検出ツールはコレっていうのがない。 867 名前：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MMe2-hXJm) mailto:sage [2017/03/23(木) 06:43:06.01 ID:HovpjxiMM.net] valgrind なんてオープンソースだから誰かが Windows にポーティングしてるかと思ったら Windows is not under consideration because porting to it would require so many changes it would almost be a separate project. (However, Valgrind + Wine can be made to work with some effort.) ということなのね、残念 868 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sde3-2Cpe) mailto:sage [2017/03/23(木) 07:14:51.92 ID:ne+fmuh4d.net] >>842 後だしばかりですまんが32→64bitアプリへの移行中 64bitにしたさいにメモリ破壊なりがないかを確認するためにumdhやらを使おうってなってる あくまでリークしてるかも？ってのは俺がタスクマネージャー見ただけでの予測である 869 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sde3-2Cpe) mailto:sage [2017/03/23(木) 07:19:49.58 ID:ne+fmuh4d.net] おお...途中で送ってしまった >>845 それはわかってるんだけどどうにしろ 移行した影響があるかないかも含めて確認するために必要なこととしてツールで保証したいってのがある んで調査中でオススメのないかな？←今ここ ページヒープってのを見付けたんだがあからさまにメモリ破壊してるやつでも検出できないしこれ使ってる人居たら何に対応できるか教えてくれんか.... 870 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ fe1f-sIi0) [2017/03/23(木) 08:52:11.56 ID:UkDqG0iw0.net] ソースコードがあるなら汎用的なBoehm GCでいいだろうと 871 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9375-iMo4) [2017/03/23(木) 09:19:11.19 ID:mYb1ScGd0.net] 俺はつかったことないけど dynamorio.org とか 金出せるなら Insure++ってやつとか >>850 メモリリークしか検出出来ないでしょ 872 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa67-QN42) mailto:sage [2017/03/23(木) 09:23:00.74 ID:63eMbsST0.net] >>849 ツールで保証したい っていうなら、>>850が正しいかと。。 873 名前：e-72yv) mailto:sage [2017/03/23(木) 13:57:08.14 ID:FwJwtm3q0.net] ツールでメモリリークがないことを保証したいってだけなら VC++のランタイム付属のやつで十分だろ メモリ破壊が有ったかどうかも調べてくれるし こういったものが標準でついていて みんな空気のように標準的に使っているから 実際問題メモリリークはめったに起きないんだよ もしあったらプログラム終了時に教えてくれるからね だからメモリリークに対してはそんなに騒がれない 付属のやつで十分な品質を保証できるから たまーにしか通らないパスでメモリリークが発生していた場合など メモリリークの発見が遅れることはあるけど まぁ通ってないパスがある時点でテストが十分でないということだし 一か月に一回ほどの頻度でメモリリークするぐらいは別に問題ないという考え方もある ・・・っていうのもあって、まぁ付属の検出ツールで大体の品質は出る それよりはハンドルやGDIなどのOSリソースのリークが怖くて こちらは如何なるツールを使っても検出不可能で タスクマネージャなどで変にハンドルが増えてないかなど 地道に調べるしか方法がない だからハンドルなどは生で使わずにクラスにラップして使うのが通常だが 題意のDLLがどういう風になっているかは俺は知らん もしリークが発生してしまったらメモリリークより深刻な事態になる メモリよりもOSのリソースの方が貴重で制限が厳しいから むしろこっちのほうを気にすればよいのにと思ってしまう メモリリーク対策などVC++付属のやつに任せてしまってさ 874 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 14:02:35.67 ID:xx3Et9SY0.net] ツールに依存しきって分岐網羅とかやらなくなってるとしたら それはツールによって腐ったとしか言いようがない 875 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 14:11:13.36 ID:FwJwtm3q0.net] ちなみにリソースリークが発生していて 結果としてメモリ使用量がどんどん増えていくってのは有りうるよ タスクマネージャで調べたら使用メモリが増えていってる感じだったってことだけど それだけだと何が原因か、はたまた問題ないのか、難しいよ メモリ使用量を見るだけじゃダメで、ハンドル使用量etcも確認しないとね これはマナーとしてWindowsソフト開発者は絶対するよ リソースリークなんかしてたらむちゃくちゃ恥ずかしいし迷惑だから あと、リソースリークはメモリリーク検出ツールでは検出できないからね それから、もしリソースリークが発生していることが分かっても どこで発生しているか突き止めるのはメモリリーク以上に難しい、とは言っておく 876 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 14:26:25.40 ID:FwJwtm3q0.net] テストを走らせるときにVC++のメモリリーク検出機能をONにしておくと テスト終了時にメモリリークが発生したかどうか知らせてくれるというだけで メモリリーク検出ツールを使うことと テストの網羅が不十分なこととは関連性がないよ メモリリーク検出ツールを使ったから、何か油断して テストの網羅が不十分になるっていう理論の展開は 一般的におこらないというか、無理がある むしろテストを網羅しないとメモリリークを検出できないわけで 877 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9375-iMo4) [2017/03/23(木) 14:28:17.35 ID:mYb1ScGd0.net] valgrindではunixシステムの主要リソースであるfile descriptorのリークも検出出来るけどな 878 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 14:29:11.39 ID:xx3Et9SY0.net] おまえさっき、こう言ってたじゃん > たまーにしか通らないパスでメモリリークが発生していた場合など > メモリリークの発見が遅れることはあるけど 879 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 14:43:08.69 ID:FwJwtm3q0.net] それはテストが不十分ゆえに発生した問題であって メモリリーク検出ツールを使った事とは全く関係がない >まぁ通ってないパスがある時点でテストが十分でないということだし と書いておいただろ 880 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sdea-QN42) mailto:sage [2017/03/23(木) 15:03:37.80 ID:ixe949V5d.net] 無いことを保証するってのは、こわい文言だね。 dll内で、メモリ確保、解放してるところを、共通の関数に置き換えて、その上で、gcにおきかえかなぁ。 881 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 15:45:13.38 ID:xx3Et9SY0.net] >>859 関係大ありだよ 通ってないパスのバグが検出できないツールを使っているのに たまーにしか通らないパスをテストしないのは ツールを過信してる証拠だろうが 882 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 16:33:59.49 ID:FwJwtm3q0.net] いや、意味不明なんだが 通ってないパスのメモリリークが検出できないのは当たり前で そんな変な勘違いする人はいないし テストの網羅度が下がる理由はもっと別要因の別問題の別観点であり メモリリーク検出ツールを過信したからとか意味不明 「俺はメモリリーク検出ツールを使っているからテストの網羅度が低くてもOKだぜ」 ってシナリオがもうありえないっつーか、前提がおかしいだろ メモリリークしかテストしないかのような前提はおかしい メモリリークさえなければ出力が間違っててもOK、とはならないだろ となれば当然テストするだろ、リーク検出ツールの有無に関係なく むしろ、リークの有る無しより、出力のほうが大事だろ、そっち優先 そのためのテストであり、パスの網羅度が高ければ結果的にリーク検出度も高いというだけ どのぐらい完璧なテストをするか、すべてのパスを網羅できるか、は メモリリーク検出ツールを使うかどうかとは関係ない、また別の現実問題 883 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sdea-QN42) mailto:sage [2017/03/23(木) 16:44:15.11 ID:ixe949V5d.net] お、おまいら、そうおこるなよ。 >849 から、つづきもないし、上手く行っていることを祈ろう。 884 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 17:00:53.12 ID:xx3Et9SY0.net] > 通ってないパスのメモリリークが検出できないのは当たり前で だったらツールでは防げないバグの話にツールを持ち出すこと自体が大間違いだな 885 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 17:33:17.98 ID:FwJwtm3q0.net] ツールで防げないバグってのは 一度も通ったことのないパスのメモリリークの事を指しているんだろうけど それをどうにかしてほしいって話は無かったはずだが、どっから出てきたんだ？ そんな話してたか？ リーク検出ツールを使ってもテストの網羅度が完璧じゃなくて漏れてしまうこともある「が」 それでも一定の効果はあるので有用である という話はしたが テストのパスの網羅度が不十分で漏れてしまうメモリリークバグを ツールでどうにかする、とは俺は言ってないんだが、初めからな 886 名前：デフォルトの名無しさん (ｻｻｸｯﾃﾛﾙ Spd3-yqOs) mailto:sage [2017/03/23(木) 17:35:51.53 ID:argEiYvxp.net] >>853読んでそんなトンチンカンな理解をする方が大間違いだろう メモリリークが大して騒がれない、ってことに対するオマケの補足情報にどんだけ突っかかるんだ 887 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 18:00:16.89 ID:xx3Et9SY0.net] おまえ853で開口一番こう言ったぞ > ツールでメモリリークがないことを保証したいってだけなら > VC++のランタイム付属のやつで十分だろ どっから出てきたって、おまえの口からだよ 888 名前：デフォルトの名無しさん (ｽｯｯﾌﾟ Sd4a-ejJz) [2017/03/23(木) 18:26:51.25 ID:pJ6fwoOxd.net] また言った言わないの揚げ足取り合戦かよくだらねえ 889 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 18:34:26.25 ID:xx3Et9SY0.net] 話の本題を無視して言葉尻にだけ突っかかる誰かさんのようなのを揚げ足取りというんだよ 890 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sde3-2Cpe) mailto:sage [2017/03/23(木) 18:54:08.36 ID:ne+fmuh4d.net] >>863 ありがとう とりあえずでboehmでメモリリーク監視することになった 思いきりリークしてるみたいだからどうしようかと悩むが... 別件なのだけどvc6環境のC++とvc9環境のC++で差分の出る演算ってあるかな？ for文のスコープの範囲が変わるぐらいしかわからんくて 大きな演算の違いはないのだろうけどもそれぞれの環境でのモジュールで 本当に微々たる差が出ているみたいで... 基本的には結果に差分がなく、特定のパラメータファイルの時だけ差分が出てしまう。その差も30mb中の0.1％も満たないぐらい やってることとしてはvc6→vc9環境へプロジェクトファイルの移行 891 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sde3-2Cpe) mailto:sage [2017/03/23(木) 19:11:57.84 ID:ne+fmuh4d.net] パラメータファイルって書くと設定値みたいに見えるね 特徴抽出したやつに演算かけてます 892 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/23(木) 19:20:15.49 ID:Ei+8urX30.net] >>848 32→64bit移行の安全性を実行時ツールで検出、というのはかなり無理じゃないか？ だからみんなソースコードをチェックしているわけだし。 sgry.jp/pgarticles/64.html yukinarit.blog11.fc2.com/blog-entry-27.html qiita.com/izmktr/items/59085ca70a6c11b0b352 >>870 > 思いきりリークしてるみたいだからどうしようかと悩むが... 32→64bit移行ではリーク自体は発生しないぞ。 それは結果的に症状がリークなだけで、根本的に駄目なところがあるんだよ。 まずは32bitの旧バイナリと新テストパターンで足場を固めないと駄目だと思うぞ。 数値演算結果の誤差ならSSEとx87の精度の違いかもしれん。 ただしVC9(VS2008)は演算にはSSEを出せなかったはずだから関係ないとは思うが。 893 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sde3-2Cpe) mailto:sage [2017/03/23(木) 19:36:37.57 ID:ne+fmuh4d.net] >>872 長々とサンクス 思いきりリークしてるから..ってのは元々からリークしていただろうから 対処をどうしようか悩むなぁって意味でした SSEとx87についてちょっと調べてくる 894 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7b7a-7HKf) mailto:sage [2017/03/23(木) 19:50:33.67 ID:CpsZOT5F0.net] 浮動小数点の丸めモードが違うとかあるか？ 895 名前：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MMe2-7Y/j) mailto:sage [2017/03/23(木) 20:04:25.70 ID:8W2HqVqhM.net] >>870 vc6って標準準拠してたっけ？ c++のような何かだったような気がするけど。 896 名前： ◆QZaw55cn4c (ﾜｯﾁｮｲ a6ff-nbIt) mailto:sage [2017/03/23(木) 20:26:53.12 ID:qM4EW3hi0.net] >>870 ベームGCか，なかなか息がながいライブラリだね 897 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7b7a-7HKf) mailto:sage [2017/03/23(木) 20:32:55.87 ID:CpsZOT5F0.net] >>875 当時は標準規格というもの自体が無かった 898 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/23(木) 20:37:31.58 ID:Ei+8urX30.net] >>873 あと、FMACの最適化がどこかであったはず。 （ただしググッても出てこないので、俺がGPUの話と混同して勘違いしているだけかも) 内容は、FMACの中間結果を精度が高い状態で保持しておき、FADDに突っ込むというもの。 これに該当した場合は、結果がハードウェア依存になる。 (旧ハードと新ハードでFMACの結果が微妙に異なる) だから同一ハードでの新旧バイナリでの結果をdiffしているのなら、これは該当しない。 環境移行が面倒等で、旧マシンで結果だけ作って新マシンと比べている場合、当たるかもしれない。 ただし再度言うが、GPUの話だったかもしれんのでよろしく。 899 名前：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MMe2-hXJm) mailto:sage [2017/03/23(木) 20:40:17.12 ID:HovpjxiMM.net] >>870 > 別件なのだけどvc6環境のC++とvc9環境のC++で差分の出る演算ってあるかな？ 正しいプログラムだとそんなに変更はないと思うけど、例えば引数の評価順に依存しているプログラムの動きが変わるって言うのはC言語あるあるだから 要するにバグの顕在化って奴ね なのでコンパイラ替えたら一通りテストした方がいい 900 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa67-QN42) mailto:sage [2017/03/23(木) 21:06:58.74 ID:63eMbsST0.net] 幸いなことに、再現性のあるバグだ。 メモリ関連にしては、ましな方。 画像データなんだよな？ 当時だと、特徴抽出前にグレースケールにしてたもんだが。。 そのデータだけ、サイズが縦横違うとかないかな。 どっかで、メモリの取り方(x方向、y方向のピクセル値)間違えてるとか。 あるいは、メモリを取り直してたりしてないかな。 reallocとか。 実務的なとこでは、仕事の落とし所も考えといた方がいいかも。今回は、調査だけなのか、移植までなのか。。 901 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 21:15:40.12 ID:FwJwtm3q0.net] >>867 もうあんまり話したくないけど、最後に言っておくと 実用上問題ないレベルで保証できればそれでよいだろってこと 100%バグがないことを保証するのはどうやっても何やってもどんなツール使っても 無理なのは当たり前の常識だろ VC++付属の検出ツールでも実用上問題ないレベルでのメモリリークの検査はできるし コードに2,3行追加するだけで、壮大にメモリリークしているかどうかぐらいは 直ぐにでもチェックできるから、とりあえず試してみろって話をしたんだよ というか、普通はONにした状態で開発しているものなんだよ あえてOFFにしとく理由は何もないからな、邪魔になるわけでもなし 質問者が何であえてOFFにした状態で開発していたのかは定かではないが 知らなかったってことなら今日からONにしとけばよいだけだろ で、実用上云々の説明がそのあとに続く「稀に漏れることがある」って話で >たまーにしか通らないパスでメモリリークが発生していた場合など >メモリリークの発見が遅れることはあるけど >まぁ通ってないパスがある時点でテストが十分でないということだし >一か月に一回ほどの頻度でメモリリークするぐらいは別に問題ないという考え方もある と書いたんだよ そのどうでも良いところにかみついて揚げ足取りしたのはお前だろ 902 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7b7a-7HKf) mailto:sage [2017/03/23(木) 21:24:27.07 ID:CpsZOT5F0.net] >>880 計算部分だけブレークポイント使って一行ずつ実行しながら見比べてみろよ 903 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa67-QN42) mailto:sage [2017/03/23(木) 21:33:57.23 ID:63eMbsST0.net] >>882 そだな。データが特定されてるんだもんな。 904 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b6e-72yv) mailto:sage [2017/03/23(木) 21:38:04.51 ID:FwJwtm3q0.net] boehmは詳しくないが、普通メモリリーク検出ツールは どこで確保したメモリがリークしたのかわかるようになっている物が多いはずだぞ その周辺を漁ればメモリリークの箇所を特定することはそう難しくないハズ VC++付属のツールの場合は ttp://yukinarit.blog11.fc2.com/blog-entry-38.html ↑のようにしておくとリークしたメモリを確保した箇所の 「ソース名」「行数」「ダンプ」がわかる あとはちょっとソースコード追いかければリーク箇所を特定できるはず 905 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa67-QN42) mailto:sage [2017/03/23(木) 21:47:32.04 ID:63eMbsST0.net] memcpyとかも、解放、抜けたりしがち。 906 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be6b-72yv) [2017/03/23(木) 22:20:42.38 ID:xx3Et9SY0.net] > 実用上問題ないレベルで保証できればそれでよいだろってこと 実用上問題あるかどうか、おまえ勝手に決めてるのか？ 907 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2b92-2Cpe) mailto:sage [2017/03/23(木) 22:36:32.61 ID:ViT7/D1o0.net] すまん めっちゃレスもらってるから全部に逐一は答えられんわ まず答えてくれてる人ありがとう助かる >>879 俺もそうは思うんだけどもVC6時代のテスト項目とか残っていない さらに言えば仕様書や設計書すらなく困り果ててる >>880 サイズ自体が異なっていたから何かしらの処理で変な取り方をしているのだろうとは考えてる 実務のことだからほぼほぼ影響を与えないのであればコストと相談してスルーってのもありだけど...そこは要相談なんだろうな >>882 俺もそうはしたいんだがVC6環境がないから対比で比べられないんだわ 908 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2fb4-QntA) mailto:sage [2017/03/23(木) 23:14:34.92 ID:v1/Wdv6U0.net] valgrind自体はともかくvalgrindという単語を見て 以前このスレに現れたキティガイを思い出した 909 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ fe75-i4+Q) mailto:sage [2017/03/24(金) 00:06:32.21 ID:8SSjzg+S0.net] 漏れも、仕様書や設計書がない、DLLからエラーが返ってくるから、 そのDLLをデバッグしてくれとか、 1月150万円で、上場企業から請け負ったこともあるけど、 こういうのは直しても、切りがない。 違うタイプのデータが来ると、またエラーになる 無理だと断っても、また見てくれって言う。 そのDLLが何をやっているのか分からないし、仕様書もないから、 新規に作り直すことは無理だから C/C++で解析できる人なんて、まず見つからないから 910 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7b7a-7HKf) mailto:sage [2017/03/24(金) 00:16:13.17 ID:DhGI6SB10.net] ハッカーに1000万払おう 911 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/24(金) 00:17:14.57 ID:RtKD05ZR0.net] >>889 マジカヨ？ちょっとその仕事試しに受けてみたいかも。 それってどれくらいの規模だった？ 912 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 63b7-rEFK) mailto:sage [2017/03/24(金) 00:18:51.24 ID:9w5lj4S/0.net] >>887 めっちゃスルーされてるけど >>844 は結構良かったよ。リーク箇所のスタックトレースまで出力される。 あとVC++標準のは誤検知する場合がある。 googleのv8でリークが誤検知されてた。 913 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9375-iMo4) [2017/03/24(金) 01:09:06.67 ID:DlmXd06I0.net] >>892 VC標準の貶すと顔 914 名前：真っ赤にして怒り出すやつ居るから気を付けろ [] [ここ壊れてます] 915 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9375-iMo4) [2017/03/24(金) 01:23:02.12 ID:DlmXd06I0.net] 彼にとってはリーク箇所のスタックトレースなんか要らないし、誤検出は使い方が悪いし、リークするコードなんて書かないから高機能は必要ないらしい。 挙げ句の果てに(自分の書いたコードに対して使うとも言ってないのに)そもそもリークするコード書いてる低脳と煽ってくる。 916 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/24(金) 01:25:52.24 ID:RtKD05ZR0.net] >>887 ついでにこんなんが出てきたので貼っておく。 > サイン、コサインをインテルの CPU で計算すると少しバグっているらしい > tomeapp.jp/archives/1282 要するに、x87のアセンブラ命令 FSIN, FCOS 等には誤差が出る場合があって、 これを嫌うコンパイラの場合は自前で計算しているらしい。 だからコンパイラを変更した場合、sin,cosの値が微妙にずれる事があり得る。 VC6->VC9でどうなのかは知らん。 917 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1b84-rs+5) mailto:sage [2017/03/24(金) 01:39:49.34 ID:uwgr9JVd0.net] FPUのPIの値がちょっと誤差持ってるって話じゃなかったっけ？ 918 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/24(金) 01:58:41.18 ID:RtKD05ZR0.net] 俺はこれは初耳だったからよくは知らない。 > In a single Intel publication, the problem is partially acknowledged. The 1999 edition of Intel Architecture Software Developer’s Manual Volume 1: Basic Architecture (download) states: > > The trigonometric instructions may use a 66-bit approximation to the true value of pi to reduce the magnitude of the input argument. In this case, the final computed result can vary considerably from the true mathematically precise result. > > This statement, which never again appears in a public Intel document, acknowledges the argument reduction problem. However, the entirely separate problem of large errors near argument multiples of pi/2 is not addressed. > notabs.org/fpuaccuracy/index.htm 主張としては、sinXのXが無駄にでかい時は仕方ないとして、 pi/2の倍数のところに誤差があるのは駄目だろ、ということらしい。 つっても仮数部が10bit多いし、doubleに丸めるなら見えなくなると思うが。 正直なところ、浮動小数点の演算結果比較はこの手の落とし穴が大量にあるから、 完全一致は諦めて、4bit位の誤差までは見逃すようにしないと現実的に無理だと思う。 919 名前：889 (ﾜｯﾁｮｲ fe75-i4+Q) mailto:sage [2017/03/24(金) 02:13:33.84 ID:8SSjzg+S0.net] >>891 20年前の話 プログラマー・SEは、1人月100〜150万円だけど、 会社が取ってくる仕事だから、社員なら1/3、派遣なら7割もらえる。 ただし、派遣では生活保障がない どこの大企業でも、プログラムの仕事は、ちょいちょいあるだろ >>895 JavaScriptでも誤差があるよ function calcNumberOfDigits(x) { return Math.floor(Math.log2(x)) + 1; } calcNumberOfDigits(Math.pow(2, 53) - 1); floorで切り捨てているから、52+1=53 になるはずなのに、54になる！ Math.log2(x) = Math.log(x) / Math.LN2 これは、除数・被除数ともに誤差があるから、時々おかしくなる 920 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/24(金) 02:49:48.36 ID:RtKD05ZR0.net] >>8 921 名前：98 いやその話じゃない。FSIN,FCOSの誤差の話は、 Intelは 1.0ulp 誤差だと言っているのにそうなってない、という話。 (とは言え仮数部が10bit多いのだが） 君が言っているのは数学的なものとだろ？ それは浮動小数点では誤差があるのが仕様。 > floorで切り捨てているから、52+1=53 になるはずなのに、54になる！ これは間違い。以下。 Math.floor(Math.log2(Math.pow(2,53)-1))+1 // 54で正しい。 Math.log2(Math.pow(2,53)-1) は、52よりも53に限りなく近いから、53になる。 > これは、除数・被除数ともに誤差があるから、時々おかしくなる これも上記の通り、認識間違い。 Math.LN2はそもそも「浮動小数点的には」誤差がない。 というより計算済みの値が使われる（はず） Math.log2(x)等の関数は一般的に割り算での実装はされないはず。 理由は以下。 ・割り算は誤差が出やすい（多分テーラー展開式等が使われる） ・割り算は遅い ・そもそも固定値割り算は逆数の掛け算に変更される （とはいえ、現実的にはこの方法は割り算よりも誤差が出たりするが） だから、 > Math.log2(x) = Math.log(x) / Math.LN2 が成立しない時も、それは浮動小数点計算による誤差であり、仕様。 [] [ここ壊れてます] 922 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa67-QN42) mailto:sage [2017/03/24(金) 03:00:17.44 ID:GqbwU5RX0.net] >>887 ソフトウェアとして、ライフサイクル切れてるのではないか。。 仕様がないのでは、検査できないではないか。 来期別案件で、再構築も提案していいかもな。只、お客さんから見ると機能がふえるわけではないから、なかなか首を縦に降ってもらえないのだが。 923 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sdea-2Cpe) mailto:sage [2017/03/24(金) 07:12:58.02 ID:pzB5kBTUd.net] >>892 すまん スルーしてるつもりはない 全レスすると全レスやつ〜って煽られたことあるから数多いときは一部にしてた... >>895 これの可能性ある気がする VC6時代のは別コンパイラでもコンパイルしてた〜みたいな話聞いてたから 今リリースされているのが別環境で用意ができるのであれば探してみるよありがとう >>900 だよね 設計者や仕様書が如何に大事かがわかったよ 924 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa1e-t8fU) mailto:sage [2017/03/25(土) 03:58:44.57 ID:D917NA3h0.net] 設計者: 私が辞めても代わりはいるもの 925 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ be8c-72yv) [2017/03/25(土) 18:13:50.51 ID:2Y4XLGXL0.net] プロとしての規律を大事にお仕事してるんですね 926 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ aa90-VHv+) mailto:sage [2017/03/26(日) 15:26:40.92 ID:pwPfsDuW0.net] >>895 こんなのあるんだ・・・誤差という言い方は語弊があるような 立派なバグじゃないですかインテルさん というかハードウェアって直せないの？ 927 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1b84-rs+5) mailto:sage [2017/03/26(日) 15:50:44.38 ID:rQp0RVJN0.net] ソフトウエア資産的に修正ると多大な影響がある。 928 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7b7a-7HKf) mailto:sage [2017/03/26(日) 15:52:58.04 ID:r1GdkURH0.net] 特定のプロセッサが生産時期で結果が変わるとか地獄しかない 929 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bc8-VHv+) mailto:sage [2017/03/26(日) 16:15:08.70 ID:Uwt+/Suh0.net] >>904 多分原因は>>896からみのPI等の桁落ち（桁不足）だろうから、 修正自体は簡単で、増やせばいいだけ。 ただし、既存ソフトへの影響が大きすぎるのと、 そもそもx87の仮数部は10bit多くて、doubleに格納した場合は丸められるわけだから、 顕在化する確率はかなり低い。 この問題もx87(1980年)からなら30年以上経って発見されたわけだし。 また現在の科学技術計算ではdoubleが主流でx87は使われなくなりつつあるし。 だから、当面は無視するのが常策だよ。 930 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ fe1f-sIi0) [2017/03/26(日) 18:22:41.51 ID:Ntld20FG0.net] >>906 浮動小数点ではよくある、気にならないとおもうが・・ 浮動小数点の演算は誤差、ケタ落ちを考慮するのが普通。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef