Fixes#5166.
This introduces versioned management of sentry.dll for Keyman for
Windows, Keyman Engine and Keyman Developer. As sentry.dll's ABI is not
backwardly compatible, we have to maintain independent copies of each
DLL for each app.
sentry.dll (or sentry.x64.dll for x64 apps) will be found in the
sentry-0.4.9 folder relative to the running process, except when running
from within the keyman repo tree (based on presence of KEYMAN_ROOT env
var). In those cases, the windows/src/ext/sentry sentry.dll will be
used, allowing us to test new debug time sentry DLLs easily.
A little bit of cleanup and consolidation was also done in the
KeymanPaths.pas unit.
Fixes#4607.
The Sentry 0.4.9 update actually simplifies some things. It does only
build with VS2019 by default, which pushed me to update Keyman build to
the same version, but that's a good thing overall, and was fairly
painless anyway.
Previously, we had our own custom build of sentry-native to make sure
that the C++ runtime libraries were statically linked to sentry.dll, but
this is now configurable in the build options, so we were able to
abandon our fork of the project at
https://github.com/keymanapp/sentry-native, which is good news. (I will
leave the fork there just in case but we'll eventually delete it once we
are convinced that this is robust.)
I have updated sentry.pas to match sentry.h; most of the changes are in
comments but there are a handful of new functions and some small changes
to function signatures.
I retested the Sentry exception scenarios and results can be found at
https://docs.google.com/spreadsheets/d/19xfurbn4cGubSCD68EGuKhcR5HrjaUcY/edit#gid=170604584
There may be an issue with Delphi x64 programs missing symbols from my
machine; something to keep an eye on but not a blocker for this merging,
I think.
Some of our Sentry reports are difficult to track down. Adding user
interaction breadcrumbs to Keyman Configuration (to start with) may
simplify this. I may add more breadcrumbs to other projects now that
this is available.
Under WINE, on macOS at least, TSentryClient is crashing at
startup, e.g. when calling SymInitialise. In order to have a
working kmcomp.exe on macOS/Linux, we'll just disable Sentry
altogether for now.
We used the 'Started' event when testing Sentry integration. We no
longer need it, but I left it in as commented code so we can re-enable
if/when we do Sentry updates in the future and need to re-test.
Fixes#3797.
Fixes KEYMAN-WINDOWS-5H.
Report unexpected errors creating or deleting scheduled task, and ignore
expected errors better, handling a potential race condition where two
processes both attempt to create a folder at the same time.
Note that creating the task should not be a race because we use the
`TASK_CREATE_OR_UPDATE` flag.
kmshell had no application.title set and this gave incorrect
results for crash report dialog.
kmbrowserhost was acting as a VCL app but it isn't, and the
sentry integration was pulling in all the VCL dependencies which
was a bad outcome. This removes those and handles crashes as a
non-VCL app.
Moves all version construction to use VERSION.md and
TIER.md and reduces intermediate file usage, so we can
present sensible versions across the project.
Updates Delphi projects to use Sentry API instead of legacy
reporting mechanisms, and strips out existing text-based
reports. Not yet complete: reporting from kmcomapi and
hosted web controls, release number. These are flagged
as build hints.
First stage of Sentry integration. Adds a basic library
for handling errors through Sentry. Does not include
integration into external handler or Keyman apps as yet.
