Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CI: Windows Host Builds Taking Forever #2594

Closed
slaff opened this issue Dec 8, 2022 · 2 comments
Closed

CI: Windows Host Builds Taking Forever #2594

slaff opened this issue Dec 8, 2022 · 2 comments

Comments

@slaff
Copy link
Contributor

slaff commented Dec 8, 2022

Sometimes the windows-host build is taking forever. The reason for it seems to be the tests execution. Might be due to a deadlock in the host emulator.

More about the issue here:

image

Example: https://github.com/SmingHub/Sming/actions/runs/3646634352/jobs/6157931489
Output:

Background timer: ticks 2478726, time 496ms, heap free 117509, used 13563, peak 24847

40754761 showFontStyle: notoSans15 DotMatrix (32 of 50)

40957857 showFontStyle: notoSans15 HLine (32 of 50)



signal_handler: SIGINT - Ctrl+C pressed
returning 0
make[3]: *** [run] Interrupt
make[2]: *** [execute] Interrupt
make[1]: *** [Libraries/Graphics/test/.host.complete] Interrupt
make: *** [tests] Interrupt
Terminate batch job (Y/N)? 

D:\a\Sming\Sming\Sming>echo Failed with error #66048. 
Failed with error #66048.

D:\a\Sming\Sming\Sming>exit /b 66048
@slaff
Copy link
Contributor Author

slaff commented Dec 8, 2022

@mikee47 when you have time can you look at the issue above?

@mikee47
Copy link
Contributor

mikee47 commented Oct 11, 2023

Fixed in #2606.

@mikee47 mikee47 closed this as completed Oct 11, 2023
@mikee47 mikee47 mentioned this issue Oct 11, 2023
Merged
slaff pushed a commit that referenced this issue Oct 12, 2023
@mikee47
Bugfix: Rp2040 os_timer_setfn() can stall other timers. (#2672)
b153bc8 
If called on first timer in queue then subsequent timers get disconnected. Must explicitly `disarm` the timer first so it's properly removed from queue. This is consistent with esp8266 behaviour.

Also applied to host timer from whence the code originated.
This bug might explain root cause of #2594, where code hangs during intensive timer usage. Specifically, this issue gets triggered if attempting to change the callback on an active timer. (If the timer is inactive then it's not in the queue so doesn't matter.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@slaff @mikee47