assert hit in eglibc (valloc) with libtorrent v0.15
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Deluge |
Won't Fix
|
Unknown
|
|||
GLibC |
Invalid
|
Undecided
|
Unassigned | ||
eglibc |
Fix Released
|
Medium
|
|||
libtorrent-rasterbar |
Unknown
|
Unknown
|
|||
qBittorrent |
Invalid
|
Undecided
|
Christophe Dumez | ||
eglibc (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
qb 2.0.0rc2, libtorrent-
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)
*******
Catching SIGABRT, please report a bug at http://
and provide the following backtrace:
stack trace:
[0xd86400]
[0xd86422]
/lib/
/lib/
/lib/
/lib/
/usr/
/usr/
/usr/
/usr/
/usr/
/usr/
/usr/
/usr/
/usr/
/lib/
/lib/
$
Related branches
summary: |
- 2.0.0rc2 dies without any reason + qbittorrent 2.0.0rc2 dies without any reason |
summary: |
- qbittorrent 2.0.0rc2 dies without any reason + malloc assert hit with libtorrent v0.15 / eglibc |
summary: |
- malloc assert hit with libtorrent v0.15 / eglibc + assert hit in eglibc (valloc) with libtorrent v0.15 |
Changed in deluge: | |
status: | Unknown → Won't Fix |
tags: | added: patch |
Changed in eglibc (Ubuntu Lucid): | |
importance: | Undecided → Medium |
milestone: | none → lucid-updates |
status: | New → In Progress |
Changed in eglibc (Ubuntu): | |
status: | New → Fix Released |
Changed in glibc: | |
status: | New → Invalid |
Changed in eglibc: | |
status: | Unknown → Fix Released |
Changed in qbittorrent: | |
status: | Triaged → Invalid |
Changed in eglibc: | |
importance: | Unknown → Medium |
Created attachment 2187
Proposed fix.
Sorry about the broken bug; I hit enter accidentally.
The failing assertion is this one: mmapped( mem2chunk( victim) ) || chunk(mem2chunk (victim) ));
assert(!victim || chunk_is_
ar_ptr == arena_for_
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) = PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) =
0xa810c000
mmap(NULL, 134221824, PROT_READ|
0xb010d000
mmap(NULL, 134221824, PROT_READ|
-1 ENOMEM (Cannot alloca
te memory)
mmap(NULL, 134221824, PROT_READ|
-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.