This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
problems with Asynchronous I/O and glibc-2.1.2 - FW: [Fwd: IPC and glibc?]
- To: <libc-alpha at sourceware dot cygnus dot com>
- Subject: problems with Asynchronous I/O and glibc-2.1.2 - FW: [Fwd: IPC and glibc?]
- From: "Lawrence Chen, P.Eng." <lchen at opentext dot com>
- Date: Mon, 15 Nov 1999 11:59:14 -0500
- Disposition-Notification-To: "Lawrence Chen, P.Eng." <lchen@opentext.com>
- Reply-To: <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