アクセス違反の書き込み位置例外のブラインド解決法

記事目次

• • toc
  • 質問の説明
  • 解決方法

質問の説明

最近、CVの問題を解決するためにOpenCVを使用しています。さて、VS2017、お前ら笑うなよ、俺もLinux使いたいんだよ、しょうがない、VSはひよっこには本当にいい、環境に合わせるのは苦痛だが。要はソースコードを見ないといけないこともあるわけで、Linuxでのソースコードは見たことがないので、あえていじらないことにして、まずは身近なものからやっていこうと思います。
まず、種明かしのような再帰を書く（もちろん、再帰は実行中のスタックを占有することなので、スタック領域を20MBに変更、これで理屈は十分だ。十分なようだ、スタックオーバーフローの爆発に最後の再帰は、ない铺不绕木の後に20MBに変更しました）。

上記の2つの矢印は、私のデバッグ、画像1400 * 1000、4チャンネルフロート（演算の便宜のために、言うまでもなく）、その後私は、コンパイラの最適化後の速度が悪くはない、OK、何の問題も実行するX64用リリースを選択しました。なぜそれを解放することを選択しますか？私はまた忘れてしまった。しかし、私は実行するデバッグを選択した後。(驚きの母fk)

バジンガ! 座標【34, 688】アクセス違反の書き込み場所？なんだこれ？ということで、上の画像のようにブレークポイントを挿入して確認してみました。ブレークポイントに条件を書いて制御するのではなく、このような杖のifを使うのはどうでしょうか？速度が遅すぎるんです。私の小さな癇癪。結果です。

ヤァー! マ! バンド! ここでアノマリーを変えるんですか？at<>()だったのが、channel()になってる？確認しましたが、問題ないはずです。(私が新しすぎて見つけられないのかもしれませんが。) 再実行したら、今度は例外の座標が変わりました？[25,827] 位置が変わった？こんなに派手に？

ソリューション

スタックが暴走しているのでは？それはスタックオーバーフローとして報告する必要があります。でも、試しにスタックを40Mにしてみよう（今は怠け者だからしょうがない、再帰は単純で残酷だ）。Debugを突破できるかどうか。はい。

そこで質問ですが、なぜReleaseをチェックしても例外が報告されないのでしょうか？どなたかこの問題の解決策をお教えください。なぜスタックスペースを調整するとうまくいくのでしょうか？スタックオーバーフローは報告されないのですか？