[tor-bugs] #15901 [Tor]: apparent memory corruption -- very difficult to isolate
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 24 21:12:17 UTC 2015
#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):
Yes, I've been over this. Have several 'unparseable-desc'
files but what is more interesting is that I have
perfect openable-with-gdb core images for four of
the five events.
Back in comment 20 the basis for the analysis was
opening a 'strings' of the core file in emacs and
comparing the memory version of the consensus document
against both the archived one and one I pulled in .z
form from another relay (identical). This is where
the confident assertion that a _single_ stray 64-bit
store corrupted the document derives from (erroneously
described as 32-bit in comment 20).
I'm planning to review the other three core
images in similar fashion, but am not in a big
hurry. This bug is epic, but real and reproducible
given enough time so I'm settled into a long-haul
mindset.
Just wrote a script to pull the current consensus
from all the authorities. Turns out that the .z
rendering is byte-for-byte identical for all
authorities and that the relay I used to pull
the consensus.z at the time of the latest event
matches them. So probably the above `infgen`
analysis is correct and the corruption does
not correspond with the zlib stream boundaries.
I'm not ruling out a zlib related cause, but
it's not going to be an obvious one if it is.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15901#comment:35>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list