トップページ⇒tech
455コメント137KB

new/deleteで異常終了する（Visual C++）

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/01/06(水) 20:35:52
大変、困っています。
Visual C++ 2008でコーディングしています。
コーディングは何度も何度も見直しました。
間違っていません。

なのに、実行するとnewで異常終了します。
debug版で動かすと動きます。release版で動かすと異常終了します。
デバッグのしようがありません。

ホントに、コーディングは正しいんです。
こういう症状の原因って何が考えられるでしょうか。

よろしくお願いします。

deleteでも異常終了します。
未初期化ポインタのdeleteとかそんなのではなくて、
本当にコーディングはあってるのに、異常終了します。

動きは、毎回違います。
例えば、printfデバッグをしようとしてprintfを
挿入すると、異常終了ポイントが変わります。
でも、newかdeleteで落ちます。

ホントに、ホントに、コーディングは合ってるのに
どうしようもありません。

もう何ヶ月も仕事が進みません。
このままだと、クビになっちゃいます。

お願いします、本当に、よろしくお願いします。
0175デフォルトの名無しさん2010/01/14(木) 08:31:07
> STLやスマートポインタを使ってないことが糞なのでしょうか。
知識の不足なんてさして問題じゃない。
察しの良い奴ならすぐに学習するからな。

メモリ破壊を指摘されても「僕悪くない！！」に徹した
技術屋としては最低最悪な外道だから糞なんだよ。
0176デフォルトの名無しさん2010/01/14(木) 09:10:13
>>175
コードの話をしてるんじゃなかったのか?w
0177デフォルトの名無しさん2010/01/14(木) 13:03:29
ここまで読んでみましたが、ライブラリというより、呼び出し元が原因ぽいんですよね。
どういうことをしていて、newで落ちてたようだ、ということだけでも書いていただければ、勉強になるんですが。
はっきりしないんでしょうかね。
0178デフォルトの名無しさん2010/01/14(木) 13:04:56
>>170
>>43
0179デフォルトの名無しさん2010/01/14(木) 19:15:38
>>170 >>1
Visual Studio デバッガ ネイティブ コードのデバッグ
http://msdn.microsoft.com/ja-jp/library/k70yt3e2.aspx
Visual Studio デバッガ メモリ リークの検出と特定
http://msdn.microsoft.com/ja-jp/library/x98tx3cf.aspx

↑のリンク先をよーく読んで
とりあえず_CrtSetDbgFlag()でも入れとけ
0180デフォルトの名無しさん2010/01/14(木) 20:20:17
>>177
御託並べてないでさっさとソース晒せよ
0181デフォルトの名無しさん2010/01/14(木) 21:18:56
>>170
>>14のコードをC++風に書くとこうなる。
このコードはメモリーリークも多重deleteもメモリ不足も例外も解決する。

template<class T>
class array
{
private:
T* buff;
array(const array&);
public:
explicit array(T* b):buff(b){}
virtual ~array(){delete[] buff;}
T& operator[](int index){return buff[index];}
const T& operator[](int index)const{return buff[index]:}
};

class C1
{
private:
array<int> a;
array<int> b;
array<C2> c;
public:
C1():a(new int[5]),b(new int[5]),c(new C2[5]){};
//各種メソッド
int xxx() ....;
};

