Alexander Bluhm <[email protected]> wrote: > On Fri, Feb 28, 2025 at 05:20:44PM -0300, K R wrote: > > The -T flag stands for: > > > > T The command did a memory access violation detected by a > > processor trap. > > > > Despite this message, the java program runs successfully and > > terminates with an exit code of 0. > > I am pretty sure that this Java process did a memory violation. > But it can catch this with a signal handler and continue execution. > When I designed this T feature my idea was to catch programs that > behave stangely, are buggy, or crash when they are under attack. > > I guess Java virtual machine falls into the stange behavior category. > > > >Fix: > > Unknown. Is this T flag expected from lastcomm(1) for every > > java program? > > We can > 1. ignore and live with it. > 2. do not set T in kernel if signal handler catches the violation. > 3. remove T from the daily mail. It is this regex in /etc/daily > lastcomm -f /var/account/acct.0 | grep -e ' -[A-Z]*[EMPTU]' > 4. or you can turn off accounting.
I would expect a record is only created if termination occurs due to it not being caught. The older ac flags are set upon termination, only. For the new flags ABTCFI and ATRAP it seems we errored and placed the checks in handler-recoverable locations. I think that switch (signum) block should be moved into ptsignal_locked() ... or somewhere else? Or should we move it into sigexit() ?
