According to https://gitlab.kitware.com/cmake/cmake/-/issues/20610 "CMake currently hard-codes default /GR /EHsc flags."
And this is how to change flags according to https://gitlab.kitware.com/cmake/cmake/-/issues/19084 string(REGEX REPLACE " /EHsc" " /EHs" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") With above change and a rebuild the issue seems to be gone. So why was the issue confined to SysFileTree? Is /EHs allowing us to use ThrowExceptionX in external C code? Or does it allow using throw / catch blocks in such external code? Just for documentation - these are current CMake defaults for MSVC (we're changing /MD to /MT everywhere and now also change /EHsc to /EHs for CMAKE_CXX_FLAGS) -- CMAKE_CXX_FLAGS /DWIN32 /D_WINDOWS /W3 /GR /EHsc -- CMAKE_CXX_FLAGS_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -- CMAKE_CXX_FLAGS_RELEASE /MD /O2 /Ob2 /DNDEBUG -- CMAKE_C_FLAGS /DWIN32 /D_WINDOWS /W3 -- CMAKE_C_FLAGS_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -- CMAKE_C_FLAGS_RELEASE /MD /O2 /Ob2 /DNDEBUG On Fri, Nov 20, 2020 at 3:43 PM Rick McGuire <object.r...@gmail.com> wrote: > Ok, I tried an experiment, and I believe I found the root cause of the > problem. It appears that CMake is using the compiler option /Ehc, which > assumes that C extern functions will never throw an exception. Since > ThrowExceptionC is declared as an extern C function, the compiler is not > generating any code for exception handling, causing the problem. The fix is > to figure out how to change the compiler options getting used. > > Rick > > On Fri, Nov 20, 2020 at 9:21 AM Rick McGuire <object.r...@gmail.com> > wrote: > >> A deeper dive. This definitely looks like a bug in the Windows >> throw/catch handling. After the exception is thrown, I see ApiContext >> destructors running for two API calls from the StemHanderl destructor, but >> never see the destructor for the ThrowException2 stack frame getting >> called. This leaves the semaphore in a bad state. >> >> Rick >> >> On Fri, Nov 20, 2020 at 9:12 AM Rick McGuire <object.r...@gmail.com> >> wrote: >> >>> I think I figured it out. After the exception is thrown, the destructor >>> for the StemHandler variable gets invoked, which ends up making a call to >>> several APIs while in the state where the kernel semaphore is held. This >>> acquires, and then releases the semaphore, which has the effect that the >>> ApiContext ends up not releasing the semaphore when invoked because it >>> doesn't believe it is holding it. This looks like a Windows bug or compiler >>> bug to me, because the destructors are getting invoked out of order. That >>> is, the StemHandler destructor appears to be invoked BEFORE the ApiContext >>> one for the ThrowException2() call. We may need to continue to rely on >>> using the RaiseExceptionX calls. >>> >>> Rick >>> >>> On Fri, Nov 20, 2020 at 9:03 AM Erich Steinböck < >>> erich.steinbo...@gmail.com> wrote: >>> >>>> This is Windows-only. >>>> But it also seems to be SysFileTree-specific - see below code sample. >>>> >>>> ~~~ >>>> i = 1 >>>> start: >>>> signal on syntax >>>> select case i >>>> when 1 then call SysGetKey "z" >>>> when 2 then call SysSearchPath "PATH", "%", "z" >>>> when 3 then call SysFileSearch "%", "%", f., "z" >>>> when 4 then call SysFileTree "%", f., "z" >>>> when 5 then call SysFileTree "", f. >>>> otherwise exit >>>> end >>>> say "no SYNTAX" >>>> syntax: >>>> signal off syntax >>>> say condition("object")~code condition("object")~message >>>> i += 1 >>>> >>>> m = ""~start("LENGTH") >>>> r = m~result >>>> signal start >>>> ~~~ >>>> >>>> On Fri, Nov 20, 2020 at 1:08 PM Rick McGuire <object.r...@gmail.com> >>>> wrote: >>>> >>>>> I suspected it would. I'm not sure what's going on here. The >>>>> destructor for ApiContext in the ThrowException2 stub is supposed to >>>>> release the kernel semaphore when an exception is thrown, then when the >>>>> exception is caught in NativeActivation, the semaphore is reacquired. >>>>> Somehow, the semaphore is ending up as a nested request, such that the >>>>> main >>>>> thread ends up holding on to it forever. I've traced this process in the >>>>> debugger, and everything is happening as suspected, but somehow the mutex >>>>> is still messed up. Does this fail on any other platforms, or is it just a >>>>> Windows problem? >>>>> >>>>> Rick >>>>> >>>>> On Fri, Nov 20, 2020 at 5:58 AM Erich Steinböck < >>>>> erich.steinbo...@gmail.com> wrote: >>>>> >>>>>> Replacing ThrowException2 with RaiseException2 in >>>>>> nullStringException() in RexxUtilCommon.hpp makes this piece of code work >>>>>> again. >>>>>> >>>>>> On Fri, Nov 20, 2020 at 10:34 AM Erich Steinböck < >>>>>> erich.steinbo...@gmail.com> wrote: >>>>>> >>>>>>> isolate the problem to a single test >>>>>>>> >>>>>>> OK, this piece of code reproduces the hang - both on 32- and 64-bit >>>>>>> Windows >>>>>>> >>>>>>> ~~~ >>>>>>> signal on syntax >>>>>>> call SysFileTree "", f. >>>>>>> syntax: >>>>>>> >>>>>>> m = ""~start("HELLO") >>>>>>> r = m~result >>>>>>> ~~~ >>>>>>> >>>>>>> _______________________________________________ >>>>>> Oorexx-devel mailing list >>>>>> Oorexx-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>>> >>>>> _______________________________________________ >>>>> Oorexx-devel mailing list >>>>> Oorexx-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> Oorexx-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>> _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
