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.

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

bug/crash with scheduler api #414

Closed
KipK opened this issue Aug 10, 2022 · 6 comments · Fixed by #549
Closed

bug/crash with scheduler api #414

KipK opened this issue Aug 10, 2022 · 6 comments · Fixed by #549
Assignees

Comments

@KipK
Copy link
Collaborator

KipK commented Aug 10, 2022

I'm in holiday I can't track it but seems I saw a bug if only one schedule is set ( for example a "disabled" schedule with id: 1 , without an "enabled" one )

Can't see if it's a crash or bug from here, but then common status data from create_rapi_json are not published on MQTT, I think it's the same with http, event_send is not called. Either it crashes before or something else.

@jeremypoulter
Copy link
Collaborator

I did have an issue with something similar, thought I fixed it, will have a look.

@KipK
Copy link
Collaborator Author

KipK commented Aug 31, 2022

I see some events.getnext() in scheduler.cpp without checking if there's such next event first, could this be the culprit ?

@KipK
Copy link
Collaborator Author

KipK commented Oct 10, 2022

While working on the Timers part of the new GUI, I get this issue as the UX I'm doing is creating each timer separated.

I confirm the OpenEvse-wifi crash if there's only one timer.
Module crash in the wollowing 30 secs.

It doesn't happend if there's more, whatever the enable/disable parity is respected or not.

@KipK
Copy link
Collaborator Author

KipK commented Nov 12, 2022

@jeremypoulter , do you have any hints on this issue yet ?
I have no debugger here, and no access to the esp32 in production to fix that on my side.

@jeremypoulter
Copy link
Collaborator

Sorry, I have not had a chance to look at it yet

@KipK KipK mentioned this issue Dec 19, 2022
@KipK
Copy link
Collaborator Author

KipK commented Jan 28, 2023

@jeremypoulter Just a hint as I'm looking at it, it's not the fact that we have only one timer, it seems to need booth an active and disabled timer. I've tried with 2 enabled or disabled timers, and it also crash the firmware.
But I still don't know where it segfault, I need a stacktrace

@jeremypoulter jeremypoulter self-assigned this Feb 21, 2023
jeremypoulter added a commit that referenced this issue Feb 21, 2023
getNextEvent could get stuck in an infinate loop if searching for a type that is not in the list. This can happen when there is only enteries ofa single type, eg disabled and you search for active, as the LCD module does causing a watchdog timeout.

Fixes #414
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants