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 jscipione)

This KDL occurred while running the Icons screensaver overnight.

src/system/kernel/scheduler/scheduler_thread.h:268: stolenTime >= 0

KDL image attached

Attachments (4)

KDL running Icons.png (31.6 KB ) - added by jscipione 11 years ago.
KDL assert failed while running Icons screensaver overnight
stolenTime.png (53.7 KB ) - added by diver 11 years ago.
10468-assertions.diff (1.7 KB ) - added by pdziepak 11 years ago.
additional assertion checks
syslog (121.3 KB ) - added by diver 11 years ago.

Download all attachments as: .zip

Change History (20)

by jscipione, 11 years ago

Attachment: KDL running Icons.png added

KDL assert failed while running Icons screensaver overnight

comment:1 by jscipione, 11 years ago

Description: modified (diff)

comment:2 by diver, 11 years ago

Component: - GeneralSystem/Kernel

comment:3 by diver, 11 years ago

I'm also seeing this panic right after boot in vbox with 2 CPUs in hrev46759.

by diver, 11 years ago

Attachment: stolenTime.png added

comment:4 by diver, 11 years ago

Still happens in hrev47003.

by pdziepak, 11 years ago

Attachment: 10468-assertions.diff added

additional assertion checks

comment:5 by pdziepak, 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 jscipione, 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 pdziepak, 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 diver, 11 years ago

Attachment: syslog added

comment:8 by diver, 11 years ago

Applied the patch. This syslog contains several crashes in scheduler related code.

comment:9 by diver, 11 years ago

ping

comment:10 by pdziepak, 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 diver, 11 years ago

So far I've reproduced timeUsed >= 0 assertion fail in hrev47140 in vbox with 2 cpu.

comment:12 by jua, 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 waddlesplash, 5 years ago

Summary: scheduler related KDL assert failedKDL: assert failed, scheduler_thread.h:268: stolenTime >= 0

comment:14 by diver, 10 months ago

Blocking: 18845 added

comment:15 by diver, 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.

comment:16 by diver, 4 weeks ago

Weird, rebooted my windows laptop and now it doesn't happen anymore.

Note: See TracTickets for help on using tickets.