This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]