that are needed for the #if HAVE_FEATURE_BREAKPAD case
so that IWYU does not give incorrect warnings
in --disable-breakpad builds
Change-Id: I05a71ac57fc53e02b293e47a56e92f993afd0592
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191909
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Adds last 4 uno commands executed in CrashReport to assist in investigating the crashes
Change-Id: Ib7307ffc62d6d51d52f9d5e7fabefc2eaf858e5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117388
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Adds Active-SfxObject field in CrashReport to assist in investigating the crashes
Change-Id: I08637a66ae95977e7afe4f5dce634b46c928a423
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117318
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Adds a Active-App field in Crash
Report to assist in investigating
the crashes
Change-Id: I30e5f307045b8e5def9986447551f39e70b94edc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116786
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This may be useful when we again will be deciding on how well something
is or isn't supported (such as when we were making SSE2 required
on Windows).
Breakpad already kind of provides this information (as CPU family, model
and stepping), but that appears to be next to useless in practice
(on X86_64 it doesn't even say the CPU vendor).
So send as metadata CPU name, flags (SSE etc.) and system RAM, as these
may be possibly useful information.
Change-Id: I77ed935d78501d49f70e8b9769fab6be79f1db77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109358
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
While debugging tdf#129712 on Windows, I saw this sequence:
1. nullptr was dereferenced (the reason for tdf#129712).
2. ExceptionHandler::HandleException was called (in
workdir/UnpackedTarball/breakpad/src/client/windows/handler/exception_handler.cc).
3. It called ExceptionHandler::WriteMinidumpOnHandlerThread.
4. Minidump was created in ExceptionHandler::ExceptionHandlerThreadMain.
5. Document Recovery dialog was shown in Desktop::Exception (in
desktop/source/app/app.cxx).
6. After closing dialog, _exit() was called in Desktop::Exception.
7. All threads except main were terminated.
8. Another access violation was thrown in the "minimal CRT cleanup".
9. ExceptionHandler::HandleException called again.
10. ExceptionHandler::WriteMinidumpOnHandlerThread hung on WaitForSingleObject
because handler thread that should release the semaphore was terminated
already at step 7.
The process had to be killed manually.
This change destroys the breakpad handler at the start of Desktop::Exception,
which de-registers itself (on Windows it uses SetUnhandledExceptionFilter).
Other than preventing the hang, the rationale also is that keeping the handler
after first minidump creation is wrong: even if the second minidump creation
succeeded, uploading it to crashdump server would give not the actual problem,
but some unrelated stack.
Change-Id: If12d0c7db519693f733b5ab3b8a288cef800a149
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86104
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true"
- when false then the Dump.ini and the dump-file are not written
- when the switch --disable-crashdump is set, then the
switch "CrashDumpEnable" set to "false"
- when the entry "CrashDumpEnable" is missing, in this case is the
default true, too
- the checkbox under Options-General "Send crash reports to ..."
is deactive and shows off (only view, not change the config)
- when set the environment variable "CRASH_DUMP_ENABLE" to any char
then the switch "CrashDumpEnable=false" are overrules with true
and the Dump.ini and dump-file are write
Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19
Reviewed-on: https://gerrit.libreoffice.org/79273
Tested-by: Jenkins
Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
- remove double code
- using of all the methode of the CrashReporter-Class
- all methode only active when crash-dump enable
except the addKeyValue
With this change the handling for the patch
tdf#127711 A runtime-switch for the MiniCrashDump
would be simpler
Change-Id: I339b3b8e06f7fc2cd3c0d34ece112a6fd352913a
Reviewed-on: https://gerrit.libreoffice.org/79272
Tested-by: Jenkins
Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
There was a race condition that the OpenGL code was initialized before
the old report has been uploaded. Therefore the OpenGL setting was
overwritten by the new start and we were not getting the old value.
Now we store any value that wants to be added before the dump.ini is
ready in a temporary map and will write them as soon as we write all the
common information.
This problem was introduced by the dialog requesting permission to
upload the crash report.
Change-Id: I29391a1ff56bac6381218c5a4aefb58c2c03f024
Reviewed-on: https://gerrit.libreoffice.org/31846
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
We can add several additional key value pairs during the execution of
the program that will be used on the server to show more information.
Change-Id: I4102adc15fc821415fa0b997ca7fe0dc4f7abcec
Reviewed-on: https://gerrit.libreoffice.org/22553
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Gabor Kelemen