On Fri, May 30, 2003 at 08:16:41PM +0300, Ruslan Ermilov wrote:
> On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote:
> > On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
> > > We had a bug in our threaded application that would mistakenly close
> > > the descriptor 0, and
On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote:
> On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
> > We had a bug in our threaded application that would mistakenly close
> > the descriptor 0, and this triggers a bug in libc_r which I will try
> > to describe below.
>
On Fri, 30 May 2003, Enache Adrian wrote:
> On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
> > We had a bug in our threaded application that would mistakenly close
> > the descriptor 0, and this triggers a bug in libc_r which I will try
> > to describe below.
> ...
> > Some import
On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
> We had a bug in our threaded application that would mistakenly close
> the descriptor 0, and this triggers a bug in libc_r which I will try
> to describe below.
...
> Some important notes: this bug is only applicable to descriptors
>
Hi!
We had a bug in our threaded application that would mistakenly close
the descriptor 0, and this triggers a bug in libc_r which I will try
to describe below.
The bug (in libc_r only, libpthread^Wlibkse is unaffected) causes a
threaded application to stuck in accept(2). libc_r makes every new
5 matches
Mail list logo