crashpad_handler socket transport not working on some Linux systems

[matusfedorko]

Hi,

crashpad_handler on linux silently fails to upload crash reports (tested with Sentry 22.11.0). More specifically it will send the report, but it will get bad request as a response. This can be fixed by using net/http_transport_libcurl.cc instead of the default net/http_transport_socket.cc (see also the patch below).

My dilemma is how to proceed now ? Where should I report this ? Should I report to crashpad devs ? I figured you'd want to know too, so maybe you can patch your fork of crashpad in the meantime.

diff --git a/Sources/External/include/Sentry/external/crashpad/util/CMakeLists.txt b/Sources/External/include/Sentry/external/crashpad/util/CMakeLists.txt
index 4c1d0e6f9..bb29356e4 100644
--- a/Sources/External/include/Sentry/external/crashpad/util/CMakeLists.txt
+++ b/Sources/External/include/Sentry/external/crashpad/util/CMakeLists.txt
@@ -246,7 +246,10 @@ endif()
 
 if(LINUX OR ANDROID)
     target_sources(crashpad_util PRIVATE
-        net/http_transport_socket.cc
+        net/http_transport_libcurl.cc
         linux/address_types.h
         linux/auxiliary_vector.cc
         linux/auxiliary_vector.h

[Swatinem]

Thanks for the report! I believe a libcurl based transport was added at some later point after we adopted the socket transport (which btw needed patching in itself).

As we already depend on libcurl for sentrys own downloader, I believe its fair to extend that dependency to our crashpad fork as well.

[matusfedorko]

Thanks, that would be highly appreciated or at least if there would be an option to choose between socket transport and curl transport, because crashpad is not our direct dependency and due to that we don't have any reasonable way right now to fix the issue on our end without risking the loss of the patch with next sentry update.

[bsergean]

I confirm this is fixed in 0.5.4, tested on linux and mac with the curl transport.

[supervacuus]

@bsergean, I am trying to understand what you mean. The fix wasn't released with 0.5.4.

[bsergean]

Od, I was able to see crashes reported with 0.5.4. Maybe the compilation was still picking up the breakpad compilation ? Is that fix available in a branch for me to test ?

…

On Jan 30, 2023, at 12:34 AM, Mischan Toosarani-Hausberger ***@***.***> wrote: @bsergean <https://github.com/bsergean>, I am trying to understand what you mean. The fix wasn't released with 0.5.4. — Reply to this email directly, view it on GitHub <#773 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2O6UMZNSH6Q73WWW2JIADWU54IBANCNFSM6AAAAAASQZVQAI>. You are receiving this because you were mentioned.

[bsergean]

I think that regardless of the reporting, I'm running into a separate problem with crashpad, as our process don't have ptrace enabled. I think we'll have to go back to using breakpad.

[9626:9626:20230130,164600.137083:ERROR scoped_ptrace_attach.cc:27] ptrace: Operation not permitted (1)

[supervacuus]

Od, I was able to see crashes reported with 0.5.4. Maybe the compilation was still picking up the breakpad compilation ?

Yes, because crashpad generally works fine on Linux. Just on some systems, it doesn't work with the socket transport. Since the curl transport seems to fix this issue and is the preferred transport on Linux by upstream, we will also make it the default.

[supervacuus]

I think that regardless of the reporting, I'm running into a separate problem with crashpad, as our process don't have ptrace enabled. I think we'll have to go back to using breakpad.

[9626:9626:20230130,164600.137083:ERROR scoped_ptrace_attach.cc:27] ptrace: Operation not permitted (1)

This is an environmental problem where something in your Linux setup (Docker, AppArmor, SELinux, ...?) prevents the crashpad_handler from establishing a ptrace connection to your process. If this problem persists, please create another issue, this is unrelated to this issue.