[tor-bugs] #24633 [Core Tor/Tor]: to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Dec 15 16:25:58 UTC 2017


#24633: to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。
-------------------------------------------------+-------------------------
 Reporter:  sx5486510                            |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  accepted
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.2.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  msvc 029-backport 030-backpot        |  Actual Points:
  031-backpot                                    |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by nickm):

 * keywords:   => msvc 029-backport 030-backpot 031-backpot


Comment:

 Have you checked what the actual value of `wheel` was in this case?  For
 the call stack you're showing, `rem` should be 6290. Assuming `WHEEL_BIT
 == 6` (the default) and `WHEEL_NUM == 5` (set in `src/common/timers.c`),
 we have `wheel == timeout_wheel(rem)`.

 That function is defined as
 {{{
 static inline int timeout_wheel(timeout_t timeout) {
         /* must be called with timeout != 0, so fls input is nonzero */
         return (fls(MIN(timeout, TIMEOUT_MAX)) - 1) / WHEEL_BIT;
 } /* timeout_wheel() */
 }}}

 so:
 {{{
 (MIN(6290,TIMEOUT_MAX) == 6290)
 fls(6290) == (64 - clz64(6290)) == (64 - 51) == 13
 (13 - 1) / WHEEL_BIT == 12 / 6 == 2
 }}}

 So if you're seeing wheel >= 5, there might be a bug here.  Maybe in the
 implementation of clz64?

 To test that -- if you build timeout_bitops.c as a standalone binary, with
 TEST_BITOPS defined, do the tests there fail?  I suspect that this may be
 a MSVC-only bug if so.  At first glance, it seems that the definitions of
 the various functions in timeout-bits.c for MSVC could be wrong.  If so,
 that would seem to match up with what's reported upstream at
 https://github.com/wahern/timeout/issues/22 .

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24633#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list