Это похоже на копию моего предыдущего поста, но это не .....
Здесь 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! */
};
Если кто-нибудь узнает, где происходит утечка ??? и как его залатать ??