[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15901 [Tor]: apparent memory corruption -- very difficult to isolate
#15901: apparent memory corruption -- very difficult to isolate
---------------------------+--------------------------------
Reporter: starlight | Owner:
Type: defect | Status: new
Priority: critical | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version: Tor: 0.2.6.10
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
---------------------------+--------------------------------
Comment (by starlight):
Thank you for the fresh look!
Very interesting, so I should be looking for corrpution
of the DEFLATE dictionary. Can't be LTO because ZLIB
was not compiled this way in the earlier instances
and in this last instance, OpenSSL was carefully
built non-LTO.
The LTO progression was ssl-only libraries shared,
ssl+event+tor with libraries shared, ssl+zlib+
event+tor static build, zlib+event+tor not ssl
static build.
I don't see it as a zlib bug because it runs fine
for three weeks before the problem occurs, is
clearly related to the gradual shifting around
of heap allocations. Also different zlibs
have been in use at the time of the event
a) 1.2.8 shared library non-LTO,
b) 1.2.8 static link LTO.
I just put up a image where ASAN+UBSAN are
applied for only the directory/consensus
logic, but I did not compile ZLIB with
instrumentation. I'll go back and add
that and restart the relay. Instrumenting
just the selected modules is handy because
the relay's forwarding performance is not
impacted. Had to purchase more RAM so
it can run this way for more than a few
days.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15901#comment:26>
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