0182デフォルトの名無しさん2010/01/14(木) 21:29:32
>>181
糞コードｗ
0183デフォルトの名無しさん2010/01/14(木) 21:41:03
ｑ
0184デフォルトの名無しさん2010/01/14(木) 22:04:05
>>181
何でvectorつかわねーんだ
0185デフォルトの名無しさん2010/01/14(木) 22:09:04
STL使わずに書いてみた。
>>184 STL版のサンプルよろしく
0186デフォルトの名無しさん2010/01/14(木) 22:10:40
>>181
メモリリークする。
多重deleteが防げてない。
例外も防げてない。
メモリ不足？
0187デフォルトの名無しさん2010/01/14(木) 22:13:22
あーあ可哀想に
C++BuilderならCodeGuardで一発なんだがな
どうせDebug版にもバグあるよそれ
それがRelease版で顕在化しただけ
0188デフォルトの名無しさん2010/01/14(木) 22:26:21
>>185
STL使わない意味ってなんかあんの？
0189デフォルトの名無しさん2010/01/14(木) 22:35:12
>>185
>>72
0190デフォルトの名無しさん2010/01/14(木) 23:00:21
Cはよい言語だ。アセンブラよりずっと簡単に書けるのに、アセンブラよりそれほど遅くない。
C++ with STLも悪くない。Cよりずっと簡単に書けるのに、Cよりそれほど遅くない。
だいぶコードサイズが大きくなるけどな。
だが、C++ without STLは最悪だ。そんなものを使うくらいなら、別の言語を使ったほうがマシだ。
0191デフォルトの名無しさん2010/01/14(木) 23:14:11
それ読む限り
C++ With STLが一番じゃん。
昔みたいにCPUもメモリも貧弱だったならともかく
CPU高速メモリあまりすぎの現状速さなんてたいして問題にならん。
0192デフォルトの名無しさん2010/01/14(木) 23:19:07
世の中メモリもディスクも無限にあるマシンばかりじゃないのだよ。
DSやPSPでSTLバリバリのコード書いたらすぐにメモリはパンクしてしまう。
0193デフォルトの名無しさん2010/01/14(木) 23:20:40
>>191
組み込み環境の事も忘れないであげてください。
0194デフォルトの名無しさん2010/01/14(木) 23:29:43
>>190
同意
0195デフォルトの名無しさん2010/01/15(金) 02:24:54
何？Embedded C++に喧嘩売ってるの？
0196デフォルトの名無しさん2010/01/15(金) 03:48:10
>>180
0197デフォルトの名無しさん2010/01/15(金) 05:31:17
取り敢えず
>>1の返答待ちと言う事で.
WindowsのVCコンパイラが生成した正当なプログラムが
ライブラリの未発見のバグで突然オチることがあるという
のが本当なら結構なニュースバリューがあるし...>>1は
発見者として大感謝されるかも...
0198デフォルトの名無しさん2010/01/15(金) 08:39:58
ちょっと視点を変えようか。
プロジェクトの設定による違いって事は無いかな？
0199デフォルトの名無しさん2010/01/15(金) 17:23:58
バッファオーバーランに設定も何もないと思うけど
0200デフォルトの名無しさん2010/01/15(金) 23:19:37
>>1がバグという可能性は？
020112010/01/15(金) 23:23:02
>>174, >>197
私は、Windowsにバグがあると言った覚えはありません。
落ちる部分のコードを何度見直しても合ってるのに
それでも異常終了するという症状に困っていると言いました。
実際は、クラスC1を使うプログラムの、クラスC1を使う
部分と全く別のコードが原因でした。
WindowsあるいはVCのバグではありません。
0202デフォルトの名無しさん2010/01/15(金) 23:32:17
動的確保する用のポインタをクラスに持ってるのに
コピコンを書かない理由がわからない
0203デフォルトの名無しさん2010/01/15(金) 23:40:26
>コピコンを書かない理由
「コピーすることがないから」は立派な理由だろう。
0204デフォルトの名無しさん2010/01/16(土) 00:09:06
>>201
もう最適化やめちゃいなよ

#pragma optimize("", off)
0205デフォルトの名無しさん2010/01/16(土) 00:13:50
>>203
その場合、書かない（＝デフォルト）のではなく、privateかリンカエラーにするんじゃないか？
0206デフォルトの名無しさん2010/01/16(土) 00:33:06
>>203
privateなりにして作っておかないとコンパイラが勝手にpublicで作るよ。
そして誰かがそのオブジェクトのコピーをして死ぬほどめんどくさくなると。
operator=も同上。
0207デフォルトの名無しさん2010/01/16(土) 01:54:04
コンパイラにバグがある事はまずない(あっても大抵全て既知の問題)
もし問題が再現する最小のプログラムが書けたらコンパイラメーカが
修正してくれる可能性は大いにあるが、そうでなければ無視される
0208デフォルトの名無しさん2010/01/16(土) 09:28:21
>>97
> C/C++コンパイラでコンパイル時に警告が出ているコード
> は既にある程度バグを含んでいるとすら言える。

