problems with Asynchronous I/O and glibc-2.1.2 - FW: [Fwd: IPC and glibc?]

["Lawrence Chen, P.Eng." <lchen at opentext dot com>]

I'm having a problem with Asynchronous I/O and glibc-2.1.2.

The application I'm porting used to work with glibc-2.1.1 (except that I had to
code around the fact that aio_read and aio_write gave the wrong return values).

I later built the application with an early release of glibc-2.1.2, which
solved a problem I was having with ecvt() and things continued to work.

But, in later early versions of glibc-2.1.2 and the released version of
glibc-2.1.2, asynchronous I/O wouldn't work.

At first I was looking in the wrong area for the problem, because it showed up
later in the application run....but after adding lots of printf's to the code,
I found that the application hangs on the first call to asynchronous I/O
(specifically aio_write()), because the function call never returns.

Attaching to my process with gdb and tracing through the aio_* calls, it
appears to hang in pthread_create().

Now using a test program that pretty much only uses aio_write(), I was unable
to reproduce the problem....so I would guess that its an interaction issue at
some other level.  Since the application has a multitude of signal handlers,
that might be one possibility....since it had tripped me up in the past with
Asynchronous I/O on Linux.  Has anything changed in this area?  Or is there
some other obvious thing I might look into?

Below is the tail of a thread from USENET.

-----Original Message-----
From: Lawrence K. Chen, P.Eng. [mailto:lchen@opentext.com]
Sent: Friday, November 12, 1999 1601
To: undisclosed-recipients:;
Subject: [Fwd: IPC and glibc?]




Andreas Jaeger wrote:
>
> >>>>> Lawrence K Chen, P Eng writes:
>
>  > Well, I attached to my process with gdb...and it seems to get stuck in
>  > pthread_create (can't see the details of that...don't really know what
goes on
>  > in there to even guess).
>
>  > Sounds like something changed in signal handling?  I'm not using signal
> See the ChangeLog entry.
>  > notification in my AIO (the application has a list of AIO requests and
uses
>  > aio_suspend/aio_error to wait/check for requests to complete).  So, I
don't
>  > think this affects the problem I'm having.
>
>  > So, I my gut is to point at pthread as the problem....but I haven't any
idea
>  > on where I might start to look if I was going to try solve this problem
from
>  > one end or the other.
>
> I'm not familiar with the code.  Could you send a proper report of
> your problem to libc-alpha@sourceware.cygnus.com?  Perhaps somebody
> else can help.  comp.os.linux.development.system does not seem to be
> the right place for this.
>
>  > I forget the exact details, but ecvt calls snprintf....snprintf had been
fixed
>  > to follow the standard in its error return.  But, ecvt hadn't been updated
so
>  > it was looking for the 'old' failure return....so when snprintf failed, it
>  > would write past the end of an array.  I had used efence to track that one
>  > down.
> Please report such kinds of bugs directly to us with the glibcbug
> script or to one of the glibc mailing lists.  Looking at the code, I
> saw the bug directly but I would have preferred if you told us before.
>
> Thanks,
> Andreas
> --
>  Andreas Jaeger
>   SuSE Labs aj@suse.de
>    private aj@arthur.rhein-neckar.de

--
    Who: Lawrence Chen, P.Eng.          Email: lchen@opentext.com
   What: Software Developer               URL: http://www.opentext.com/basis
  Where: Open Text, BASIS Division      Phone: 614-761-7449
         5080 Tuttle Crossing Blvd.       Fax: 614-761-7269
         Dublin, OH  43016                ICQ: 12129673
  DISCLAIMER: All opinions expressed are mine and *NOT* my employers