> Try running the segfaulting metalink wget under valgrind. > As Angel suggested, I ran the wget with the said metalink file through valgrind. THe results are quite surprising:
└─(~/testing)─(14 files, total 704Kb)─> valgrind --leak-check=full ./wget --metalink metalink ==29833== Memcheck, a memory error detector ==29833== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==29833== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==29833== Command: ./wget --metalink metalink ==29833== ==29833== Invalid write of size 4 ==29833== at 0x440FFA: fill_ranges_data (multi.c:148) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0b0 is 0 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid write of size 4 ==29833== at 0x441022: fill_ranges_data (multi.c:149) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0b4 is 4 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid write of size 4 ==29833== at 0x44104D: fill_ranges_data (multi.c:150) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0bc is 12 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid read of size 4 ==29833== at 0x441054: fill_ranges_data (multi.c:150) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0bc is 12 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid write of size 4 ==29833== at 0x441057: fill_ranges_data (multi.c:150) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0b8 is 8 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid write of size 8 ==29833== at 0x44107C: fill_ranges_data (multi.c:151) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0c0 is 16 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid write of size 4 ==29833== at 0x441094: fill_ranges_data (multi.c:152) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0c8 is not stack'd, malloc'd or (recently) free'd ==29833== ==29833== Invalid read of size 8 ==29833== at 0x4410B8: fill_ranges_data (multi.c:154) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0c0 is 16 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== ==29833== Invalid read of size 4 ==29833== at 0x4410EF: fill_ranges_data (multi.c:156) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) ==29833== Address 0x698d0b4 is 4 bytes after a block of size 32 alloc'd ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x440F8B: init_ranges (multi.c:129) ==29833== by 0x4311C8: retrieve_from_file (retr.c:1091) ==29833== by 0x429C34: main (main.c:1739) ==29833== --29833-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --29833-- si_code=1; Faulting address: 0x1F; sp: 0x402a63d90 valgrind: the 'impossible' happened: Killed by fatal signal ==29833== at 0x3806282D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==29833== by 0x38063FC7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==29833== by 0x3802B26C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==29833== by 0x3802B3F2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==29833== by 0x3809D44D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==29833== by 0x380AC00C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==29833== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29833== by 0x44107B: fill_ranges_data (multi.c:151) ==29833== by 0x43127A: retrieve_from_file (retr.c:1105) ==29833== by 0x429C34: main (main.c:1739) 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. The various invalid reads seem to be causing a problem. When using another metalink file, the one downloaded from ubuntu.com, these errors do not appear. However, the following does prop up: ==29869== Thread 2: ==29869== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==29869== at 0x6478FEF: sendmmsg (in /usr/lib/libc-2.18.so) ==29869== by 0x79853E2: ??? (in /usr/lib/libresolv-2.18.so) ==29869== by 0x7982BF4: __libc_res_nquery (in /usr/lib/libresolv-2.18.so) ==29869== by 0x79831DE: ??? (in /usr/lib/libresolv-2.18.so) ==29869== by 0x79837C6: __libc_res_nsearch (in /usr/lib/libresolv-2.18.so ) ==29869== by 0x7777A8A: _nss_dns_gethostbyname4_r (in /usr/lib/ libnss_dns-2.18.so) ==29869== by 0x6462974: gaih_inet (in /usr/lib/libc-2.18.so) ==29869== by 0x6464E0C: getaddrinfo (in /usr/lib/libc-2.18.so) ==29869== by 0x41739F: getaddrinfo_with_timeout_callback (host.c:384) ==29869== by 0x43F382: run_with_timeout (utils.c:2007) ==29869== by 0x417403: getaddrinfo_with_timeout (host.c:402) ==29869== by 0x417BE4: lookup_host (host.c:779) ==29869== Address 0x7564610 is on thread 2's stack ==29869== ==29869== Thread 1: ==29869== 11 bytes in 1 blocks are definitely lost in loss record 7 of 56 ==29869== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29869== by 0x44E5B4: xmalloc (xmalloc.c:41) ==29869== by 0x44E6DC: xmemdup (xmalloc.c:113) ==29869== by 0x44E71C: xstrdup (xmalloc.c:121) ==29869== by 0x4418D6: parse_metalink (metalink.c:137) ==29869== by 0x431173: retrieve_from_file (retr.c:1074) ==29869== by 0x429C34: main (main.c:1739) ==29869== ==29869== 72 bytes in 1 blocks are definitely lost in loss record 38 of 56 ==29869== at 0x4C2757B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29869== by 0x44E5B4: xmalloc (xmalloc.c:41) ==29869== by 0x44E6DC: xmemdup (xmalloc.c:113) ==29869== by 0x44E71C: xstrdup (xmalloc.c:121) ==29869== by 0x4418A8: parse_metalink (metalink.c:136) ==29869== by 0x431173: retrieve_from_file (retr.c:1074) ==29869== by 0x429C34: main (main.c:1739) ==29869== ==29869== 288 bytes in 1 blocks are possibly lost in loss record 48 of 56 ==29869== at 0x4C29734: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29869== by 0x4010EE1: allocate_dtv (in /usr/lib/ld-2.18.so) ==29869== by 0x40115ED: _dl_allocate_tls (in /usr/lib/ld-2.18.so) ==29869== by 0x5ADAC11: pthread_create@@GLIBC_2.2.5 (in /usr/lib/ libpthread-2.18.so) ==29869== by 0x4413AE: spawn_thread (multi.c:199) ==29869== by 0x431402: retrieve_from_file (retr.c:1134) ==29869== by 0x429C34: main (main.c:1739) ==29869== ==29869== LEAK SUMMARY: ==29869== definitely lost: 83 bytes in 2 blocks ==29869== indirectly lost: 0 bytes in 0 blocks ==29869== possibly lost: 288 bytes in 1 blocks ==29869== still reachable: 45,433 bytes in 1,097 blocks ==29869== suppressed: 0 bytes in 0 blocks ==29869== Reachable blocks (those to which a pointer was found) are not shown. ==29869== To see them, rerun with: --leak-check=full --show-reachable=yes ==29869== All the leaks seem to originate from the metalink related code. There do exist a few leaks in the Wget trunk code, but they did not prop up here. -- Thanking You, Darshit Shah
