libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] unw_set_cache_size and per-thread caches


From: Milian Wolff
Subject: Re: [Libunwind-devel] unw_set_cache_size and per-thread caches
Date: Fri, 04 May 2018 23:10:37 +0200

On Freitag, 4. Mai 2018 22:27:00 CEST Bert Wesarg wrote:
> Milian,
> 
> On Fri, May 4, 2018 at 10:21 PM, Milian Wolff <address@hidden> wrote:
> > Hey Bert, others.
> > 
> > I notice that unw_set_cache_size is disabled / always fails when libunwind
> > is> 
> > compiled with --enable-per-thread-cache:
> >   /* Currently not supported for per-thread cache due to memory leak */
> >   /* A pthread-key destructor would work, but is not signal safe */
> > 
> > #if defined(HAVE___THREAD) && HAVE___THREAD
> > 
> >   return -1;
> > 
> > #endif
> > 
> > Can you, or someone else, give me some more information on the reasoning
> > here?
> > 
> > I'm especially surprised, since I personally would never consider
> > unw_set_cache_size to be called from a signal. I am probably
> > misunderstanding something here?
> 
> its not about /setting/ the cache size, its about thread termination.
> Changing the cache size allocates memory for the cache (the default
> cache size is inside the cache variable itself. Thus this extra
> allocated memory needs to be released if the thread terminates. And
> the suggestion from Dave was to use a pthread-key destructor.

OK, and ASAN won't report a leak, since the memory is allocated via mmap. Now 
I understand.

Since "signal safety" is the apparent reason for why this isn't supported, 
similar to the other thread about tls_model("initial-exec"), I wonder:

Is libunwind ever signal safe when it's compiled with per-thread-caches? If 
that is not the case, we could just add the pthread-key destructor.

If on the other hand, __thread is actually (currently) thread safe, then I 
propose we add another configuration option to libunwind, which will basically 
remove the signal safety guarantees and enable us to remove the tls_model and 
set custom cache sizes.

Cheers

-- 
Milian Wolff
address@hidden
http://milianw.de

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]