After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564138 - EINTR not handled in g_io_unix_close (..)
EINTR not handled in g_io_unix_close (..)
Status: RESOLVED DUPLICATE of bug 682819
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-12-11 16:20 UTC by Matthew Bucknall
Modified: 2013-02-03 06:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthew Bucknall 2008-12-11 16:20:34 UTC
Please describe the problem:
g_io_unix_close (..) in giounix.c does not correctly handle the condition where close(..) returns <0 with errno set to EINTR. The function should retry closing the channel's associated resource when this occurs, but instead returns a G_IO_STATUS_ERROR to the caller.

EINTR is correctly handled in g_io_unix_read (..) and g_io_unix_write (..), so should be handled in g_io_unix_close for consistent behavior.


Steps to reproduce:
1. Send SIGINT to application at the same time close (..) is called inside g_io_unix_close (..)
2. 
3. 


Actual results:
g_io_unix_close (..) returns G_IO_STATUS_ERROR.

Expected results:
g_io_unix_close (..) should retry closing its associated resource until it succeeds or another type of error occurs.

Does this happen every time?
Yes

Other information:
The bug was originally noticed in glib-2.16.5 and is still present in svn head.
Comment 1 Matthias Clasen 2013-02-03 06:08:40 UTC
according to comments in bug 682819, it is not advisable to retry an interrupted close close()

*** This bug has been marked as a duplicate of bug 682819 ***