Closed alecazam closed 1 year ago
Sounds like thread names were added a year ago to Google's Crashpad, so is there a plane to update this fork. The only updates I see on the fork were 8-12 months ago.
Also naming of the process threads, or any threads created by crashpad. And does this crash process really need 6 threads?
Hi @alecazam
This is crashpas fork. We do follow everything in what crashpas does with slight modifications and build improvements. We do support streams where crashpad writes this information. Can you show me your code and what you see in Backtrace?
Here's what our thread list looks like in the web tool. These are the functions the thread is stopped at, and not the name. Is there some call where we need to register the names?
@alecazam Can you please confirm you are using the "backtrace" branch of the repository? The "master" branch does not contain the same enhancements and upstream crashpad code.
We are using the crashpad that gets downloaded from the Visual Studio extension. So not building from sources. This looks pretty ancient. I also don't see any prebuilt libs here, so is this something we need to build ourselves?
crashpad-2021-07-16-release-x64-fd70c47fc249659db8a7345b00026b14a3963d6d
Seems like if there are only 2 year old pre-built libs, then there should be instructions on how to build the libs from source. But the default CMake seems to only build Debug. I've tried the CMake settings I use on my own projects, and they don't apply to Backtrace crashpad.
Generating Code... zlib.vcxproj -> C:\devref\crashpad\cbuild\third_party\zlib\Debug\zlib.lib
Generating Code... compat.vcxproj -> C:\devref\crashpad\cbuild\compat\compat.dir\Debug\compat.lib
This doesn't work. cmake -S . -B cbuild/ -D CMAKE_BUILD_TYPE=Release cmake --build cbuild/
This doesn't work cmake -S . -B cbuild/ --config Release cmake --build cbuild/
I was able to build a series of Release libs from the Visual Studio project. They are scattered all over the various directories. Don't really know which ones that I need to load. util and client seem to be the only ones in common with those older libs. No real instructions on this either.
2>mini_chromium.vcxproj -> c:\devref\crashpad\cbuild\third_party\mini_chromium\mini_chromium.dir\Release\mini_chromium.lib 3>zlib.vcxproj -> C:\devref\crashpad\cbuild\third_party\zlib\Release\zlib.lib 4>crashpad_getopt.vcxproj -> c:\devref\crashpad\cbuild\third_party\getopt\crashpad_getopt.dir\Release\crashpad_getopt.lib 5>util.vcxproj -> c:\devref\crashpad\cbuild\util\util.dir\Release\util.lib 6>compat.vcxproj -> c:\devref\crashpad\cbuild\compat\compat.dir\Release\compat.lib 7>client.vcxproj -> C:\devref\crashpad\cbuild\client\Release\client.lib 8>minidump.vcxproj -> c:\devref\crashpad\cbuild\minidump\minidump.dir\Release\minidump.lib 9>snapshot.vcxproj -> c:\devref\crashpad\cbuild\snapshot\snapshot.dir\Release\snapshot.lib 10>tools.vcxproj -> c:\devref\crashpad\cbuild\tools\tools.dir\Release\tools.lib 11>handler.vcxproj -> C:\devref\crashpad\cbuild\handler\Release\handler.exe 12>handler_console.vcxproj -> C:\devref\crashpad\cbuild\handler\Release\handler_console.exe
But these are what we currently load out of the VC Extension. So names have changed, and libraries grouped differently.
Thanks @alecazam.
Appreciate your patience with this!
I think the expectation for paid services is that the experience is better than do-it-yourself opensource with no docs. We use Make and not visual studio to build stuff. And the current cmake scripts don't build Release. The docs state that crashpad can be built from the command line, but it only builds Debug. Letting VS handle this isn't the total solution.
I got the build down to 100 header files. I was trying to copy them 1 by 1, but gave up, and started copying whole directories. But it's better than the original 500 headers or so.
I needed the following folders:
client mini_chromium base - files, numerics, strings, synchronization build util - file, misc, numeric, synchronization, win
I don't know how to build against the static runtime versions of the libraries. This all had a working ninja build system from Google, but it now seems to have a non-working CMake system.
Release argument doesn't work to CMake. Pretty sure this is supposed to build against static runtime, but I'm still setting /MD used across all the release builds. We also need exceptions and RTTI disabled. Also we build all our projects across all platforms with clang and not MSVC.
cmake -G "Visual Studio 16 2019" -DSTATIC_RUNTIME=ON ..
9>lld-link : error : /failifmismatch: mismatch detected for 'RuntimeLibrary': 9>>>> libFooReleasewin.lib(Foot.o) has value MT_StaticRelease 9>>>> crashpad_client.lib(crashpad_client_win.obj) has value MD_DynamicRelease
I had to mod the ALL_BUILD CMakeList.txt file. So I have this compiling and linking to our project (still not build with clang-ci, but there is a CMake setting for that).
cmake_minimum_required(VERSION 3.15)
project(backtrace_crashpad LANGUAGES C CXX)
cmake_policy(SET CMP0077 NEW)
# add these lines, and switched to CMake 3.15
cmake_policy(SET CMP0091 NEW)
# this is default
# set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>DLL")
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
For some reason, our Main and fmod threads don't have names, despite us setting them. I'll see if SetThreadDescription is called for all of these, but it's odd that some are missing and some are not.
This was on our end. fmod was only setting thread via old SEH which doesn't have getters, and our main thread was unnamed. So now have full thread names.
We set thread names on our own threads via SetThreadDescription, but I don't see names in any of the crashpad code. And when we set thread names, they don't appear in backtrace crash reports.