[FFmpeg-devel] [PATCH] avutil/log: Check and warn for recursive calls
Michael Niedermayer
michaelni at gmx.at
Thu Mar 20 17:57:23 CET 2014
On Thu, Mar 20, 2014 at 05:36:11PM +0100, wm4 wrote:
> On Thu, 20 Mar 2014 14:51:11 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
>
> > this only works when a error checking mutex is available.
> > an alternative would be to use thread local storage to implement our own checking mutex
> >
> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > ---
> > libavutil/log.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/log.c b/libavutil/log.c
> > index a0bb5e4..b32dfe0 100644
> > --- a/libavutil/log.c
> > +++ b/libavutil/log.c
> > @@ -42,7 +42,11 @@
> >
> > #if HAVE_PTHREADS
> > #include <pthread.h>
> > +# ifdef PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
> > +static pthread_mutex_t mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
> > +# else
> > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> > +# endif
> > #endif
> >
> > #define LINE_SZ 1024
> > @@ -251,7 +255,11 @@ void av_log_default_callback(void* ptr, int level, const char* fmt, va_list vl)
> > if (level > av_log_level)
> > return;
> > #if HAVE_PTHREADS
> > - pthread_mutex_lock(&mutex);
> > + if (pthread_mutex_lock(&mutex)) {
> > + const char *msg = "av_log is thread safe, but cannot be called from signal handlers\n";
> > + write (2, msg, strlen(msg));
> > + return;
> > + }
>
> So this is just to catch signal handler usage?
Its the case iam aware of, i do not know if its the only case in
which this will ever be called in the wide world by all the
applications
maybe i should write it more generically but i thought thats the
most likely scenario and other people will understand it even in
other scenarios like interrupt handlers
> Calling pthread
> functions from signal handlers is AFAIK not safe, even if you attempt
> to workaround the fundamental deadlock problems.
this patch doesnt change this, the mutex lock is called from there
before the patch already
>
> I'd say ffmpeg is not responsible for catching basic undefined behavior
> (like calling things that are not signal-safe from signal handlers).
I prefer a error message that tells me what is wrong over a deadock
that i cannot reproduce in gdb (this was actually the case for the
one this lead to this)
also my concern is not about an application directly calling
av_log() from a signal handler but more that it calls some function
that appears safe and that then calls av_log()
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140320/7bb581be/attachment.asc>
More information about the ffmpeg-devel
mailing list