This is the mail archive of the libc-help@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] |
On Tue, 4 Jun 2013, Siddhesh Poyarekar wrote:
On 4 June 2013 14:35, Dimitrios Apostolou <jimis@gmx.net> wrote:according to the libc manual, malloc is signal-safe in glibc. However I gotIf it really says that then it is a bug in the manual. malloc is not async-signal safe Please quote the section of the manual that mentions it and file a bug report.a deadlock when I sigTERM'd a process during malloc(), and it tried to log with vasprintf() (which itself calls malloc). Am I missing something regarding libc's malloc() reentrancy? Here is the backtrace I got:Maybe you confused it with thread-safe? malloc is thread-safe, but not async-signal-safe.
It seems you are right, I can't find the excerpt in the current libc manual! It seems google had directed me to some very old manual:Quoting http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html
On the GNU system, malloc and free are safe to use in signal handlers because it blocks signals. As a result, the library functions that allocate space for a result are also safe in signal handlers. The obstack allocation functions are safe as long as you don't use the same obstack both inside and outside of a signal handler.
Thanks, I'll remove all logging from the signal handler. Dimitris
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |