This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV
- From: "david.abdurachmanov at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 06 Jun 2014 22:09:07 +0000
- Subject: [Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV
- Auto-submitted: auto-generated
- References: <bug-13862-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=13862
David Abdurachmanov <david.abdurachmanov at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |david.abdurachmanov at gmail dot c
| |om
--- Comment #8 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I have noticed deadlock in our application on aarch64 (ARMv8 64-bit) on Fedora
19, glibc 2.17.
Our main application uses jemalloc, but on aarch64 we used glibc malloc
implementation. I found that this happens also on x86_64 with glibc used, but
not with jemalloc. x86_64 machine is running Scientific Linux 6.5 (RHEL 6.5)
with glibc 2.12.
valgrind results from x86_64:
==28032== Invalid write of size 8
==28032== at 0x3AF1811000: _dl_allocate_tls_init (in /lib64/ld-2.12.so)
==28032== by 0x3AF2406C20: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.12.so)
==28032== by 0x26A0A995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)
==28032== Invalid write of size 1
==28032== at 0x3AF1811013: _dl_allocate_tls_init (in /lib64/ld-2.12.so)
==28032== by 0x3AF2406C20: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.12.so)
==28032== by 0x26A0A995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xrootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)
I compiler plain 2.12 (origin/release/2.12/master) with debug information and
used new ld.so with valgrind:
==17333== Invalid write of size 8
==17333== at 0x118521: _dl_allocate_tls_init (dl-tls.c:421)
==17333== by 0x84BF29F: pthread_create@@GLIBC_2.2.5 (allocatestack.c:247)
==17333== by 0x2803B995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)
==17333== Invalid write of size 1
==17333== at 0x118534: _dl_allocate_tls_init (dl-tls.c:422)
==17333== by 0x84BF29F: pthread_create@@GLIBC_2.2.5 (allocatestack.c:247)
==17333== by 0x2803B995: XrdSysThread::Run(unsigned long*, void* (*)(void*),
void*, int, char const*) (in
/afs/cern.ch/cms/sw/ReleaseCandidates/vol1/slc6_amd64_gcc490/external/xr
ootd/3.2.4-cms2/lib/libXrdUtils.so.1.0.0)
416 if (map->l_tls_offset == NO_TLS_OFFSET
417 || map->l_tls_offset == FORCED_DYNAMIC_TLS_OFFSET)
418 {
419 /* For dynamically loaded modules we simply store
420 the value indicating deferred allocation. */
421 dtv[map->l_tls_modid].pointer.val = TLS_DTV_UNALLOCATED;
422 dtv[map->l_tls_modid].pointer.is_static = false;
423 continue;
424 }
421 and 422 lines. Is map->l_tls_modid correct?
So far I have not seen these invalid writes if jemalloc is used instead of
glibc.
--
You are receiving this mail because:
You are on the CC list for the bug.