https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104767
Bug ID: 104767
Summary: GNAT.Serial_Communications windows package
allows/causes multiple closing of the same windows
handle.
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: tornenvi at gmail dot com
Target Milestone: ---
Created attachment 52554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52554=edit
Patch to set handle to -1 on close.
There is an error in the GNAT Ada package GNAT.Serial_Communications, as
implemented in the
file
gcc/ada/libgnat/g-sercom__mingw.adb
in the gcc git sources. Which is ultimately installed as
10.3.1\adainclude\g-sercom.adb
on an windows installation.
This package does not correctly clean up the Port.H handle in the
Close procedure. The end result is that when Connect (or Close) is
called for a second time it will silently close the previous window
handle again.
If the previous windows handle has been reassigned (this happens often under
windows 10 at least)
then whatever other random device,interface, file I/O will fail when
its handle is unexpectedly closed. This situation can be very difficult to
identify. I Also believe that the Ada implementation may use windows handles
to implement its task system, so this bug can lead to unexpected application
crashes.
The issue was detected in V10.3.1 of GCC but appears to be in the current HEAD
commit
ea4911c4fa629a97d22b6e48975d8f1c4e04549d
The attached patch implements the fix.
Note that this error appears to have been introduced when it was changed to
allow for some changes for the Linux implementation in commit
55d4e2ba076049f88c24011f2f63aa226e6c87a0
Importantly the Linux implementation does not appear to have the same fault,
since it does not attempt to silently Close the serial port on Connect. So the
two implementations are different in behavior.
I would suggest that the package be changed to raise an exception in the
Connect function if the handle is not '-1' instead of silently closing the
handle, but such a change does break backwards compatibility.