[Bug 490024] Re: assert hit in eglibc (valloc) with libtorrent v0.15
Bug Watch Updater
490024 at bugs.launchpad.net
Wed May 25 23:02:02 UTC 2011
Launchpad has imported 8 comments from the remote bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=5553.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-01-08T16:54:12+00:00 Drow-sources wrote:
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/0
------------------------------------------------------------------------
On 2008-01-08T17:00:51+00:00 Drow-sources wrote:
Created attachment 2187
Proposed fix.
Sorry about the broken bug; I hit enter accidentally.
The failing assertion is this one:
assert(!victim || chunk_is_mmapped(mem2chunk(victim)) ||
ar_ptr == arena_for_chunk(mem2chunk(victim)));
GDB's bigcore.c testcase triggers this assertion on several PowerPC systems I
tested. It starts by a malloc too large for the system to satisfy; when
_int_malloc fails, malloc creates and tries a new arena. This arena is saved
as the default arena for the main thread so future allocations come from that
arena instead of the main one.
Later the test tries a malloc which can be met by mmap. Eventually mmap
returns ENOMEM after a number of similar allocations:
mmap(NULL, 134221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa810c000
mmap(NULL, 134221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb010d000
mmap(NULL, 134221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
-1 ENOMEM (Cannot alloca
te memory)
mmap(NULL, 134221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
-1 ENOMEM (Cannot alloca
te memory)
brk(0x180c1000) = 0x180c1000
I do not know why brk succeeded (another seven times, all 0x8000000 bytes) when
mmap failed. But the result is a non-mmapped chunk allocated from the main
arena. The assert checks the thread's specific arena and fails. Updating
ar_ptr fixes the failure.
Patch attached.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/1
------------------------------------------------------------------------
On 2008-01-09T20:35:28+00:00 Drepper-fsp wrote:
The patch is correct but incomplete. I've checked in the complete
version.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/2
------------------------------------------------------------------------
On 2008-01-09T20:49:06+00:00 Drow-sources wrote:
Thanks. Is your change to memalign correct?
ar_ptr = arena_get2(ar_ptr->next ? ar_ptr : 0, bytes);
+ (void)mutex_unlock(&ar_ptr->mutex);
if(ar_ptr) {
p = _int_memalign(ar_ptr, alignment, bytes);
(void)mutex_unlock(&ar_ptr->mutex);
if (!ar_ptr), segfault, else double unlock.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/3
------------------------------------------------------------------------
On 2010-02-24T11:33:14+00:00 Petr Baudis wrote:
valloc() implementation has the same problem.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/16
------------------------------------------------------------------------
On 2010-02-24T11:35:18+00:00 Petr Baudis wrote:
Created attachment 4624
proposed patch
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/17
------------------------------------------------------------------------
On 2010-02-24T23:45:22+00:00 Drepper-fsp wrote:
I've applied the patch. But you failed to update the copyright year and
provided no ChangeLog entry.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/18
------------------------------------------------------------------------
On 2010-02-25T10:30:04+00:00 Petr Baudis wrote:
Thanks. I have provided a changelog entry, but you are right that I forgot to
update the year.
Reply at: https://bugs.launchpad.net/deluge/+bug/490024/comments/19
** Changed in: eglibc
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/490024
Title:
assert hit in eglibc (valloc) with libtorrent v0.15
Status in Deluge BitTorrent Client:
Won't Fix
Status in Embedded GLIBC:
Fix Released
Status in The GNU C Library:
Invalid
Status in Bittorrent library by Rasterbar software:
Unknown
Status in qBittorrent - An advanced bittorrent client in C++ / Qt4:
Invalid
Status in “eglibc” package in Ubuntu:
Fix Released
Status in “eglibc” source package in Lucid:
Fix Committed
Bug description:
qb 2.0.0rc2, libtorrent-rasterbar-0.15.svn.r4053, Xubuntu 9.10
This is almost a daily pehnomenom. I finally succeed in goaching the stack trace, no obvious reason for the crash:
- - -
qbittorrent: malloc.c:3929: __libc_valloc: Assertion `!p ||
((((mchunkptr)((char*)(p) - 2*(sizeof(size_t)))))->size & 0x2) ||
ar_ptr == (((((mchunkptr)((char*)(p) - 2*(sizeof(size_t)))))->size &
0x4) ? ((heap_info *)((unsigned long)(((mchunkptr)((char*)(p) -
2*(sizeof(size_t))))) & ~((2 * (512 * 1024))-1)))->ar_ptr :
&main_arena)' failed.
*************************************************************
Catching SIGABRT, please report a bug at http://bug.qbittorrent.org
and provide the following backtrace:
stack trace:
[0xd86400]
[0xd86422]
/lib/tls/i686/cmov/libc.so.6 : gsignal()+0x51 [0x769f4d1]
/lib/tls/i686/cmov/libc.so.6 : abort()+0x182 [0x76a2932]
/lib/tls/i686/cmov/libc.so.6 : __assert_fail()+0xf8 [0x7698648]
/lib/tls/i686/cmov/libc.so.6 : __libc_valloc()+0x19f [0x76e46bf]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::page_aligned_allocator::malloc(unsigned int)+0x1d [0x100d43d]
/usr/local/lib/libtorrent-rasterbar.so.6 : boost::pool<libtorrent::page_aligned_allocator>::ordered_malloc_need_resize()+0x5a [0x103824a]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::disk_buffer_pool::allocate_buffer(char const*)+0xa6 [0x10323a6]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::disk_io_thread::read_into_piece(libtorrent::disk_io_thread::cached_piece_entry&, int, int, int, boost::unique_lock<boost::recursive_mutex>&)+0x103 [0x10324c3]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::disk_io_thread::copy_from_piece(std::_List_iterator<libtorrent::disk_io_thread::cached_piece_entry>, bool&, libtorrent::disk_io_job const&, boost::unique_lock<boost::recursive_mutex>&)+0x20d [0x1032a9d]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::disk_io_thread::try_read_from_cache(libtorrent::disk_io_job const&)+0x9a [0x103301a]
/usr/local/lib/libtorrent-rasterbar.so.6 : libtorrent::disk_io_thread::operator()()+0x181d [0x1034fcd]
/usr/local/lib/libtorrent-rasterbar.so.6 : boost::detail::thread_data<boost::reference_wrapper<libtorrent::disk_io_thread> >::run()+0x23 [0x103b2b3]
/usr/lib/libboost_thread.so.1.40.0 : thread_proxy()+0x65 [0x51bab5]
/lib/tls/i686/cmov/libpthread.so.0 [0xd7280e]
/lib/tls/i686/cmov/libc.so.6 : clone()+0x5e [0x77417ee]
$
More information about the foundations-bugs
mailing list