問題タブ [malloc]

長さが262144要素でなければならない非常に大きな配列があります（将来的にはさらに大きくなる可能性があります）。次のようにスタックに配列を割り当てようとしました：

ただし、特定のポイントを超えて要素を追加しようとすると、それらにアクセスしようとすると値が異なるようです。これは、より多くのメモリを持つヒープとは対照的に、スタックには有限の量のメモリしかないためであると理解しています。

私はあまり運がなくても次のことを試しました（コンパイルしません）：

そして、 を使用することを検討しmallocましたが、これを行う C++ のような方法があるかどうか疑問に思っていました...

私はただ一緒に行くべきmallocですか？

nsapi は、要求が終了したときに解放されるプールからメモリを取得する MALLOC マクロを提供しますが、要求がないときに初期化関数でこの malloc 関数を呼び出すとどうなるかはわかりません。この malloc (または pblock_created) メモリは永続的であると推定できますか? nsapi のドキュメントにはそれについて何も書かれていません。

実行時にポインタと参照をどのように区別しますか？たとえば、データ型のポインターがポインターであるかどうかを知らずに解放したい場合、どうすればよいでしょうか。変数がスタックに割り当てられているのか、malloc（）を介して割り当てられているのかを判断する方法はありますか？

それとも、それを実行してerrnoやポインタをチェックして成功したかどうかを確認する必要がありますか？

正確なコピーアロケータを作成できるように、自分でmalloc/freeを作成したいと思います。

どんな教祖にもヒントや提案がありますか？

今のところいくつか質問があります：

1. システムコールを呼び出す必要がないように、メモリの大きなチャンクをmallocして、そこから分散する必要がありますか？
2. コレクターのコピーは通常どのように行われますか？この部分を効率的に行うには少し複雑だと思います。私の素朴な実装では、残りのオブジェクトのサイズのブロックをmallocするだけで、2倍のスペースが必要になります。

このコードの何が問題なのか誰にもわかりますか?

大きなビットマップ画像 (3366x600) を描画しようとしているので、SIZE_BG は 6MB です。イメージがスタックからオーバーフローするのを防ぐために、malloc を使用します。glDrawPixels() の呼び出しでアクセス違反エラーが発生します。glDrawPixels を呼び出す前に最初の数バイトをチェックしたため、bgPtr は正しいデータを指しているようで、正しいデータです。

さまざまな長さの入力配列でさまざまなアルゴリズムをベンチマークするC++プログラムがあります。それは多かれ少なかれこのように見えます：

（2）のヒープ管理全体を（1）の状態にリセットすることは可能ですか？プログラム中に割り当てられたヒープに割り当てられたすべてのメモリは、（3）で解放されることが保証されています。

Linuxでg++4.3を使用しています。

編集：C /C++には実際のガベージコレクションがないことを理解しています。（2）の空きリストにある隣接する空のメモリチャンクにメモリ割り当てを強制的に結合させたい。

次の C コードを検討してください。

以前に malloc されたものではない c を解放しようとしているため、これは segfault になります。私の質問は、malloc したばかりのブロックはどうなりますか? 明らかに c はもうそれを指していないので、使用できませんが、まだ「フリー」リストの一部と見なされていますか、それとも明示的なメモリ リークですか?

私は C コードの多くの行をクリーンアップ ラベル/条件付きメモリ割り当ての失敗に費やしました (allocファミリーが を返すことで示されますNULL)。これは、メモリ障害が発生した場合に適切なエラー ステータスにフラグを立て、呼び出し元が「適切なメモリ クリーンアップ」を実行して再試行できるようにするための優れた方法であると教えられました。私は今、この哲学についていくつかの疑問を抱いており、それを解決したいと思っています.

I guess it's possible that a caller could deallocate excessive buffer space or strip relational objects of their data, but I find the caller rarely has the capability (or is at the appropriate level of abstraction) to do so. Also, early-returning from the called function without side effects is often non-trivial.

I also just discovered the Linux OOM killer, which seems to make these efforts totally pointless on my primary development platform.

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer.

I figure there are probably other platforms out there that follow the same principle. Is there something pragmatic that makes checking for OOM conditions worthwhile?

ball という構造体、いくつかのボール、ボールの配列、および配列に新しいボールを追加する関数があります。

構造体:

(非動作機能):

および main 内の関数呼び出し:

関数の呼び出しが失敗し、次のエラー メッセージが表示されます。

何か助けはありますか？

それは役に立ちました。これでコンパイルできますが、実行時にセグメンテーション違反エラーが発生します。興味がある場合は、完全なコードを次に示します。