================
@@ -226,13 +227,45 @@ lldb::SBError SBDebugger::InitializeWithErrorHandling() {
return error;
}
+#if LLVM_ENABLE_TELEMETRY
+#if ENABLE_BACKTRACES
+static void TelemetryHandler(void *) {
+ // TODO: get the bt into the msg?
+ // Also need to pre-alloc the memory for this entry?
+ lldb_private::telemetry::DebuggerInfo entry;
----------------
labath wrote:
The object itself is allocated on the stack, which is about the safest place
you can allocate memory in a signal handler. The problem is if you have any
variable length fields inside the object (strings, vectors, etc.), as they will
try to allocate data on the heap. Something like this also has impact on the
downstream implementation doing the actual sending, as that needs to be
signal-safe as well (and I expect that to be the trickiest part).
Writing async-signal-safe code is very hard. What you're balancing here is the
code complexity (and time to write it, etc.) versus the chance that you will
not be able to send some of the crash notifications. It's a large scale and I
don't know where your balance lies there. The only think *I* would like to
avoid is flaky tests.
What I might try to do is let each downstream implementation make that
determination for itself. Since you're not sending much in the way of actual
data (a backtrace might be nice, but that could also be gathered elsewhere),
maybe you don't need any create any objects here and just have a special
telemetry entry point (`AtCrash`?) that you call and let it do whatever it
wants. Or maybe we don't even need the special entry point, as the downstream
implementation could register the handler -- if it wants to?
https://github.com/llvm/llvm-project/pull/127696
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
