I'm basically seeking for assistance pin-pointing an issue here with
Firebird 3 SuperServer 32-bit on Windows 10 Prof., as it seems, in the
context of the Trace API. This all is not an issue with Firebird 2.5.
Unfortunately, it is only reproducible in FB TraceManager at the moment.
I haven't been able to reproduce it with e.g. a mix of isql and
fbtracemgr.exe for example.
When starting a trace session with e.g. the following configuration:
and triggering a few monitoring table queries behind the scene in a
particular area of our product, a single thread in firebird.exe starts
to fully utilize a single CPU core. When I start the trace session with
an additional exclude_filter part %MON$%, the problem disappears.
I guess not very helpful, but this is the stack trace of the high CPU
offending thread in firebird.exe according to SysInternals process explorer.