0

FreeBSD で Valgrind を使用しようとしていますが、いくつかの問題が発生しています。ここに出力があります

==4764== Memcheck, a memory error detector
==4764== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4764== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==4764== Command: driver -i
==4764== 
==4764== 
==4764== HEAP SUMMARY:
==4764==     in use at exit: 33,852 bytes in 4 blocks
==4764==   total heap usage: 12 allocs, 8 frees, 171,894 bytes allocated
==4764== 
==4764== LEAK SUMMARY:
==4764==    definitely lost: 0 bytes in 0 blocks
==4764==    indirectly lost: 0 bytes in 0 blocks
==4764==      possibly lost: 0 bytes in 0 blocks
==4764==    still reachable: 33,852 bytes in 4 blocks
==4764==         suppressed: 0 bytes in 0 blocks
==4764== Rerun with --leak-check=full to see details of leaked memory
==4764== 
==4764== For counts of detected and suppressed errors, rerun with: -v
==4764== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==4765== Syscall param ioctl(generic) points to uninitialised byte(s)
==4765==    at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765==    by 0x1A40469: ??? (in /lib/libpcap.so.8)
==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765==    by 0x120FE6A: driver_init (recfm.c:387)
==4765==    by 0x402633: main (driver.c:224)
==4765==  Address 0x7ff000270 is on thread 1's stack
==4765==  Uninitialised value was created by a stack allocation
==4765==    at 0x1A3FED0: ??? (in /lib/libpcap.so.8)
==4765== 
==4765== Conditional jump or move depends on uninitialised value(s)
==4765==    at 0x1A408DD: ??? (in /lib/libpcap.so.8)
==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765==    by 0x120FE6A: driver_init (recfm.c:387)
==4765==    by 0x402633: main (driver.c:224)
==4765==  Uninitialised value was created by a heap allocation
==4765==    at 0x1008DAB: malloc (vg_replace_malloc.c:274)
==4765==    by 0x1A4013E: ??? (in /lib/libpcap.so.8)
==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765==    by 0x120FE6A: driver_init (recfm.c:387)
==4765==    by 0x402633: main (driver.c:224)
==4765== 
==4765== Warning: noted but unhandled ioctl 0x20004269 with no size/direction hints   This could cause spurious value errors to appear.   See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.Syscall param ioctl(generic) points to uninitialised byte(s)
==4765==    at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765==    by 0x1A40291: ??? (in /lib/libpcap.so.8)
==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765==    by 0x120FE6A: driver_init (recfm.c:387)
==4765==    by 0x402633: main (driver.c:224)
==4765==  Address 0x7fefffd14 is on thread 1's stack
==4765==  Uninitialised value was created by a stack allocation
==4765==    at 0x1A3FEF8: ??? (in /lib/libpcap.so.8)
==4765== 
==4765== Syscall param ioctl(generic) points to uninitialised byte(s)
==4765==    at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765==    by 0x1A40C98: ??? (in /lib/libpcap.so.8)
==4765==    by 0x1823277: pcap_init (pcaputil.c:98)
==4765==    by 0x120FE6A: driver_init (recfm.c:387)
==4765==    by 0x402633: main (driver.c:224)
==4765==  Address 0x7ff000454 is on thread 1's stack
==4765==  Uninitialised value was created by a stack allocation
==4765==    at 0x1822C10: pcap_init (pcaputil.c:61)
==4765== 
--4765-- WARNING: unhandled syscall: 522
--4765-- You may be able to write your own handler.
--4765-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4765-- Nevertheless we consider this a bug.  Please report
--4765-- it at http://valgrind.org/support/bug_reports.html.

...repeated a bunch of times

その最後の警告は何度も繰り返されますが、必ずしも問題があるとは思いませんよね? もっと心配なのは、私が思うもう一つの問題です。

私のプログラムはまだバックグラウンドで実行されているようですが、明らかに valgrind から適切なレポートが得られません。それが言及している問題のある行の1つは pcaputil:77 です

これは次のとおりです。

pd=pcap_open_live(__intf, snaplen, 1, 512, ebuf)

_intf、はchar *、は配列ですsnaplenintebufchar ebuf[SIZE] = {0};

4

2 に答える 2

1

実際、それはValgrind-for-FreeBSDがいくつかのioctlを実際に理解していないだけです。同じ問題がOSXにも存在します(おそらく他のすべての* BSDにも存在します)。Valgrindのバグ312989を参照してください(KDEのバグデータベースを使用しています。実際には300,000を超えるバグはありません:-))。

FreeBSDの修正も同様ですが、何らかの理由で、「システムヘッダーファイルをインクルードする」というDarwinの規則ではなく、「インクルードファイルからValgrindソースにすべてのものをコピーする」というLinuxの規則を採用することにしました。 ; これは、ヘッダーファイルにもう少し作業が必要になることを意味します。FreeBSD Valgrindのメンテナに、ダーウィンのアプローチの方が良いかどうか尋ねます。

于 2013-01-10T04:27:26.007 に答える
0

さて、Valgrindにはバグがあります。FreeBSDには、処理しないシステムコールがあります。おそらくpcapが呼び出すものです。これが伝播し、Valgrindがpcapが初期化されていないデータにジャンプしていると言う可能性があります。プログラムが正常に機能している可能性もあり、問題があるのはValgrindだけです。最善の方法は、独自のioctlラッパーを追加し、valgrindにパッチを適用して、それでも問題が発生するかどうかを確認することです。または、使用しているシステムコールを使用しないpcapの代替を使用することもできます。

それが単純な解決策ではない場合は申し訳ありません。

于 2013-01-09T16:00:39.980 に答える