Opened 10 years ago

Last modified 7 years ago

#1176 closed defect (Not a bug)

server_port_flush looks strange

Reported by: Sebastian Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.2.6-alpha
Severity: Keywords:
Cc: Sebastian, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Coverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can never be executed more than once, because
port->pending_replies is never updated. It appears to me that a patch
like this should fix the problem:

diff --git a/src/or/eventdns.c b/src/or/eventdns.c
index 83bff67..70cf28c 100644
--- a/src/or/eventdns.c
+++ b/src/or/eventdns.c
@@ -1303,6 +1303,12 @@ server_port_flush(struct evdns_server_port *port)

return;

log(EVDNS_LOG_WARN, "Error %s (%d) while writing response to port; dropping", tor_socket_strerror(err), err);

}

+ if (req->next_pending && req->next_pending != req) {
+ port->pending_replies = req->next_pending;
+ } else {
+ port->pending_replies = NULL;
+ }
+

if (server_request_free(req)) {

/* we released the last reference to req->port. */
return;

But maybe I'm missing some subtleties here?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (3)

comment:1 Changed 10 years ago by nickm

I think server_request_free already unlinks the request. Did you look there?

comment:2 Changed 10 years ago by Sebastian

flyspray2trac: bug closed.
The code was clarified a little

comment:3 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.