[#835] [V70001] [GTM-9410] Fix longstanding spinloop in GDE error trap exposed by v70001/gtm9410 subtest
-
While implementing YDBTest!1814 (merged) (YDBTest@c6eec83e), I tested a use case where multiple GDE processes are invoked and try to modify the mumps.gld file at the same time. In some test runs, I noticed that the GDE processes were in a spin loop and never exiting.
-
Turns out they were trying to
CLOSE
the filemumps.gldinprogress
. And encountering a%SYSTEM-E-ENO2
error because that file did not exist (due to a concurrent GDE process removing it). -
The error trap in
sr_unix/gdeput.m
set up a device exception handler (gdexcept
variable) when opening the devicetempfile
. But thewriteerr
entryref (which is whatgdexcept
invokes) did not take into account thattempfile
could not exist. And because of this, theCLOSE
command would encounter a runtime error that in turn would go back to the device exception handler which in turn would invokewriteerr^%GDEPUT
and encounter the very same error again and so on. -
The fix is simple and is to check if the file
tempfile
exists (using$zsearch
) and only in that case invoke theCLOSE
command. This avoids the indefinite device exception handler invocation.