这似乎与我之前的帖子重复，但它不是......
这里 Valgrind 给出以下错误:
udit@udit-Dabba ~/mec $ valgrind --leak-check=full
sendip -v -p ipv6 -f file.txt -6s ::1 -p esp -es 0x20 -eq 0x40
-ei z30 -eI z100 -p tcp -ts 21 -td 21 ::2
==4331== Memcheck, a memory error detector
==4331== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4331== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==4331== Command: sendip -v -p ipv6 -f file.txt -6s ::1 -p esp -es 0x20
-eq 0x40 -ei z30 -eI z100 -p tcp -ts 21 -td 21 ::2
==4331==
esp
Added 43 options
Initializing module ipv6
Initializing module esp
Initializing module tcp
==4331== Invalid write of size 4
==4331== at 0x4027EB8: memcpy (mc_replace_strmem.c:635)
==4331== by 0x4032269: do_opt (esp.c:113)
==4331== by 0x804A51D: main (sendip.c:575)
==4331== Address 0x41ceab0 is 144 bytes inside a block of size 146 alloc'd
==4331== at 0x402699A: realloc (vg_replace_malloc.c:525)
==4331== by 0x4032231: do_opt (esp.c:111)
==4331== by 0x804A51D: main (sendip.c:575)
==4331==
valgrind: m_mallocfree.c:225 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
==4331== at 0x380282BD: report_and_quit (m_libcassert.c:193)
==4331== by 0x38028415: vgPlain_assert_fail (m_libcassert.c:267)
==4331== by 0x380351E7: vgPlain_arena_malloc (m_mallocfree.c:225)
==4331== by 0x380662C7: vgPlain_cli_malloc (replacemalloc_core.c:83)
==4331== by 0x38001FA8: vgMemCheck_new_block (mc_malloc_wrappers.c:201)
==4331== by 0x38002196: vgMemCheck_malloc (mc_malloc_wrappers.c:238)
==4331== by 0x38068BF8: vgPlain_scheduler (scheduler.c:1394)
==4331== by 0x3807A354: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==4331== at 0x40268A4: malloc (vg_replace_malloc.c:236)
==4331== by 0x4152415: gethostbyname2 (getXXbyYY.c:103)
==4331== by 0x402CC68: set_addr (ipv6.c:33)
==4331== by 0x804A642: main (sendip.c:594)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
esp.c (第 113 行)
case 'eI': /* ICV data (variable length) */
/* For right now, we will do either random generation
* or a user-provided string. We put it in the header,
* then move it into the trailer in finalize.
*/
length = stringargument(arg, &temp);
priv->icvlen = length;
pack->alloc_len += length;
pack->data = realloc(esp, pack->alloc_len);
esp = (esp_header *)pack->data;
113:
memcpy(&esp->tail.ivicv[priv->ivlen],temp, priv->icvlen);
pack->modified |= ESP_MOD_ICV;
这些是我认为可能有助于调试的相应头文件......
ip6.h
/*
* authentication header
*/
struct ip_auth_hdr {
u_int8_t nexthdr;
u_int8_t hdrlen; /* This one is measured in 32 bit units! */
u_int16_t reserved;
u_int32_t spi;
u_int32_t seq_no; /* Sequence number */
u_int8_t auth_data[0]; /* Variable len but >=4. Mind the
64 bit alignment! */
#define icv auth_data /* rfc 4302 name */
/* TBD - high-order sequence number */
};
/*
* encapsulated security payload header
*/
struct ip_esp_hdr {
u_int32_t spi;
u_int32_t seq_no; /* Sequence number */
u_int8_t enc_data[0]; /* Variable len but >=8. Mind the
64 bit alignment! */
};
esp.h
struct ip_esp_tail {
u_int8_t padlen; /* padding is pushed before tail */
u_int8_t nexthdr;
u_int32_t ivicv[0]; /* both IV and ICV, if any */
};
struct ip_esp_headtail {
struct ip_esp_hdr hdr;
struct ip_esp_tail tail;
};
typedef struct ip_esp_headtail esp_header;
#define ESP_MIN_PADDING 4
typedef struct ip_esp_private { /* keep track of things privately */
u_int32_t type; /* type = IPPROTO_ESP */
u_int32_t ivlen; /* length of IV portion */
u_int32_t icvlen; /* length of ICV portion */
u_int32_t keylen; /* length of "key" (not transmitted data) */
u_int32_t key[0]; /* key itself */
} esp_private;
struct ip_auth_hdr {
u_int8_t nexthdr;
u_int8_t hdrlen; /* This one is measured in 32 bit units! */
u_int16_t reserved;
u_int32_t spi;
u_int32_t seq_no; /* Sequence number */
u_int8_t auth_data[0]; /* Variable len but >=4. Mind the
64 bit alignment! */
#define icv auth_data /* rfc 4302 name */
/* TBD - high-order sequence number */
};
/*
* encapsulated security payload header
*/
struct ip_esp_hdr {
u_int32_t spi;
u_int32_t seq_no; /* Sequence number */
u_int8_t enc_data[0]; /* Variable len but >=8. Mind the
64 bit alignment! */
};
如果有人知道泄漏发生在哪里？？？以及如何修补它？
最佳答案
正如克里斯所说，valgrind 告诉您，您的程序正在尝试写入分配区域之外的内存:
Invalid write of size 4
at 0x4027EB8: memcpy (mc_replace_strmem.c:635)
by 0x4032269: do_opt (esp.c:113)
by 0x804A51D: main (sendip.c:575)
Address 0x41ceab0 is 144 bytes inside a block of size 146 alloc'd
at 0x402699A: realloc (vg_replace_malloc.c:525)
by 0x4032231: do_opt (esp.c:111)
by 0x804A51D: main (sendip.c:575)
它告诉你在 do_opt 中(在文件 esp.c 的第 111 行)你调用了 realloc 来分配 146 字节的内存，现在函数 memcpy 正试图从开始的 144 字节开始进行 4 字节的写入内存块，这将导致分配区域之外的写入 (144 + 4 > 146)。它还告诉您 memcpy 是从 do_opt 函数调用的。
因此，您要么分配到很少的内存，要么在复制到内存时使用了错误的偏移量。所以下一步是检查 valgrind 报告的位置中的代码。
但是如果在查看代码时问题不明显怎么办？
一种选择是使用 valgrind 的
--db-attach option ，它允许您输入 gdb。这将允许您环顾四周并检查诸如 weather pack->alloc_len 是您期望的值，如果 &esp->tail.ivicv[priv->ivlen]指向您期望它与 pack->data 进行比较的宫殿。 (这也可以通过添加 printf 打印这些值的经典方式来完成)。以下是我的猜测 问题是什么，但如果你想先自己弄清楚，那就隐藏起来:
也许您忘记了 ivicv 是一个 uint32，而您的 priv->ivlen 以字节为单位。在这种情况下，将其更改为
&esp->tail.ivicv[priv->ivlen / sizeof(u_int32_t)]有助于
关于c - Valgrind 给出错误，但一切似乎都很好，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7662008/