3

Splintは、C コードのメモリ リークをうまく追跡します。すべてmalloc()に一致する が必要free()です。しかし、BoehmGC で収集されたコードはGC_MALLOC()、一致しないを使用しGC_FREE()ます。これにより、Splint は、実際には存在しないメモリ リークに関する大量のメッセージに夢中になります。

Splint が誤ったメモリ リーク メッセージを表示しないように、そのようなコードの適切な注釈を知っている人はいますか?

特に、誰かがウィキペディアのBoehmGC の例に注釈を付けることができますか?

#include <assert.h>
#include <stdio.h>
#include <gc.h>

int main(void)
{
    int i;

    GC_INIT();
    for (i = 0; i < 10000000; ++i)
    {
        int **p = GC_MALLOC(sizeof(int *));
        int *q = GC_MALLOC_ATOMIC(sizeof(int));

        assert(*p == 0);
        *p = GC_REALLOC(q, 2 * sizeof(int));
        if (i % 100000 == 0)
            printf("Heap size = %zu\n", GC_get_heap_size());
    }

    return 0;
}
4

1 に答える 1

2

BoehmGC API 自体に注釈を付ける必要があると思います。そうすれば、例に必要な注釈 (存在する場合) が明らかになります。

まず、注釈のない関数によって返されるポインターは暗黙的@onlyに です。つまり、参照が失われる前に、関連するメモリを解放する必要があります。したがって、最初のステップは、アロケータに注釈を付けて、参照を返さないようにすること@onlyです。代わりに、マニュアルでは共有参照の使用を推奨しています。

Splint を使用してガベージ コレクション環境で使用するように設計されたプログラムをチェックする場合、1 つまたは複数の参照によって共有され、明示的に解放されないストレージが存在する可能性があります。shared アノテーションは、任意に共有できるが決して解放されないストレージを宣言します。

BoehmGC API を変更したくない場合は、適切に注釈を付けたラッパー関数を作成することで回避できます。さらに、ラッパー関数内の特定の転送エラーを無効にする必要があります ( @onlyBoehmGC API から暗黙的な参照を取得し、それを として返すため@shared)。

たとえば、これは、コードの特定のポイントで「ステートメントには効果がありません」というエラーを無効にする方法です。

/*@-noeffectuncon@*/
not_annotated_void_function();
/*@=noeffectuncon@*/

ラッパー関数は次のようになります。

/*@shared@*/ /*@null@*/ /*@out@*/ static void * MY_GC_MALLOC(size_t size) /*@*/{
    /*@-onlytrans@*/
    return( GC_MALLOC(size) );
    /*@=onlytrans@*/
}

次に、この例では、MY_GC_MALLOCではなくを使用しますGC_MALLOC。

于 2011-08-01T21:53:46.653 に答える