そこまで言い出すとオープンソースなんかほぼ全滅だろ。
0209デフォルトの名無しさん2010/01/16(土) 10:25:02
オプソはシステム抽象化、標準化が行き着くところ迄行っている
UNIX環境の最大の強み。非純正開発環境でmakeして当然出てくる
ワーニングを無視しても殆どが遜色無く動くからオプソが成立
しており膨大な数のソフト資産が形成されてる。
0210デフォルトの名無しさん2010/01/16(土) 10:54:51
>208
まともなプロジェクトならウォーニングはほとんど出ないよ。
オープンソースの場合は、「動けばいい」じゃないから。
0211デフォルトの名無しさん2010/01/16(土) 11:44:59
boostはまともなプロジェクトじゃないんですかそうですか
0212デフォルトの名無しさん2010/01/16(土) 12:20:20
>>211
boostは完全C++準拠
boostで警告が出るならコンパイラの問題
0213デフォルトの名無しさん2010/01/16(土) 13:10:49
>>212
お前はGCCが糞だと言うのか。
だったら何を使えと言うのか？
0214デフォルトの名無しさん2010/01/16(土) 14:36:29
>>213
http://www.boost.org/development/tests/trunk/developer/summary.html

まあこれでも見て考えや
0215102010/01/16(土) 15:02:23
>>212
boostはコンパイラのベンダ拡張使いまくりですけど。
それで、VCもICCも警告でまくりですけど。
0216デフォルトの名無しさん2010/01/16(土) 20:46:35
201の発言をみて怖くなった。
この人は原因を把握しているのだろうか？
「落ちなくなったから正常に違いない」なんだろうか？
今までは「潜在的なバグがあるが偶然デバッグ版で動いていたがリリース版では動かなかった」で、
今は「潜在的なバグがあるが偶然デバッグ版でもリリース版でも落ちない」ではないだろうか？

