public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cr at progress dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/9721] New: dl-tls.c: tls_get_addr, etc, allocate using __libc_memalign but free with free - causes problems if you link a different malloc/free/etc library Date: Thu, 08 Jan 2009 11:14:00 -0000 [thread overview] Message-ID: <20090108111436.9721.cr@progress.com> (raw) We link with ptmalloc3 for performance reasons, but find that using thread-local storage (in dlopen'ed libraries, though that may not be relevant) causes crashes. Valgrind shows memory has been allocated with it's memalign, but freed with ptmalloc3's free: ==24649== Thread 4: ==24649== Invalid read of size 4 ==24649== at 0x83951C3: free (ptmalloc3.c:764) ==24649== by 0x348B1A: ___tls_get_addr (in /lib/ld-2.3.4.so) ==24649== by 0x1708E88F: ShutdownLibrary (TimeFormatPlugin.cpp:934) ==24649== by 0x8285F85: CorrelatorPluginType::~CorrelatorPluginType() (CorrelatorPlugin.cpp:524) ==24649== by 0x81669D0: .... ... ==24649== Address 0x66613BC is 4 bytes before a block of size 4 alloc'd ==24649== at 0x4005F7F: memalign (m_replacemalloc/vg_replace_malloc.c:332) ==24649== by 0x348BC8: ___tls_get_addr (in /lib/ld-2.3.4.so) ==24649== by 0x14F7988F: ??? ==24649== by 0x8285F85: CorrelatorPluginType::~CorrelatorPluginType() (CorrelatorPlugin.cpp:524) ==24649== by 0x81669D0: .... ... I think when running natively, the allocation occurs from libc's __libc_memalign in /lib/libc.so but the free from ptmalloc3. This is on Redhat Enterprise 4, but looking in CVS the trunk is the same - calling __libc_memalign and free. Is there a particular reason to use inconsistent prefixes on the symbols? If it used __libc_memalign and __libc_free or memalign and free, I believe it would fix our problem; would it cause other problems? We are working around it by including a __libc_memalign symbol in ptmalloc3, but that's ugly. -- Summary: dl-tls.c: tls_get_addr, etc, allocate using __libc_memalign but free with free - causes problems if you link a different malloc/free/etc library Product: glibc Version: 2.3.4 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: cr at progress dot com CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=9721 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
next reply other threads:[~2009-01-08 11:14 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-01-08 11:14 cr at progress dot com [this message] 2009-01-08 15:28 ` [Bug libc/9721] " drepper at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090108111436.9721.cr@progress.com \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).