Threadnames aren't set for crashpad threads (SetThreadDescription), and our threads don't have names.

[alecazam]

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.

[alecazam]

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.

https://bugs.chromium.org/p/crashpad/issues/detail?id=327

[alecazam]

Also naming of the process threads, or any threads created by crashpad. And does this crash process really need 6 threads?

[konraddysput]

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?

[alecazam]

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?

[gm4sl]

@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.

[alecazam]

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

[alecazam]

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/

[alecazam]

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.

pragma comment( lib, "crashpad_base.lib" )

pragma comment( lib, "crashpad_client.lib" )

pragma comment( lib, "crashpad_common.lib" )

pragma comment( lib, "crashpad_util.lib" )

[gm4sl]

Thanks @alecazam.

• using the "Visual Studio 16 2019" generator builds a solution containing both Debug/Release configurations but I completely agree with you, there should be better instructions for building the different configurations from the command-line
• as you found, the output directory structure, with binaries scattered in various directories, makes it really hard to create a distribution for use in a project; this will definitely need to be addressed
• documentation of usage needs to be improved, some of which will fall out of properly placing binaries in a well-defined location
• the Visual Studio extension should be updated to pull the latest binaries

Appreciate your patience with this!

[alecazam]

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

[alecazam]

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>")

[alecazam]

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.