Opened 3 weeks ago

Closed 3 weeks ago

#23696 closed defect (fixed)

Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version: Tor: 0.3.2.1-alpha
Severity: Normal Keywords: tor-client, tor-sched, easy, 0.3.2.2-alpha-must
Cc: pastly Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Just upgraded to TBB 7.5a5 on Windows 10 and at startup:

Tor WARN: tor_bug_occurred_(): Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed. (Future instances of this warning will be silenced.) (on Tor 0.3.2.1-alpha ) 
Tor WARN: Bug: Non-fatal assertion !((diff < 0)) failed in kist_scheduler_schedule at scheduler_kist.c:520. (Stack trace not available) (on Tor 0.3.2.1-alpha )

Child Tickets

Change History (12)

comment:1 Changed 3 weeks ago by arma

Version: Tor: 0.3.2.1-alpha

comment:2 Changed 3 weeks ago by arma

Cc: pastly added

Question for pastly:

A) This is on Windows -- is the kist scheduler supposed to be picked here? Is it supposed to be kistlite or something? (I still haven't read all the code.)

Question for network team person:

B) Is the monotonic time thing supposed to work on Windows too?

comment:3 Changed 3 weeks ago by cypherpunks

After third restart it changed to

Tor NOTICE: Scheduler type KISTLite has been enabled. 

comment:4 in reply to:  2 Changed 3 weeks ago by pastly

Replying to arma:

Question for pastly:

A) This is on Windows -- is the kist scheduler supposed to be picked here? Is it supposed to be kistlite or something? (I still haven't read all the code.)

I'm guessing KISTLite was used from the beginning. They both use the same code, except for ~1 function (not this one).

If Tor switched during runtime, it should have logged the switch and probably a reason why.

Regardless, I'm betting this is a failure of monotime actually being monotonic. Or ... if this was literally right away on startup and if we can't assume statically-allocated memory on Windows is initialized to 0, then it's possible scheduler_last_run was garbage and larger than now.

comment:5 Changed 3 weeks ago by pastly

Keywords: tor-sched added

comment:6 Changed 3 weeks ago by pastly

Keywords: easy added

nickm says we should just init scheduler_last_run in the scheduler init function, and init it to now.

My only protest is that we didn't just run and will have to wait 10ms in order to actually do so for the first time, but that probably doesn't really matter.

comment:7 in reply to:  6 Changed 3 weeks ago by dgoulet

Replying to pastly:

nickm says we should just init scheduler_last_run in the scheduler init function, and init it to now.

My only protest is that we didn't just run and will have to wait 10ms in order to actually do so for the first time, but that probably doesn't really matter.

Yeah impact should be very minimal but the other option is now - 1 ;)

comment:8 Changed 3 weeks ago by dgoulet

Keywords: 0.3.2.2-alpha-must added

I'm arguing that this MUST be in the next alpha. Trivial fix and would be good to avoid warnings for another 2 or 3 weeks ;).

comment:9 Changed 3 weeks ago by dgoulet

Status: newneeds_review

See branch: ticket23696_032_01.

comment:10 Changed 3 weeks ago by nickm

Status: needs_reviewmerge_ready

This seems okay to me. I'll merge it once isis/ahf say "go"

comment:11 in reply to:  10 Changed 3 weeks ago by isis

Replying to nickm:

This seems okay to me. I'll merge it once isis/ahf say "go"


go

comment:12 Changed 3 weeks ago by nickm

Resolution: fixed
Status: merge_readyclosed

merged

Note: See TracTickets for help on using tickets.