0

私は次の問題を抱えています：

Windowsマシン（32ビット、3.1Gbメモリ、VC ++ 2008とmingwコンパイル済みコードの両方）で実行されるプログラムは、bad_alloc例外がスローされて失敗します（約1.2Gbを割り当てた後、900万倍のベクトルを割り当てようとすると例外がスローされます） 、つまり約75Mb）、まだ十分なRAMが利用可能です（少なくともタスクマネージャーによると）。

Linuxマシン（32ビット、4Gbメモリ、32ビット、2Gbメモリ）で実行される同じプログラムは、約1.6Gbのピークメモリ使用量で正常に実行されます。興味深いことに、4Gb linuxマシンでwineの下で実行されたmingwによって生成されたwin32コードも、Windowsの下で実行された場合とは異なる（後の）場所ではありますが、bad_allocで失敗します...

考えられる問題は何ですか？

  • ヒープの断片化？（どうすればわかりますか？これはどのように解決できますか？）
  • ヒープの破損？（エラーが報告されずにpageheap.exeが有効になっているコードを実行しました。境界チェックを使用してベクトルアクセスを実装しました。これもエラーはありません。コードには基本的にポインターがなく、std::vectorsとstd::listsのみが使用されます。Valgrindでプログラムを実行します（ memcheck）はメモリを消費しすぎて途中で終了しますが、エラーは見つかりません）
  • メモリ不足??? （十分なメモリがあるはずです）

さらに、Linuxバージョンが動作しているときに（そしてメモリの少ないマシンでも）Windowsバージョンが失敗する理由は何でしょうか？（/ LARGEADDRESSAWAREリンカーフラグは、効果がある場合はVC + 2008で使用されることにも注意してください）

どんなアイデアでも大歓迎です、私はこれで私の知恵の終わりにいます... :-(

4

4 に答える 4

5

システムに搭載されているRAMの量とは関係ありません。仮想アドレス空間が不足しています。32ビットのWindowsOSプロセスの場合、ユーザーモードの2GB（LARGEADDRESSAWAREの場合は3GB）とカーネルの2GBから4GBの仮想アドレス空間（使用しているRAMの量に関係なく）を取得します。newを使用してメモリを割り当てようとすると、OSは、メモリ割り当て要求を満たすのに十分な大きさの仮想メモリの連続ブロックを見つけようとします。仮想アドレス空間がひどく断片化されている場合、またはメモリの巨大なブロックを要求している場合は、bad_alloc例外のスローに失敗します。プロセスが使用している仮想メモリの量を確認してください。

于 2009-10-24T12:39:00.987 に答える
2

Windows XP x86 と既定の設定では、1.2 GB は、システム ライブラリ、コード、スタック、およびその他のものが共有された後に、ヒープ用に残されているすべてのアドレス空間に相当します。largeaddressaware では、プロセスに最大 3GB を与えるために、/3GB ブート フラグを指定してブートする必要があることに注意してください。/3GB フラグは多くの XP システムで不安定性を引き起こすため、デフォルトでは有効になっていません。

Windows x86 のサーバー バリアントは、3GB/1GB 分割を使用することと、PAE を使用して 4GB の RAM をすべて使用できるようにすることの両方によって、より多くのアドレス空間を提供します。

Linux x86 は、デフォルトで 3GB/1GB 分割を使用します。

64 ビット OS では、32 ビット プロセスであっても、より多くのアドレス空間が得られます。

于 2009-10-24T14:10:08.363 に答える
0

Debugモードでコンパイルしていますか？その場合、割り当てによって大量のデバッグデータが生成され、実際のメモリ不足で、発生したエラーが発生する可能性があります。Releaseそれで問題が解決するかどうか試してみてください。

私はこれをVCで経験しただけで、MinGWでは経験していませんが、どちらもチェックしていません。これでも問題を説明できる可能性があります。

于 2009-10-24T12:36:07.243 に答える