Opened 11 years ago
Last modified 4 weeks ago
#10468 new bug
KDL: assert failed, scheduler_thread.h:268: stolenTime >= 0
Reported by: | jscipione | Owned by: | pdziepak |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #18845 | |
Platform: | All |
Description (last modified by )
This KDL occurred while running the Icons screensaver overnight.
src/system/kernel/scheduler/scheduler_thread.h:268: stolenTime >= 0
KDL image attached
Attachments (4)
Change History (20)
by , 11 years ago
Attachment: | KDL running Icons.png added |
---|
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
comment:2 by , 11 years ago
Component: | - General → System/Kernel |
---|
comment:3 by , 11 years ago
I'm also seeing this panic right after boot in vbox with 2 CPUs in hrev46759.
by , 11 years ago
Attachment: | stolenTime.png added |
---|
comment:5 by , 11 years ago
Unfortunately, I am not able to reproduce this issue and reviewing the involved code does not show anything obviously wrong. I have attached a patch that adds numerous assertion checks to the code which, hopefully, would help to narrow down the issue.
comment:6 by , 11 years ago
Just a crazy thought due to the timing of the occurrence of this bug... could it be possible that the assert failed due to a time calculation that was skewed by the system clock changing due to DST?
comment:7 by , 11 years ago
Not really, system_time()
is monotonic (at least when invoked on the same logical processor). DST, time zones, etc affect only real_time_clock*()
family of functions.
by , 11 years ago
comment:8 by , 11 years ago
Applied the patch. This syslog contains several crashes in scheduler related code.
comment:10 by , 11 years ago
Some of the assertion fails in the syslog really shouldn't happen (namely fail at timeUsed >= 0) and are very strange. However, it just occurred to me that these problems may have also been caused by normal threads running with B_IDLE_PRIORITY
like in case of #10766.
Could you check whether the problem is still present on hrev47129?
comment:11 by , 11 years ago
So far I've reproduced timeUsed >= 0 assertion fail in hrev47140 in vbox with 2 cpu.
comment:12 by , 10 years ago
I'm seeing this issue as well, running hrev47380 in VirtualBox. Got both kinds, timeUsed >= 0
and stolenTime >= 0
failed asserts. I've never seen it happen when running directly on hardware, but since installing in virtualbox a few days ago, it occured several times already, so maybe it has to do with running in a VM... maybe something related to timing inaccuracy by the VM?
In all cases, the system was idling and not even being interacted with, the KDL was then waiting for me when I got back to it. I can provide KDL screenshots in case they are helpful (but I guess they don't show anything that's not already shown in the other attachments on this ticket).
comment:13 by , 5 years ago
Summary: | scheduler related KDL assert failed → KDL: assert failed, scheduler_thread.h:268: stolenTime >= 0 |
---|
comment:14 by , 10 months ago
Blocking: | 18845 added |
---|
comment:15 by , 4 weeks ago
Started getting this panic (scheduler_thread.h:317: timeUsed >= 0
) in VMware with both 1 and 2 cpus. Curiously, booting older states also panic with the same message.
KDL assert failed while running Icons screensaver overnight