最後に聞かせて欲しい。
不具合の原因はなんだったの？
初期化漏れ？ コードの誤り？
「全く関係ないところを直したら落ちなくなりました」は原因じゃないですよ。
0217デフォルトの名無しさん2010/01/16(土) 20:50:07
debug版だと勝手に初期化されてたまたま動くことがあるね
release版で死ぬなら初期化漏れかあるいはメモリ破壊だろ
0218デフォルトの名無しさん2010/01/17(日) 12:53:27
ライブラリ作成が仕事でも自分の作ったライブラリをテストランするプログラムぐらい書くよな？
0219デフォルトの名無しさん2010/01/17(日) 13:09:14
いくらテストランしたところでメモリ壊されたら対処のしようがないよね
0220デフォルトの名無しさん2010/01/17(日) 13:54:40
Ｓさんのプライドを守ってあげるような言い方で協力を要請すべきだったな
プログラム云々より人間関係の信頼構築に失敗している
0221デフォルトの名無しさん2010/01/17(日) 14:37:23
プライド？ヘボグラマの癖にプライドも糞もないわい
0222デフォルトの名無しさん2010/01/17(日) 15:10:52
プライドなんか関係ない。認めざるを得ない証拠を突き付ければOK
0223デフォルトの名無しさん2010/01/17(日) 15:22:40
ボンクラの>>1にそんなことができると思って(ry

そもそもSの書いた部分に原因があるとも、直ったのかどうかすら分からない。
しかも>>1はSに責任を擦り付けるためだけの情報しか書いていない。
0224デフォルトの名無しさん2010/01/17(日) 16:36:13
Sのコード直したらたまたま直ったってだけで>>1のコードはまだ白じゃないだろ
0225デフォルトの名無しさん2010/01/17(日) 16:46:20
何ヶ月も同じところで躓いたまま進まないことってあるのか
0226デフォルトの名無しさん2010/01/17(日) 16:52:11
少なくともnew/deleteではありえない。その前にクビになる。
0227デフォルトの名無しさん2010/01/17(日) 21:41:03
>>225
そんだけボンクラなんだろ。両者とも。
そんなことが許されてるからボンクラなままだとも言える。
0228デフォルトの名無しさん2010/01/19(火) 00:30:23
以前あるプロジェクトで>>14みたいなコード書いて関数に値渡してたバカがいたよ。
そいつも一週間は格闘してたな。しかも露見した時の言い訳がひどかった。
参照渡しにするのを忘れたとか何とか。
コピー代入禁止にしとけばすぐに発見できることなのにな。
まあ>>1が同じ事してないことを祈るよ
0229デフォルトの名無しさん2010/01/19(火) 12:46:20
ボンクラ再生産
ボンクラ(ボンクラ&)
ボンクラ operator = (ボンクラ&)
023012010/01/19(火) 19:58:17
>>14のコードが糞だという意見がとても多いですね。
どう糞なのでしょう。
大半の方はSTLやスマートポインタを使っていない
から糞だといっているようです。
>>228の方は「>>14みたいなコード」(ダメなコードの意味だと思いますが)の
何がダメなんでしょうか。
0231デフォルトの名無しさん2010/01/19(火) 20:52:13
コピーを考慮しないからじゃないですかね。
0232デフォルトの名無しさん2010/01/19(火) 21:19:04
>>230
何がダメって理由書いたつもりなんだが…

void Test( C1 c ){}

int _tmain(int argc, _TCHAR* argv[])
{
C1 c;
c.init();
Test( c );
return 0;
}

露骨にコピーや代入やってもいいけど、まあ一応>>228の例
C2に空クラスでも実装すりゃコンパイルできるだろ
それと各種メソッドとかいうC1::xxx()をメンバ（a、b、c）にアクセスするように実装して
Test()とreturnの間でC1::xxx()を呼び出してみな
VCならそっちの方がわかりやすいメッセージが出るだろ
何が起こるか予想できるよな？
0233デフォルトの名無しさん2010/01/19(火) 22:31:54
>>230
初期化子を使ってないとかnew失敗でNULLが返ってくる前提とか
初期化メゾットをコンストラクタで呼ばないとか
さんざん言われた設計だけでなく実装段階でもクソだ
0234デフォルトの名無しさん2010/01/19(火) 22:41:03
>>1がソース晒さない限り、VC++のバグということで..
また　都　市　伝　説　が一つ増えたというわけだ。
0235デフォルトの名無しさん2010/01/19(火) 23:13:10
クソみたいなコードを量産する前に、
せめてEffective C++ぐらい読んどけ
0236デフォルトの名無しさん2010/01/19(火) 23:53:54
>>1
＾＾
0237デフォルトの名無しさん2010/01/20(水) 21:50:18
>>232

デバッグ版で動いてリリース版で動かない例にはなってないな
0238デフォルトの名無しさん2010/01/20(水) 22:14:49
ttp://msdn.microsoft.com/ja-jp/library/dykf6bx9(VS.80).aspx
0239デフォルトの名無しさん2010/01/21(木) 00:24:49
>>230
> 大半の方はSTLやスマートポインタを使っていないから糞だといっているようです。
アホすぎる。何が悪いと言われているのに理解できないお前のノーミソなど
味噌糞一緒くたにしてしまえ。そのノークソが一番糞だ。

たまにいるよな、これぐらい酷いアホ。
自分が理解できていないことを理解できないアホは救いようがない。
0240デフォルトの名無しさん2010/01/21(木) 01:03:32
>自分が理解できていないことを理解できないアホは救いようがない。

世の中の殆どの人間がそうなんだが
0241デフォルトの名無しさん2010/01/21(木) 01:06:18
>>1
なんか騒動になってるぞ。株式市場とかにも影響してくるから
釈明の意味でソース晒したほうがいいんじゃね？（情報漏れは
無いようにな）
0242デフォルトの名無しさん2010/01/21(木) 01:38:50
>>241
おまえがその騒動とやらのソースをさらせよ
0243デフォルトの名無しさん2010/01/21(木) 02:30:58
この手のスレはチンパンジーアイちゃんが出てから１０程度
でオチるのが常。
しかしこの伸びは異常。やっぱし何かあるからだろな。
0244デフォルトの名無しさん2010/01/22(金) 10:50:24
なんかの手違いで.hと{.obj|.dll|.lib}の不整合が起きてたと予想。
.objや.lib内ではnon-virtualなメソッドが最新の.hではvirtualになってたみたいな。
プリコンパイルヘッダの仕組みを理解せずに使ってたとか、
同じ.hに依存する2つのライブラリのビルドの整合がとれてないとか。
0245デフォルトの名無しさん2010/01/23(土) 01:51:42
れすみないでかくけどはいれつのきょうかいこえてかきこんでるときに
にたようなしょうじょうおこるよね
でばっぐだとあいだにまーじんとってくれるからもんだいおきなかったりするし
printfいれるとうわがきされるいちがかわるからばぐはっしょうするし
はいれつをじさくａｒｒａｙにおきかえてoperator[]じっそうして
きょうかいちぇっくやったらだいたいつかまるきがする
0246デフォルトの名無しさん2010/01/23(土) 01:56:41
>>1は逃亡したつもりなのかもしれないが...
0247デフォルトの名無しさん2010/01/24(日) 14:54:08
>>233
>設計だけでなく実装段階でもクソ

意味不明
0248デフォルトの名無しさん2010/01/24(日) 15:32:17
「リゾット」あるいは「メゾネット」なら知ってるが、「メゾット」は俺も解らない。
0249デフォルトの名無しさん2010/01/24(日) 18:15:55
おまえらドＳだな
0250デフォルトの名無しさん2010/01/24(日) 20:02:24
チンパンジーが何で関係あるの？
0251デフォルトの名無しさん2010/01/24(日) 20:20:36
チンパンジー
0252デフォルトの名無しさん2010/01/29(金) 12:10:34
>>1ですが
やっぱりコンパイラのバグだと思います。
Oilly Debugとかなんとかいうツールで生成コードを
見せてもらった至る所で違ってました
0253デフォルトの名無しさん2010/01/29(金) 13:05:48
それならMSに報告しておいてくれ
次のバージョンでは直してもらえるかもしれない
0254デフォルトの名無しさん2010/01/29(金) 14:07:49
次はムリ。次の次だな。
0255デフォルトの名無しさん2010/01/29(金) 14:14:24
>>1
VCなどのコンパイラに感染するウィルスがあるって噂
を聞いた事ががあるんで、ウィルスチェック。
そんじょそこらのウィルスチェッカーじゃ弱くて
OSをインストールした直後で一切ネットに繋げていない
状態で、インストール元CD−ROMのパッケージを全部
こじあけてHDに展開して、すべてのファイルについて
MD5をとっておく。
（MD5データのみUSBメモリに保存しておく）
開発マシンの同名ファイルのMD5を取って比較する。
出来ればMD5だけじゃなく他のその手のチェックサム
を合わせて取って比較チェックしたほうがいいかも
0256デフォルトの名無しさん2010/01/29(金) 16:54:32
このバグ既に報告済みだから
0257デフォルトの名無しさん2010/01/29(金) 20:59:32
その生成コードとやらの掲載よろしく
0258デフォルトの名無しさん2010/01/31(日) 22:55:15
>>1
とりあえず収拾してくれ
0259デフォルトの名無しさん2010/02/02(火) 07:18:39
この手のバグは配列(ポインタ)のインデックス不正で起こることがとても多い。
0260デフォルトの名無しさん2010/02/02(火) 08:58:43
>>259
本当はそうかもしれないけど、他人のコードがおかしいとケンカ売っている以上
もう、「ごめん、僕のミスだった」じゃ済まない。
だから、コンパイラのエラーにするしかなかったんだと思う。
特定のコンパイラだと運よく動くなんてことはままあるのだけど。
0261デフォルトの名無しさん2010/02/02(火) 10:30:42
再現コード込みで文句言えない時点で騒いでる方のミス。
と俺は思ってる。

本当に問題あるのなら食わせたソースと吐いたアセンブラ突き合わせて説明できるはず。
0262デフォルトの名無しさん2010/02/02(火) 20:58:21
アセンブラは吐かないだろ…
0263デフォルトの名無しさん2010/02/02(火) 23:15:06
コンパイラのバグだったらアセンブラ吐かせて説明できるはずってことでしょ
026412010/02/03(水) 00:08:18
随分日にちがたってしまいました。
アクセス規制にかかっててずっと書き込めませんでした。

ちなみに、>>252は私ではありません。

あと、皆さんのコメント見ててちょっと思ったんですが、
クラスの値渡しってまずいんですか？

そういうプログラムを普段書かないから分からないんですが、
0265デフォルトの名無しさん2010/02/03(水) 00:15:43
>>264
値渡しは出来る（と思う）が、当然だがクラスへの変更操作は
呼び出し元には反映されないので、同一オブジェクトへの２つ
のバージョンが出来てしまうことになり多くの場合に問題が発生する
ので、通常はポインタ渡しにする。
VCの場合、プリコンパイルドヘッダ周りが結構悪さをして
予期せぬ不具合を作る場合がある。ビルドする際には
面倒でも中間ファイルを削除する習慣を付けたいもの
（その代わりビルドの時間が多少犠牲になる）
0266デフォルトの名無しさん2010/02/03(水) 00:46:23
またVCバグ説ｗ
0267デフォルトの名無しさん2010/02/03(水) 00:49:19
>>264
コピー＆代入がおかしいって既に数人が指摘してんじゃん
0268デフォルトの名無しさん2010/02/03(水) 03:17:05
>>264
コピー、代入がしっかり設計されているクラスならば値渡しは問題にならない。
ただ効率の問題が別にあるがそれ自体はバグではない。
おまえの作った>>14のクラスをコピーや代入するとバグる。値渡しはその一例にすぎない。
二重deleteでヒープを破壊するからな。
もしお前がコピーや代入をたまたましていなくて問題がなかったとしても
>>14のクラスを他人が使う可能性があるとしたらやばいな
まあ他にも複合的な問題はありそうだけどな
0269デフォルトの名無しさん2010/02/03(水) 04:14:40
なんでコピーコンストラクタや代入演算子を自前で書かないのかわからない
クラス内でnew/de;eteするクラスは自前で書くのが当たり前だろ
0270デフォルトの名無しさん2010/02/03(水) 04:59:39
>クラスの値渡しってまずいんですか？
こういうレベルの人に C++ コードを書かせる時点で間違い
0271デフォルトの名無しさん2010/02/03(水) 05:04:52
入門書レベルの質問じゃね？
0272デフォルトの名無しさん2010/02/03(水) 05:25:40
あくまでも自分は悪くなく、コンパイラのバグだと言い張る奴は
いつまで経ってもバグが取れない
0273デフォルトの名無しさん2010/02/03(水) 07:08:45
永久にとれるはずがない。
そいつが開発をしていること自体がプロジェクトのバグだからな。
0274デフォルトの名無しさん2010/02/03(水) 13:51:32
「よくわかんないけど動いたのでこれでいいです」
これで許される環境がウラヤマシスギルw
■ このスレッドは過去ログ倉庫に格納されています