Stephan Bergmann
11ecb45eb9
...which I happened to run into when the breakpad code kicked in due to some crash happening, > src/client/linux/minidump_writer/minidump_writer.cc:721:12: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here > src/client/linux/minidump_writer/minidump_writer.cc:763:14: runtime error: applying non-zero offset to non-null pointer 0x000000200000 produced null pointer > src/client/linux/minidump_writer/minidump_writer.cc:772:64: runtime error: applying non-zero offset 3200848 to null pointer (Unlike the changes in the existing external/breakpad/ubsan.patch, which is only applied when doing sanitizer builds, these changes should be non-controversial and OK to apply always, so they go into a different patch file.) Change-Id: Ib1b3f87ba22f96d5fb93b8fcb9951ddc3c353697 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124245 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Google breakpad crash-reporting library https://chromium.googlesource.com/breakpad/breakpad When this is enabled and soffice.bin crashes, a "mini-dump" file is written as "instdir/crash/*.dmp". There is an UI to upload the mini-dump to a TDF server but of course that only makes sense if the server has symbols available that match the build, which is not the case if you have built LO yourself. If you want to get the backtrace from local mini-dump files: * with Visual Studio: 1. open the *.dmp file from the Visual Studio IDE File->Open->File 2. then click "Debug Native Only" * otherwise: 1. run "make symbols" to extract the debuginfo from the binaries 2. run "workdir/UnpackedTarball/breakpad/src/processor/minidump_stackwalk foo.dmp workdir/symbols"