0

私は非常に複雑なソフトウェアを書いています (今までに 10 年以上)。

以下からソースをチェックアウトすることをお勧めします: http://savannah.nongnu.org/svn/?group=cybop

INSTALL ファイルの指示に従ってコンパイルおよび実行します。

このコマンド ラインを使用して memcheck を実行しました: christian@deneb:/home/project/cybop/examples$ valgrind --tool=memcheck --log-file=memcheck.log --leak-check=full --track-origins =はい ../src/controller/cyboi exit/run.cybol

memcheck の出力は次のとおりです。

==28641== Memcheck, a memory error detector
==28641== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==28641== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==28641== Command: ../src/controller/cyboi exit/run.cybol
==28641== Parent PID: 22974
==28641== 
==28641== 
==28641== HEAP SUMMARY:
==28641==     in use at exit: 5,174 bytes in 407 blocks
==28641==   total heap usage: 636 allocs, 229 frees, 45,749 bytes allocated
==28641== 
==28641== 442 (72 direct, 370 indirect) bytes in 1 blocks are definitely lost in loss record 406 of 407
==28641==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==28641==    by 0x401EC0: allocate_array (array_allocator.c:116)
==28641==    by 0x40719C: allocate_part (part_allocator.c:50)
==28641==    by 0x42EE3E: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:262)
==28641==    by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
==28641==    by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
==28641==    by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
==28641==    by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
==28641==    by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
==28641==    by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
==28641==    by 0x42F4CB: deserialise_cybol (cybol_deserialiser.c:196)
==28641==    by 0x42FD48: deserialise (deserialiser.c:229)
==28641== 
==28641== 4,732 (72 direct, 4,660 indirect) bytes in 1 blocks are definitely lost in loss record 407 of 407
==28641==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==28641==    by 0x401EC0: allocate_array (array_allocator.c:116)
==28641==    by 0x40719C: allocate_part (part_allocator.c:50)
==28641==    by 0x41F6EA: deserialise_xml_element (element_xml_deserialiser.c:61)
==28641==    by 0x41FA65: select_xml_element_content (element_content_xml_selector.c:144)
==28641==    by 0x41FAF3: deserialise_xml_element_content (element_content_xml_deserialiser.c:73)
==28641==    by 0x41FBA9: deserialise_xml (xml_deserialiser.c:66)
==28641==    by 0x42F3E1: deserialise_cybol (cybol_deserialiser.c:178)
==28641==    by 0x42FD48: deserialise (deserialiser.c:229)
==28641==    by 0x430088: receive_file (file_receiver.c:106)
==28641==    by 0x433D2F: initialise (initialiser.c:88)
==28641==    by 0x4344C3: manage (manager.c:320)
==28641== 
==28641== LEAK SUMMARY:
==28641==    definitely lost: 144 bytes in 2 blocks
==28641==    indirectly lost: 5,030 bytes in 405 blocks
==28641==      possibly lost: 0 bytes in 0 blocks
==28641==    still reachable: 0 bytes in 0 blocks
==28641==         suppressed: 0 bytes in 0 blocks
==28641== 
==28641== For counts of detected and suppressed errors, rerun with: -v
==28641== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)

「確実に失われた」というエラーは、すべてが適切に解放されたわけではないと主張しています。Sisyphus の仕事をして、私のすべてのソース コードを検索するように頼んでいるわけではありません。基本的に、すべての関数が依存する「malloc」は 1 つだけです。データ構造 (トップダウン) は次のとおりです。パーツ - アイテム - 配列 - 値。つまり、パーツは 9 つのアイテムを参照し、アイテムは 3 つの配列を参照します。

自作のビルトイン ガベージ コレクションによると、すべて問題ありませんでした。見てみたい人もいるのではないでしょうか？どんなヒントでも大歓迎です。次のファイル「array_allocator.c」のソース コード スニペット:

void allocate_array(void* p0, void* p1, void* p2) {

    if (p0 != *NULL_POINTER_STATE_CYBOI_MODEL) {

        void** a = (void**) p0;

        // The memory area.
        int ma = *NUMBER_0_INTEGER_STATE_CYBOI_MODEL;

        // Determine type (type) size.
        determine_size((void*) &ma, p2);

        // Calculate memory area.
        calculate_integer_multiply((void*) &ma, p1);

        // The temporary size_t variable.
        size_t tma = ma;

        // CAUTION! In order to always get a correct memory address returned
        // that may be used to store data, a potential zero size is changed
        // to a minimum size of one here.
        if (tma == *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {

            tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;

        } else if (tma < *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {

fwprintf(stdout, L"ERROR: Could not allocate array. The memory area to be allocated is negative: %i\n", *a);

            tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;
        }

        *a = malloc(tma);

        // Initialise array elements with null pointer.
        //
        // CAUTION! Initialising with zero values is essential, since
        // cyboi frequently tests variables for null pointer values.
        memset(*a, *NUMBER_0_INTEGER_STATE_CYBOI_MODEL, tma);

    } else {

        log_message_terminated((void*) ERROR_LEVEL_LOG_CYBOI_MODEL, (void*) L"Could not allocate array. The array is null.");
    }
}
4

1 に答える 1

0

ここでこの質問をするのは間違いでした。なぜなら、それは一般的なプログラミングには触れておらず、むしろプロジェクト固有の問題に触れているからです。

やっと見つけたバグ。論理エラーでした。

(自己定義された)「パーツ」構造体の割り当てを解除する場合、「モデル」の「タイプ」が必要です。エラーは、実際の「モデル」の前にパーツの「タイプ」の割り当てを解除したため、「モデル」の割り当て解除が正しく機能せず、メモリ リークが発生したことです。

解決しました。stackoverflow には属しません。閉めるだけ。

于 2013-04-05T18:21:03.160 に答える