cmake traps

[lerdmann]

Using cmake package 3.20.6-3. Whenever I run cmake, it traps but nonetheless it finishes.

Attaching the POPUPLOG.OS2 entry:

`07-05-2023 08:17:51 SYS3170 PID 0049 TID 0001 Slot 0092 C:\USR\BIN\CMAKE.EXE c0010001 1ffde411 EAX=00000000 EBX=000008dc ECX=0086fd4c EDX=00000003 ESI=2004c480 EDI=0000000c
DS=0053 DSACC=d0f3 DSLIM=3fffffff
ES=0053 ESACC=d0f3 ESLIM=3fffffff
FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC= GSLIM=**** CS:EIP=005b:1f9595a1 CSACC=d0df CSLIM=3fffffff SS:ESP=0053:0086fc98 SSACC=d0f3 SSLIM=3fffffff EBP=0086fcb0 FLG=00010202

DOSCALL1.DLL 0003:0000e411`

[lerdmann]

Digging into it: Exception Code c0010001 means XCPT_PROCESS_TERMINATE and is triggered by a thread calling DosExit to either end itself (DosExit(EXIT_TRHEAD)) or the whole process (DosExit(EXIT_PROCESS)). I suspect that DosExit is called explicitely (or through some intermediate function call) but should not, because normally, the RTL should handle thread and process termination completely on its own.

This might also point to the problem in case cmake.exe starts multiple threads: https://bz.apache.org/ooo/show_bug.cgi?id=123001#c1

[StevenLevine]

A bit of background. The only normal way to terminate a process is via DosExit. We will ignore terminations caused by traps and such because that it not relevant to this issue. DosExit can called directly be called the application or will be called by the runtime if main returns.

When DosExit is issued, XCPT_PROCESS_TERMINATE is sent to the thread that called DosExit and XCPT_ASYNC_PROCESS_TERMINATE is sent to every other thread.

Note, that if exceptq is loaded and sees one of these exceptions, it passes it on to the next exception handler, unless requested to report them. See the Z and ZZ options. These options are used to track down so called "silent exits."

Normally, exception handlers return XCPT_CONTINUE_EXECUTION for these exceptions and they never show up on popuplog.os2. When a popuplog entry appears, it indicates that something is not quite right with the exception handlers. In the past, I've needed to use a process dump to track down the cause of this kind on spurious popuplog entry.

The popuplog entry is harmless in the sense that it has no other effect on exit processing. The process is already exiting and this will continue until the process terminates or gets stuck in the exit list.

[lerdmann]

I tried EXCEPTQ=ZZ and EXCEPTQ=Z but that will hang the whole system when I run cmake.exe. How do I create a process dump ? I tried the "procdump" tool and specified CMAKE as the process name but that did not work out.

[lerdmann]

I now tried EXCEPTQ=Z3. That fixes the hang but POPUPOS2.LOG is still being written to. But I cannot find the log file. It is not in the var\log\app directory. Where do I find it ?

[StevenLevine]

The is the first I've heard of this behavior for EXCEPTQ=ZZ. Since it's a bit OT for this ticket, email me if you want to work on it.

I'm biased to using my pdumpctl (http://www.warpcave.com/betas/PDumpCtl-0.18-20230608.zip), There is an older version at http://www.warpcave.com/os2diags/PDumpCtl-0.17-20210620.zip.

I recommend you configure for a full dump with

pdumpctl n f cmake

Run cmake with

cmake

and see if the resulting dump file contain sufficient data. To turn off the facility, it's

pdumpctl o

You can run pdumpctl interactively with

pdumpctl -i cmake

Depending on your system you might need to point pdumpctl at a dump file directory.

[StevenLevine]

Only exceptq reports generated by the kLIBC exception handler will end up in \var\log\app. Anything else will end up in the current directory with the legacy .trp file naming.

[dmik]

It's worth to clarify that any app linked to kLIBC will trap to /var/log/app unless it installs its own exception handler on top of kLIBC's one.