Opened 7 years ago

Closed 7 years ago

#9047 closed defect (fixed)

Discontinuity in position in microdescriptor cache

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.12-alpha
Severity: Keywords: tor-client microdesc discontinuity
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

[Mon Jun 10 22:35:05 2013] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_cache_rebuild(): Bug: Discontinuity in position in microdescriptor cache.By my count, I'm at 3727156, but I should be at 3727222
"

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by nickm

Component: - Select a componentTor
Keywords: tor-client microdesc discontinuity added
Milestone: Tor: unspecified
Status: newneeds_information

Is this on Windows?

Were there any previous warnings?

comment:2 Changed 7 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.4.x-final
Summary: DiscontinuityDiscontinuity in position in microdescriptor cache

See also #9031, #8922, and #8883.

It looks like the case we fixed in #8822 is not the only bug at work here.

It's interesting that the multiple for the discontinuity is always a multiple of 33, and that the length of the annotation field is 32.

Hypothesis: the microdesc write is succeeding, but the descriptor write is failing.

comment:3 Changed 7 years ago by nickm

Hypothesis #2: the descriptor write is failing with EINVAL because the md->body field is NULL. The #8822 fix should catch this case.

comment:4 Changed 7 years ago by rransom

How many newlines does each microdesc contain?

comment:5 in reply to:  4 Changed 7 years ago by rransom

Replying to rransom:

How many newlines does each microdesc contain?

As of 2013-04-04, each microdesc contained 6 newlines. Windows newline-munging probably doesn't explain an off-by-33 error.

comment:6 Changed 7 years ago by nickm

Status: needs_informationneeds_review

Ah. Indeed, the annotation is 33 with the newline. So the "we wrote the annotation but not the descriptor" hypothesis is looking better and better.

A microdesc has at least 6 newlines. Possibly more.

See my branch bug9047 for a bugfix, though I think the #8822 fix will remove the majority of what caused this (not checking if md->body is NULL, that is). I think this is clear enough to go into 0.2.4.x.

comment:7 Changed 7 years ago by andrea

I think this one looks okay. We know the annotations are always 33 bytes including the \n then?

comment:8 in reply to:  7 Changed 7 years ago by rransom

Replying to andrea:

I think this one looks okay. We know the annotations are always 33 bytes including the \n then?

Here's the first md in one of my cached-microdescs files:

@last-listed 2013-04-02 04:28:45
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALzkOvQKA2ZDXocrApv7L96fVdT2/2va8eNri8mFpGf2QkwTHlupA9BH
49YMC2fPmRkmo7Dk3+ElkO3KrPArqMYMEum4MUb4VqMYuKXV8z6IY7675j+5aj9N
L4ypw7RLhKPEoJRvT7yZhUyvfDPlG+pTYjy66NAEPlGwUzQK58IlAgMBAAE=
-----END RSA PUBLIC KEY-----
p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999

The @last-listed annotation looks like it should have a fixed length.

comment:9 Changed 7 years ago by rransom

(Nothing is going to depend on the annotations being 33 bytes long; that's just how Nick diagnosed this bug.)

comment:10 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Fixed a compatibility issue; merging.

Note: See TracTickets for help on using tickets.