[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [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
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs