Re: [patch] debuginfod more metrics
Hi Frank, On Thu, 2020-11-19 at 13:50 -0500, Frank Ch. Eigler via Elfutils-devel wrote: > Subject: [PATCH] debuginfod: add thread-busy metrics to webapi > service > > Improve monitoring of debuginfod instances by tracking thread_busy > status for the threads responding to http requests. While these are > usually short-lived, longer archive-uncompress operations can take > long enough time to show up on top/uptime. This should also assist > noticing abusive clients and guide scaling of the service. Looks fine to me. The scoped increment & decrement is nice. Cheers, Mark
[PATCH] debuginfod: Handle "/" and report unrecognized operations
This doesn't change any functionality, but simply shows something a little
user friendlier when accessing the server "by hand" (in a browser).
Signed-off-by: Mark Wielaard
---
debuginfod/ChangeLog | 5 +
debuginfod/debuginfod.cxx | 20 +++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index d4face2d..e2ae4785 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2020-11-21 Mark Wielaard
+
+ * debuginfod.cxx (handle_root): New function.
+ (handler_cb): Handle "/" and report url1 in webapi error.
+
2020-11-11 Mark Wielaard
* debuginfod-find.c (progressfn): Use clock_gettime to print Progress
diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
index d2a434ee..c112e8a0 100644
--- a/debuginfod/debuginfod.cxx
+++ b/debuginfod/debuginfod.cxx
@@ -1784,6 +1784,19 @@ handle_metrics (off_t* size)
return r;
}
+static struct MHD_Response*
+handle_root (off_t* size)
+{
+ static string version = "debuginfod (" + string (PACKAGE_NAME) + ") "
+ + string (PACKAGE_VERSION);
+ MHD_Response* r = MHD_create_response_from_buffer (version.size (),
+(void *) version.c_str (),
+MHD_RESPMEM_PERSISTENT);
+ *size = version.size ();
+ MHD_add_response_header (r, "Content-Type", "text/plain");
+ return r;
+}
+
@@ -1859,8 +1872,13 @@ handler_cb (void * /*cls*/,
inc_metric("http_requests_total", "type", "metrics");
r = handle_metrics(& http_size);
}
+ else if (url1 == "/")
+{
+ inc_metric("http_requests_total", "type", "/");
+ r = handle_root(& http_size);
+}
else
-throw reportable_exception("webapi error, unrecognized /operation");
+throw reportable_exception("webapi error, unrecognized '" + url1 +
"'");
if (r == 0)
throw reportable_exception("internal error, missing response");
--
2.18.4
[Bug libdw/26930] New: tsearch/tfind tree caches need locking
https://sourceware.org/bugzilla/show_bug.cgi?id=26930 Bug ID: 26930 Summary: tsearch/tfind tree caches need locking Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: mark at klomp dot org CC: elfutils-devel at sourceware dot org Target Milestone: --- libdw uses various search trees as (lazy) caches. Specifically struct Dwarf has: /* Search tree for the CUs. */ void *cu_tree; Dwarf_Off next_cu_offset; /* Search tree and sig8 hash table for .debug_types type units. */ void *tu_tree; Dwarf_Off next_tu_offset; Dwarf_Sig8_Hash sig8_hash; /* Search tree for split Dwarf associated with CUs in this debug. */ void *split_tree; /* Search tree for .debug_macro operator tables. */ void *macro_ops; /* Search tree for decoded .debug_line units. */ void *files_lines; struct Dwarf_CU has: /* Known location lists. */ void *locs; struct Dwarf_CFI_s has: /* Search tree for the CIEs, indexed by CIE_pointer (section offset). */ void *cie_tree; /* Search tree for the FDEs, indexed by PC address. */ void *fde_tree; /* Search tree for parsed DWARF expressions, indexed by raw pointer. */ void *expr_tree; struct Dwfl_Module has: void *lazy_cu_root; /* Table indexed by Dwarf_Off of CU. */ When used in a concurrent program they need to be read locked when searched (with tfind) and write locked when updating (with tsearch). See several backtraces in bug #26921 which describes a different concurrent unsafe update mechanism. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #7 from Mark Wielaard --- Thanks for the backtraces, they show a different concurrent unsafe thing in libdw, the usage of (lazy) tsearch caches. I opened a separate bug for that, bug #26930 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #8 from Ben Woodard --- One thing that I’m unclear about is how these two are different. It doesn’t matter to me that they are split up but I just don’t understand why? -ben On Sat, Nov 21, 2020 at 2:00 PM mark at klomp dot org < sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=26921 > > --- Comment #7 from Mark Wielaard --- > Thanks for the backtraces, they show a different concurrent unsafe thing in > libdw, the usage of (lazy) tsearch caches. I opened a separate bug for > that, > bug #26930 > > -- > You are receiving this mail because: > You are on the CC list for the bug. > > -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #9 from Mark Wielaard --- (In reply to Ben Woodard from comment #8) > One thing that I’m unclear about is how these two are different. > It doesn’t matter to me that they are split up but I just don’t understand > why? Simply so the bugs cover something tractable. There are other places where we update shared state in a way that is not safe for concurrent code. We don't have a list of all such places yet. The task to find and fix them all is IMHO too big for one bug. If you want you could create a meta bug for that which then can depend on these 2 bugs (plus any others for issues we find in the future). -- You are receiving this mail because: You are on the CC list for the bug.
