#1662 closed defect (fixed)

termios.c: semaphore not deleted, consequently resulting in failure of rtems_termios_open

Reported by: Bharath Suri Owned by: Chris Johns
Priority: normal Milestone: 5.1
Component: fs Version: 4.11
Severity: normal Keywords:
Cc: joel.sherrill@…, sebastian.huber@… Blocked By:
Blocking:

Description (last modified by Gedare Bloom)

The semaphore osem is still in use in rtems_termios_close while an attempt to delete it is made and hence is not deleted.
Consequently, it results in a RTEMS_TOO_MANY on rtems_semaphore_create, which further results in failure of rtems_termios_open.

Attachments (3)

libcsupport-changes.diff (511 bytes) - added by Bharath Suri on Aug 9, 2010 at 6:00:52 PM.
Patch @ cpukit/libcsupport
cpukit-ChangeLog-changes.txt (173 bytes) - added by Bharath Suri on Aug 9, 2010 at 6:01:32 PM.
Updated ChangeLog? @ cpukit/
termios01-init-changes.diff (1021 bytes) - added by Bharath Suri on Aug 10, 2010 at 6:09:00 PM.
Patch to testsuites/libtests/termios01/init.c

Download all attachments as: .zip

Change History (15)

Changed on Aug 9, 2010 at 6:00:52 PM by Bharath Suri

Attachment: libcsupport-changes.diff added

Patch @ cpukit/libcsupport

Changed on Aug 9, 2010 at 6:01:32 PM by Bharath Suri

Updated ChangeLog? @ cpukit/

comment:1 Changed on Aug 9, 2010 at 6:19:10 PM by Joel Sherrill

Cc: Joel Sherrill added

comment:2 Changed on Aug 10, 2010 at 4:57:32 PM by Joel Sherrill

Cc: Sebastian Huber added

Changed on Aug 10, 2010 at 6:09:00 PM by Bharath Suri

Attachment: termios01-init-changes.diff added

Patch to testsuites/libtests/termios01/init.c

comment:3 Changed on Aug 10, 2010 at 6:17:07 PM by Bharath Suri

blocked: 1661

comment:4 Changed on Aug 11, 2010 at 1:25:13 AM by Bharath Suri

Resolution: fixed
Status: newclosed

comment:5 Changed on Aug 11, 2010 at 2:47:07 PM by Sebastian Huber

Resolution: fixed
Status: closedreopened

comment:6 Changed on Aug 12, 2010 at 6:36:21 AM by Sebastian Huber

Let me explain the problem with the clean up during the last close. The Termios driver is an example for a driver that will be opened by one thread, but the read and write access may be issued by different threads concurrently. The close may happen also concurrently (exit() may be called concurrently?). I think a concurrent call to close() will lead to more problems, so I omit this here. I think currently that the only way to avoid accesses to deleted resources is to not delete anything during the last close. Instead we should simply flush the output buffer.

comment:7 Changed on Nov 24, 2014 at 6:58:28 PM by Gedare Bloom

Version: HEAD4.11

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

comment:8 Changed on Dec 19, 2014 at 3:53:23 AM by Gedare Bloom

Description: modified (diff)
Milestone: 4.114.11.1

comment:9 Changed on Jan 26, 2017 at 7:16:00 AM by Sebastian Huber

Milestone: 4.11.14.11.2

comment:10 Changed on Mar 23, 2017 at 1:03:28 AM by Chris Johns

Milestone: 4.11.24.11.3

The 4.11.2 milestone is closing.

comment:11 Changed on Feb 5, 2018 at 5:55:12 AM by Chris Johns

What should happen with this ticket?

comment:12 Changed on Feb 5, 2018 at 7:53:24 AM by Sebastian Huber

Milestone: 4.11.35.1
Resolution: fixed
Status: reopenedclosed

Due to the reference counting of file descriptors (#3132) this problem no longer exists in RTEMS 5.1. If you close() a file descriptor which is still in use, you get an error (EBUSY).

Note: See TracTickets for help on using tickets.