4

スタック破壊検出エラーをスローするプログラムを作成しました。99% の確率で動作しますが、特定のファイルではエラーがスローされます。valgrind を使用してエラーを特定しようとしましたが、ログ ファイルを理解するのに苦労しています。だからここにあります：

==3797== Memcheck, a memory error detector
==3797== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3797== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==3797== Command: ./pargrep de nuevo.txt
==3797== Parent PID: 2367
==3797== 
==3797== 
==3797== HEAP SUMMARY:
==3797==     in use at exit: 33,339 bytes in 5 blocks
==3797==   total heap usage: 12 allocs, 7 frees, 35,025 bytes allocated
==3797== 
==3797== 4 bytes in 1 blocks are still reachable in loss record 1 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x8048FDB: maestro (padre.c:39)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 55 bytes in 1 blocks are still reachable in loss record 2 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40B878B: __libc_message (libc_fatal.c:138)
==3797==    by 0x413D09F: __fortify_fail (fortify_fail.c:32)
==3797==    by 0x413D049: __stack_chk_fail (stack_chk_fail.c:29)
==3797==    by 0x8049665: contar_palabra (funcion.c:51)
==3797==    by 0x80494C5: hilos_hijos (hilos.c:90)
==3797==    by 0x4041E98: start_thread (pthread_create.c:304)
==3797==    by 0x41279ED: clone (clone.S:130)
==3797== 
==3797== 136 bytes in 1 blocks are possibly lost in loss record 3 of 5
==3797==    at 0x4025315: calloc (vg_replace_malloc.c:467)
==3797==    by 0x4010CD7: allocate_dtv (dl-tls.c:300)
==3797==    by 0x401146B: _dl_allocate_tls (dl-tls.c:464)
==3797==    by 0x40425C6: pthread_create@@GLIBC_2.1 (allocatestack.c:570)
==3797==    by 0x80490E1: maestro (padre.c:84)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 352 bytes in 1 blocks are still reachable in loss record 4 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40B3537: __fopen_internal (iofopen.c:76)
==3797==    by 0x40B360B: fopen@@GLIBC_2.1 (iofopen.c:107)
==3797==    by 0x804907D: maestro (padre.c:66)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 32,792 bytes in 1 blocks are still reachable in loss record 5 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40EBA18: __alloc_dir (opendir.c:186)
==3797==    by 0x40EBB49: opendir (opendir.c:141)
==3797==    by 0x8049013: maestro (padre.c:53)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== LEAK SUMMARY:
==3797==    definitely lost: 0 bytes in 0 blocks
==3797==    indirectly lost: 0 bytes in 0 blocks
==3797==      possibly lost: 136 bytes in 1 blocks
==3797==    still reachable: 33,203 bytes in 4 blocks
==3797==         suppressed: 0 bytes in 0 blocks
==3797== 
==3797== For counts of detected and suppressed errors, rerun with: -v
==3797== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 8)

私は本当にエラーが何であるかを理解していません.私は助けに感謝します.

4

4 に答える 4

6

スタック破壊エラーとヒープ メモリ エラーを区別する必要があります。

Valgrind は、一部のメモリが解放されておらず、一部が失われている可能性があることを示しています。しかし、それはあなたの本当の問題、つまりスタック破壊とは何の関係もないかもしれません。

スタックとは、ローカル変数 (多くの場合 char 配列)、割り当てられていないその他の配列などを意味します。

ヒープ: malloc、calloc、realloc などで割り当てられたもの。

したがって、スタックが破壊された場合は、配列の末尾を上書きする可能性が高くなります。最初に strcpy、memcpy、および配列アクセスを確認します (割り当てられていないメモリに書き込む場所)。

于 2012-06-22T17:51:05.303 に答える
2

Valgrind 3.7.0 では、スタックとグローバル オーバーランを検出する実験的なツール exp-sgcheck を試すことができます。前述のとおり、これは実験的なツールであるため、memcheck やその他の非実験的な Valgrind ツールほど高品質ではない可能性があります。(たとえば、偽陽性および/または偽陰性を与える可能性があります)。ただし、exp-sgcheck は、厄介な配列オーバーランのバグを見つけるのに役立ちました。

于 2012-06-25T22:22:57.750 に答える
0

これらのメッセージで、Valgrindはメモリが割り当てられたことを通知します（そしてmallocの呼び出しがどのように発生したかをスタックトレースで示します）が、これらの割り当てからのメモリは解放されていません。

詳細については、 http： //valgrind.org/docs/manual/mc-manual.html#mc-manual.leaksをご覧ください。

于 2012-06-22T17:41:59.997 に答える
0

valgrind は配列オーバーランを検出しません。これは、観察されたスタック破壊の原因である可能性があります。

于 2012-06-22T17:51:21.310 に答える