This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid deadlock in malloc on backtrace
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 05 Mar 2015 14:22:22 -0500
- Subject: Re: [PATCH] Avoid deadlock in malloc on backtrace
- Authentication-results: sourceware.org; auth=none
- References: <20150224100249 dot GA31871 at spoyarek dot pnq dot redhat dot com> <54EF9B9C dot 1080305 at redhat dot com> <20150302053051 dot GT19363 at vapier> <20150302173442 dot GW23507 at brightrain dot aerifal dot cx> <20150302175723 dot GL8519 at vapier>
On 03/02/2015 12:57 PM, Mike Frysinger wrote:
> to be clear, while i support adding an optional "paranoid" mode, i'm entirely
> against disabling them by default. these crash messages have improved the lives
> of users and developers significantly since they were added. i don't have data
> to back this claim up, but having worked as a developer writing my own code,
> an upstream developer releasing my own packages, and a distro maintainer on a
> wide swath of packages, all continuously since the glibc 2.2.5 days, i think my
> anecdotal memory is sufficient. as a maintainer of the toolchain, i certainly
> know it helps bucket bugs -- before this message, most random crashes were
> thrown at the toolchain distro maintainers (after all, a crash in malloc must
> surely be the fault of the C library). now with all the memory corruption
> hooks, we've got a pretty strong/reliable signal that it is entirely the fault
> of the package. returning to that status quo would be a terrible idea.
>
> if a distro has frameworks in place to replace the functionality of these (e.g.
> a core dump handler), then they can make the decision to also opt in their C
> library to this mode. on Gentoo, we make the decision based on how hardened the
> user wants their system.
That's a very cogent argument for keeping the status-quo behaviour and fixing
the deadlock, while continuing the discussion over what exactly should be done.
Cheers,
Carlos.