Created attachment 9315 [details] tmp/tst-dprintf-malloc.c After this commit (which went into glibc 2.23), dprintf unconditionally uses malloc to allocate a temporary buffer: commit 8a29509dd9aa179bfe4ef96d49d72f6816ec878f Author: Paul Pluzhnikov <ppluzhnikov@google.com> Date: Wed Aug 12 18:56:08 2015 -0700 Fix BZ #16734 -- fopen calls mmap to allocate its buffer I'm attaching a simple test case. Our dprintf is never completely async-signal-safe because it calls malloc in corner cases (see bug 16060), but the unconditional malloc call stretches things. Rather than reverting to mmap, we should probably use a buffer on the stack. (I found this while reading the libio source code for the vtables reorganization, not through user bug reports.)
Note that dprintf need not be AS-safe, POSIX doesn't mandate it, and we don't document any safety standard for it in the glibc manual, nor in the linux man pages project. The original author of the interface (Roland McGrath) has stated that he intended it to be AS-safe, but we don't know if that's even possible today. I don't quite understand why this is filed as a distinct bug from bug 16060?
(In reply to Carlos O'Donell from comment #1) > Note that dprintf need not be AS-safe, POSIX doesn't mandate it, and we > don't document any safety standard for it in the glibc manual, nor in the > linux man pages project. The original author of the interface (Roland > McGrath) has stated that he intended it to be AS-safe, but we don't know if > that's even possible today. > > I don't quite understand why this is filed as a distinct bug from bug 16060? It's a regression in 2.23. It's fix probably will not address the other issues in bug 16060.
(In reply to Florian Weimer from comment #2) > (In reply to Carlos O'Donell from comment #1) > > Note that dprintf need not be AS-safe, POSIX doesn't mandate it, and we > > don't document any safety standard for it in the glibc manual, nor in the > > linux man pages project. The original author of the interface (Roland > > McGrath) has stated that he intended it to be AS-safe, but we don't know if > > that's even possible today. > > > > I don't quite understand why this is filed as a distinct bug from bug 16060? > > It's a regression in 2.23. It's fix probably will not address the other > issues in bug 16060. What's the regression?
(In reply to Carlos O'Donell from comment #3) > (In reply to Florian Weimer from comment #2) > > (In reply to Carlos O'Donell from comment #1) > > > Note that dprintf need not be AS-safe, POSIX doesn't mandate it, and we > > > don't document any safety standard for it in the glibc manual, nor in the > > > linux man pages project. The original author of the interface (Roland > > > McGrath) has stated that he intended it to be AS-safe, but we don't know if > > > that's even possible today. > > > > > > I don't quite understand why this is filed as a distinct bug from bug 16060? > > > > It's a regression in 2.23. It's fix probably will not address the other > > issues in bug 16060. > > What's the regression? Before, you could call dprintf from a signal handler, interrupting malloc, and it would work if the format string was reasonable (no self-deadlock). After the change to use malloc for the temporary buffer instead of mmap, you end up with a self-deadlock.
(In reply to Florian Weimer from comment #4) > > > It's a regression in 2.23. It's fix probably will not address the other > > > issues in bug 16060. > > > > What's the regression? > > Before, you could call dprintf from a signal handler, interrupting malloc, > and it would work if the format string was reasonable (no self-deadlock). > After the change to use malloc for the temporary buffer instead of mmap, you > end up with a self-deadlock. We might document asprintf as being conditionally AS-safe, but what might the conditions of safety be?