[or-cvs] r11929: Backport r11829: Downgrade warning that caused bug 463; comm (in tor/branches/tor-0_1_2-patches: . doc src/or)

[nickm@xxxxxxxx]

Author: nickm
Date: 2007-10-14 04:48:59 -0400 (Sun, 14 Oct 2007)
New Revision: 11929

Modified:
   tor/branches/tor-0_1_2-patches/
   tor/branches/tor-0_1_2-patches/ChangeLog
   tor/branches/tor-0_1_2-patches/doc/TODO.012
   tor/branches/tor-0_1_2-patches/src/or/dns.c
Log:
 r15764@catbus:  nickm | 2007-10-14 04:43:10 -0400
 Backport r11829: Downgrade warning that caused bug 463; comment; resolve.



Property changes on: tor/branches/tor-0_1_2-patches
___________________________________________________________________
 svk:merge ticket from /tor/012 [r15764] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/branches/tor-0_1_2-patches/ChangeLog
===================================================================
--- tor/branches/tor-0_1_2-patches/ChangeLog	2007-10-14 08:48:56 UTC (rev 11928)
+++ tor/branches/tor-0_1_2-patches/ChangeLog	2007-10-14 08:48:59 UTC (rev 11929)
@@ -40,6 +40,9 @@
       key from getting rotated.
     - On some platforms, accept() can return a broken address.  Detect
       this more quietly, and deal accordingly.  (Fixes bug 483.)
+    - It's not actually an error to find a non-pending entry in the DNS
+      cache when canceling a pending resolve.  Don't log unless stuff
+      is fishy.  Resolves bug 463.
 
 
 Changes in version 0.1.2.17 - 2007-08-30

Modified: tor/branches/tor-0_1_2-patches/doc/TODO.012
===================================================================
--- tor/branches/tor-0_1_2-patches/doc/TODO.012	2007-10-14 08:48:56 UTC (rev 11928)
+++ tor/branches/tor-0_1_2-patches/doc/TODO.012	2007-10-14 08:48:59 UTC (rev 11929)
@@ -14,6 +14,6 @@
     (this will break some existing test-network configurations, yes?)
   o r11499, r11500, r11501: hidserv hexdigests rather than nicknames
 P - r11548, the osx /tmp fix
-N - r11829: Don't warn when cancel_pending_resolve() finds a cached failure.
+  o r11829: Don't warn when cancel_pending_resolve() finds a cached failure.
 R - r11915: just because you hup, don't publish a near-duplicate descriptor
 

Modified: tor/branches/tor-0_1_2-patches/src/or/dns.c
===================================================================
--- tor/branches/tor-0_1_2-patches/src/or/dns.c	2007-10-14 08:48:56 UTC (rev 11928)
+++ tor/branches/tor-0_1_2-patches/src/or/dns.c	2007-10-14 08:48:59 UTC (rev 11929)
@@ -839,9 +839,19 @@
   strlcpy(search.address, address, sizeof(search.address));
 
   resolve = HT_FIND(cache_map, &cache_root, &search);
-  if (!resolve || resolve->state != CACHE_STATE_PENDING) {
-    log_notice(LD_BUG,"Address %s is not pending. Dropping.",
+  if (!resolve)
+    return;
+
+  if (resolve->state != CACHE_STATE_PENDING) {
+    /* We can get into this state if we never actually created the pending
+     * resolve, due to finding an earlier cached error or something.  Just
+     * ignore it. */
+    if (resolve->pending_connections) {
+      log_warn(LD_BUG,
+               "Address %s is not pending but has pending connections!",
                escaped_safe_str(address));
+      tor_fragile_assert();
+    }
     return;
   }