問題タブ [alloca]

メモリ リークが遅いと思われるレガシー C++ アプリケーションを保守しています。現在の構成で例外がスローされないようにすることで、メモリリークを「修正」することができました。また、多くの例外が発生するように構成することで、リークをトリガーしてスケーリングすることもできます。

割り当てられるすべてのメモリは、malloc() ではなく alloca() を使用して行われます。これについて私が説明したのは、alloca() が Java ガベージ コレクターのように機能し、コンテキストを終了するときにメモリを自動的に解放するためだということです。

リークがスローされる例外に明確にバインドされているため、例外がスローされたときに alloca() がメモリを解放できないという理論があります。

これはまったくもっともらしいですか？true の場合は alloca() の重大な欠陥だと思いますが、alloca() をグーグルで検索すると、一般的に問題になるようです。

専門家の洞察をいただければ幸いです。

引数として割り当てに使用する関数が渡される関数を作成しようとしています。タイプ の有効なアロケータを受け入れる必要がありますvoid *(*)(size_t)。ただしalloca、アロケーターとして使用しようとすると、奇妙な動作が発生します。関数への関数ポインターを構築すると、正常にallocaコンパイルされますが、リンカー エラーが発生します。

結果は

これは alloca がインライン化されていることと関係がありますか? しかし、インライン化は、関数がアドレスを持つ必要がない場合の最適化としてのみ行われるわけではありません。実際、GCC を使用すると、上記のコードで期待どおりに動作する独自のバージョンを作成することもできます。

標準バージョンが同じように動作しない理由はありますか?

alloca( GNU) C では、スタック上の変数データを操作するためのメカニズムが少なくとも 2 つ提供されていますstrdupa。

問題allocaは、メモリに連続領域を割り当てないように見えることです-プログラム

版画

これは、後続の割り当てが 4 倍の単語を返す可能性があることを示唆しています (ただし、実装固有であると予想されます。このコードは、ARM ベースの電話でのみ試しました)。

事前にわかっているサイズでそれらを割り当てるのではなく、スタックに単一の値をプッシュする「認可された」方法はありますか?

私は次のようなことを意味します：

x86 と ARM の両方で機能するソリューションを探しています。(これらのプラットフォームの ABI を研究し、スタック ポインターを明示的に操作するアセンブリに展開されるマクロを作成することはオプションだと思いますが、自分でこれを調べる時間はありません)