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

Re: libc recently more aggressive about pthread locks in stable ?



On Mon, Nov 14, 2016 at 10:31:18AM +0100, Gert Wollny wrote:
> Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes
> Holschuh:
> > 
> > 
> > 
> > Unfortunately, when hardware lock elision support was added to glibc
> > upstream, libpthreads was *not* changed to properly assert() this
> > forbidden condition on the non-hardware-elision codepaths.  Such an
> > assert() would have given us consistent behavior, thus flushing the
> > bugs out in the open... at the cost of a performance hit (I have no
> > idea how severe), and much screaming.
> 
> An alternative to find problems with (un-)locking should be to compile
> the program in question with -fsanitize=thread (on amd64) and run it.
> 
> Unfortunately, in current unstable with thread sanitizer one might get
> #796246 (at least I had this).

Does "-fsanitize=thread -no-pie" work for you?

> Best, 
> Gert 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply to: