[Bug runtime/16719] systemtap runs hold vmlinux file descriptor open

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16719

--- Comment #5 from Josh Stone <jistone at redhat dot com> ---
(In reply to Jonathan Lebon from comment #4)
> Good call. That's exactly what's happening here. Those files are kept open
> by libdw because their associated Dwfl objects are wrapped in shared_ptrs,
> and although build_no_more() reduces the refcount, setupdwfl.cxx also holds
> its own reference to it as a caching strategy (see setupdwfl.cxx:75).

For reference:

 75 // Store last kernel and user Dwfl for reuse since they are often
 76 // re-requested (in phase 2 and then in phase 3).
 77 static DwflPtr kernel_dwfl;
 78 static DwflPtr user_dwfl;

At the very least, these should be systemtap_session members, not globals!  We
may have distinct sessions for multiple --remote targets, which happen to have
similiar search parameters (e.g. just "kernel"), and they really should not get
reused by setup_dwfl_kernel.

I think kernel-debuginfo rpms can't be installed in parallel, yet, which may
explain why this has never troubled us.

> Since pass 3 also requires access to those objects, this actually works in
> our favour: build_no_more() lowers the refcount, and then we can completely
> lower it and free the Dwfl object once pass 3 is completed. The attached
> patch shows one straightforward way of doing this, placing it at the end of
> translate_pass(). (Is there a better-suited place for this? Maybe in
> main.cxx's passes_0_4()?).

I'm not sure how useful the single kernel_dwfl and user_dwfl really are in the
first place.  It's fine if they're re-requested in sequence, I guess.  But for
instance, if pass-3 starts on a different module than the last one pass-2
opened, the pass-3 will be creating the dwfls all over again.

Maybe scripts are just commonly focused enough that this works out ok?  This
also assumes that the search parameters used in setup_dwfl_kernel/user are
exactly the same, which I'm not sure about.

If the saved DwflPtrs were in maps, then we could really save *every* dwfl from
pass-2 for use in pass-3, but that still depends on matching search params.

As for when to clean these, remember that translate_pass() may sometimes be
skipped altogether.  Run pass 1, pass 2, check the cache, and jump to pass 5. 
So the cache-jump needs to have these dangling pass-2 dwfl cleared too.

-- 
You are receiving this mail because:
You are the assignee for the bug.