Re: race condition destroying condition variables

Brent W. Baccala, on mer. 27 déc. 2017 15:07:51 -0500, wrote: > On Wed, Dec 27, 2017 at 2:31 PM, Samuel Thibault <[1]samuel.thiba...@gnu.org> > wrote: > > Ok, so even if Posix explicitly says that it has undefined behavior, > since nptl behaves fine we should probably behave fine too. >

Re: race condition destroying condition variables

On Wed, Dec 27, 2017 at 2:31 PM, Samuel Thibault wrote: > Hello, > > Brent W. Baccala, on mar. 26 déc. 2017 23:06:13 -0500, wrote: > > Also, the Linux source code in nptl/ includes the following comment: > > > > /* If there are waiters which have been already signalled

Re: race condition destroying condition variables

Hello, Brent W. Baccala, on mar. 26 déc. 2017 23:06:13 -0500, wrote: > Also, the Linux source code in nptl/ includes the following comment: > >   /* If there are waiters which have been already signalled or >      broadcasted, but still are using the pthread_cond_t structure, >      

Re: race condition destroying condition variables

Well, I've tried both Samuel's (swap space) and Svante's (nocheck) suggestions and have found that both allow me to successfully build the glibc packages! The problem that I've got now is that I've changed the size of the condition variables by adding an extra field, an integer that tracks the

Re: race condition destroying condition variables

Svante Signell, on jeu. 21 déc. 2017 23:58:20 +0100, wrote: > On Thu, 2017-12-21 at 17:32 -0500, Brent W. Baccala wrote: > > Well, I've got a patch that might work, but I'm having a lot of > > trouble testing it. > > > > I can't dpkg-buildpackage the Debian glibc package. > > > > It gets into

Re: race condition destroying condition variables

On Thu, 2017-12-21 at 17:32 -0500, Brent W. Baccala wrote: > Well, I've got a patch that might work, but I'm having a lot of > trouble testing it. > > I can't dpkg-buildpackage the Debian glibc package. > > It gets into the test routines, then a bunch of the math tests crash > with SIGSEGVs and

Re: race condition destroying condition variables

Well, I've got a patch that might work, but I'm having a lot of trouble testing it. I can't dpkg-buildpackage the Debian glibc package. It gets into the test routines, then a bunch of the math tests crash with SIGSEGVs and SIGILLs, then I get a bunch of kernel errors: no more room in ee26a908

Re: race condition destroying condition variables

On Tue, Dec 19, 2017 at 3:25 AM, Samuel Thibault wrote: > Brent W. Baccala, on mar. 19 déc. 2017 00:08:44 -0500, wrote: > > Looks like there's a race condition when we destroy a condition > variable. My > > understanding of the expected behavior is that once all the

Re: race condition destroying condition variables

On Tue, Dec 19, 2017 at 09:25:16AM +0100, Samuel Thibault wrote: > Brent W. Baccala, on mar. 19 déc. 2017 00:08:44 -0500, wrote: > > Looks like there's a race condition when we destroy a condition variable.  > > My > > understanding of the expected behavior is that once all the threads have > >

Re: race condition destroying condition variables

Brent W. Baccala, on mar. 19 déc. 2017 00:08:44 -0500, wrote: > Looks like there's a race condition when we destroy a condition variable.  My > understanding of the expected behavior is that once all the threads have been > signaled (i.e, pthread_cond_broadcast is called), the condition variable

race condition destroying condition variables

Hi - Looks like there's a race condition when we destroy a condition variable. My understanding of the expected behavior is that once all the threads have been signaled (i.e, pthread_cond_broadcast is called), the condition variable can be safely destroyed with pthread_cond_destroy. The problem