[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks
From: |
Darshit Shah |
Subject: |
Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks |
Date: |
Sun, 8 Sep 2013 18:14:17 +0530 |
> 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
- [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Darshit Shah, 2013/09/07
- Message not available
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks,
Darshit Shah <=
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Giuseppe Scrivano, 2013/09/08
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Ángel González, 2013/09/08
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Darshit Shah, 2013/09/09
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Darshit Shah, 2013/09/11
- Re: [Bug-wget] [bug-wget] Segfault when trying to use metalinks, Ángel González, 2013/09/11