[tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--------------------------+----------------------------------
 Reporter:  starlight     |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by starlight):

 Replying to [comment:14 arma]:
 > Can you publish the results of your "tracing malloc" work?

 I wrote a quick but reasonable patch that activates and deactivates the
 standard mtrace() facility in response to a pair of RT signals (40-on,
 41-off) or control-channel commands.  Then traced something like 120
 seconds after the relay had warmed up.  mtrace.pl provided alloc/free
 subtraction.  Standard glibc hook functions are terribly inefficient and
 nearly kill it, but strong hints regarding the cause of the problem jumped
 off the page nonetheless and I set aside further refinement.  Was also
 trying to coax LSAN into producing a pretty report, but LSAN is "too
 smart," and builds a graph of references by searching all allocations for
 pointers to other allocations--reliably produced zilch.  No option to tune
 LSAN for stupidity and that exercise was a frustrating waste of time.

 The mtrace() patch can be enhanced with fast hook callbacks that write
 binary structs including full call-arcs, and I was prepared to do that
 (notes in the patch).  A small C/C++ utility to set-subtract frees from
 mallocs and pretty-print the results is required; should summarize by
 call-arc as Valgrind, ASAN, LSAN etc. do (anyone remember Purify?).

 I'm willing to work this into a proper enhancement if of interest.  My
 idea is that it can be an always-available on-demand memory trace one
 could activate and deactivate on a long-running instance, even one with
 months of uptime.

 Am a bit burned-out on hacking Tor at the moment and would prefer to take
 a month or two to finish (more like two).  If this is viewed as near-term
 desirable one of the core devs could certainly complete it and I won't
 feel upstaged (as long I get a little credit).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24806#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online