public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again Date: Tue, 19 May 2015 01:15:00 -0000 [thread overview] Message-ID: <bug-16159-131-yH7ZsuMfrN@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-16159-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=16159 --- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via fff94fa2245612191123a8015eac94eb04f001e2 (commit) via 99db95db37b4fd95986fadb263e4180b7381d10d (commit) via 920d70128baa41ce6ce3b1b4771fe912f8d1691a (commit) from 46f894d8c60afcc06056a376340df2f378694551 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fff94fa2245612191123a8015eac94eb04f001e2 commit fff94fa2245612191123a8015eac94eb04f001e2 Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Tue May 19 06:40:37 2015 +0530 Avoid deadlock in malloc on backtrace (BZ #16159) When the malloc subsystem detects some kind of memory corruption, depending on the configuration it prints the error, a backtrace, a memory map and then aborts the process. In this process, the backtrace() call may result in a call to malloc, resulting in various kinds of problematic behavior. In one case, the malloc it calls may detect a corruption and call backtrace again, and a stack overflow may result due to the infinite recursion. In another case, the malloc it calls may deadlock on an arena lock with the malloc (or free, realloc, etc.) that detected the corruption. In yet another case, if the program is linked with pthreads, backtrace may do a pthread_once initialization, which deadlocks on itself. In all these cases, the program exit is not as intended. This is avoidable by marking the arena that malloc detected a corruption on, as unusable. The following patch does that. Features of this patch are as follows: - A flag is added to the mstate struct of the arena to indicate if the arena is corrupt. - The flag is checked whenever malloc functions try to get a lock on an arena. If the arena is unusable, a NULL is returned, causing the malloc to use mmap or try the next arena. - malloc_printerr sets the corrupt flag on the arena when it detects a corruption - free does not concern itself with the flag at all. It is not important since the backtrace workflow does not need free. A free in a parallel thread may cause another corruption, but that's not new - The flag check and set are not atomic and may race. This is fine since we don't care about contention during the flag check. We want to make sure that the malloc call in the backtrace does not trip on itself and all that action happens in the same thread and not across threads. I verified that the test case does not show any regressions due to this patch. I also ran the malloc benchmarks and found an insignificant difference in timings (< 2%). * malloc/Makefile (tests): New test case tst-malloc-backtrace. * malloc/arena.c (arena_lock): Check if arena is corrupt. (reused_arena): Find a non-corrupt arena. (heap_trim): Pass arena to unlink. * malloc/hooks.c (malloc_check_get_size): Pass arena to malloc_printerr. (top_check): Likewise. (free_check): Likewise. (realloc_check): Likewise. * malloc/malloc.c (malloc_printerr): Add arena argument. (unlink): Likewise. (munmap_chunk): Adjust. (ARENA_CORRUPTION_BIT): New macro. (arena_is_corrupt): Likewise. (set_arena_corrupt): Likewise. (sysmalloc): Use mmap if there are no usable arenas. (_int_malloc): Likewise. (__libc_malloc): Don't fail if arena_get returns NULL. (_mid_memalign): Likewise. (__libc_calloc): Likewise. (__libc_realloc): Adjust for additional argument to malloc_printerr. (_int_free): Likewise. (malloc_consolidate): Likewise. (_int_realloc): Likewise. (_int_memalign): Don't touch corrupt arenas. * malloc/tst-malloc-backtrace.c: New test case. https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=99db95db37b4fd95986fadb263e4180b7381d10d commit 99db95db37b4fd95986fadb263e4180b7381d10d Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Tue May 19 06:36:29 2015 +0530 Succeed if make check does not report any errors The conditional that evaluates if there are any FAILed test cases currently always fails, since we ensure it fails if we find any unexpected results in tests.sum and it would obviously fail if it does not find failed results in tests.sum. This patch fixes this by simply inverting the result of the egrep, i.e. succeed if egrep fails (to find failed results) and fail if it succeeds. Tested with 'make subdirs=localedata check' and 'make subdirs=locale check' where all tests succeed and with 'make subdirs=elf check' where a couple of tests fail for me. * Makefile (summarize-tests): Fix return value on success. https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=920d70128baa41ce6ce3b1b4771fe912f8d1691a commit 920d70128baa41ce6ce3b1b4771fe912f8d1691a Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Tue May 19 06:35:37 2015 +0530 Add envz_remove to the libc manual I was told that Ma Shimao submitted a patch to add envz_remove to the libc manual, but the patch could not be accepted since he does not have a copyright assignment in place. I have been woefully behind on libc-alpha recently and have not seen the patch or the discussion thread. I have also not read the man page for envz_remove, so Alexandre Oliva asked me if I could write this independently and post a patch. The patch below is the result of the same - I have written it based on the implementation in string/envz.c and Alex told me via email that the function is AS, AC and MT-safe like envz_strip. I assume Alex and Carlos cannot review this since they have been tainted by the original patch (I haven't even tried to look for a link to it since I don't want to be tainted) so someone else will have to review this. If there are no reviewers till the end of the week, I will commit this since I believe there is a chance that there are no other reviewers who haven't read that thread. * manual/string.texi (Envz Functions): Add envz_remove. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 35 ++++ Makefile | 2 +- NEWS | 20 +- malloc/Makefile | 6 +- malloc/arena.c | 22 ++- malloc/hooks.c | 12 +- malloc/malloc.c | 173 ++++++++++++-------- .../tst-detach1.c => malloc/tst-malloc-backtrace.c | 49 +++--- manual/string.texi | 8 + 9 files changed, 213 insertions(+), 114 deletions(-) copy nptl/tst-detach1.c => malloc/tst-malloc-backtrace.c (57%) -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2015-05-19 1:15 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-11-13 3:30 [Bug malloc/16159] New: " darryl.miles at darrylmiles dot org 2013-11-13 3:31 ` [Bug malloc/16159] " darryl.miles at darrylmiles dot org 2013-11-13 3:37 ` darryl.miles at darrylmiles dot org 2013-11-13 3:44 ` carlos at redhat dot com 2013-11-13 3:57 ` carlos at redhat dot com 2013-11-13 7:57 ` Ondřej Bílka 2013-11-13 7:57 ` neleai at seznam dot cz 2013-11-13 13:00 ` darryl.miles at darrylmiles dot org 2013-11-13 14:31 ` Ondřej Bílka 2013-11-13 13:11 ` darryl.miles at darrylmiles dot org 2013-11-13 14:31 ` neleai at seznam dot cz 2013-11-13 15:50 ` bugdal at aerifal dot cx 2013-11-13 16:03 ` carlos at redhat dot com 2013-11-13 16:12 ` joseph at codesourcery dot com 2013-11-13 16:23 ` Ondřej Bílka 2013-11-13 16:23 ` neleai at seznam dot cz 2013-11-13 16:28 ` bugdal at aerifal dot cx 2013-11-13 16:30 ` bugdal at aerifal dot cx 2013-11-13 16:47 ` joseph at codesourcery dot com 2013-11-13 16:54 ` joseph at codesourcery dot com 2013-11-14 14:32 ` neleai at seznam dot cz 2013-11-14 15:54 ` bugdal at aerifal dot cx 2013-11-14 16:47 ` neleai at seznam dot cz 2013-11-14 17:08 ` bugdal at aerifal dot cx 2013-11-28 13:52 ` eblake at redhat dot com 2014-02-23 23:34 ` adconrad at 0c3 dot net 2014-06-13 12:18 ` fweimer at redhat dot com 2015-05-19 1:15 ` cvs-commit at gcc dot gnu.org [this message] 2015-05-19 1:16 ` siddhesh 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=bug-16159-131-yH7ZsuMfrN@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /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).