Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
[Henrique de Moraes Holschuh] > And what should we do about Debian stretch, then? I believe a good start would be to add an assert() in a test version of glibc and then run all the autopkgtest scripts on the packages in the archive to see how widespread the problem is. It will not cover all packages, but at least a significant portion of the archive. I suspect we are too close to the Stretch freeze to try to modify all the packages affected by the problem, and if so we should probably disable the more strict code for Stretch too, and make it an RC issue in unstable after the freeze in February. A problem is that it will be hard to test all the packages in time, as such locking issue might not trigger on every run. Is there already, or can you create, a wiki page to collect the details on this problem? You seem to have more grasp of the issue than me, otherwise I would have started one myself. I assume other distributions are affected too. What are they doing to handle it? -- Happy hacking Petter Reinholdtsen
Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
[Jeff Epler] > I believe that similar bugs have been afflicting hurd and kfreebsd > debian ports for some time. In retrospect, it's too bad these reports > weren't given more attention, because it could have made things better > for Linux platforms as well. :-/ Yeah, too bad. :/ On the other hand, it make me glad to have yet another example of the value of the less popular architectures. :) Does this mean that running the autopkgtest scripts on hurd or kfreebsd would expose these problems? Do we have any idea how widespread the problem is? -- Happy hacking Petter Reinholdtsen
Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > And what should we do about Debian stretch, then? > > I believe a good start would be to add an assert() in a test version of > glibc and then run all the autopkgtest scripts on the packages in the > archive to see how widespread the problem is. It will not cover all > packages, but at least a significant portion of the archive. > > I suspect we are too close to the Stretch freeze to try to modify all > the packages affected by the problem, >... This discussion sounds as if all this would be future hardware, but hardware with working (and not disabled) TSX is available in nearly every computer shop in the world for over a year now (the first fixed Intel CPUs were released in 2014). Please don't make it sound as if TSX would be a huge problem for stretch - it is not. Every nontrivial piece of software has bugs. If anyone wants to search specifically for this class of bugs that is appreciated, just like searching for any other class of bugs is appreciated. Running stretch on hardware with TSX available and enabled is working fine for many users for quite some time now. 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
