deadlock in loadpoint api #18603
Labels
question
Rather clarification than issue
Comments
|
The log looks cut off but here is the end of it. there is no activity apart from ocpp |
|
@jeffborg please omit |
Also not visible in the log afaikt. Anyway the log is too noisy to see much. |
|
@andig worked it out what --profile does, just using nightly as both nightly and 0.133.0 have the same issue First time running and this happened - 2nd start was ok so will be another comment once it stops functioning I'll get the profile out. |
Can tell because of this |
|
@andig here is your answer about which locks are causing an issue. Seems in loadpoint_api.go SetDisableThreshold & GetMaxCurrent are deadlocked! Yes I have home assistant setting the enable / disable threasholds externally. but this shouldn't cause any issues and clearly it is. This is not an issue in 0.132.1. Also attached is the debug2 version just in case. debug=1 output Logs just stop at 10:42:21 as you mentioned earlier not really much to see here except as above in original log the last message was a set for disableThreshold |
|
Looks like a deadlock here, just not sure why this would deadlock: Apart from this shouldn't be happening, you've selected "no external automation". Where would these MQTT requests be coming from? /cc @GrimmiMeloni |
|
@andig Just dynamically setting the enable and disable thresholds. It wasn't an issue in 0.132.1 or hasn't been an issue beforehand. This shouldn't occur full stop. I hammered a 2nd copy on my computer against these 2 methods and couldn't get a result. But that was go from the container. My gut feeling it's an issue in go itself and if I rebuild 0.132.1 with the latest go because the Dockerfile doesn't limit the point version I may see the issue in 0.132.1 as well. |
|
So there is external automation? Just to get the picture straight. Could you try the nightly, too? |
|
@andig that was the nightly for the profile same as 0.133.0. Never bothered with 0.133.0 for profile. Forgot to add yes externally automations. |
|
@andig I went through the call chain. The thread in |
|
Nope. That's what RLocks are for- they just allow ready and you can have any number of those. I still don't get it. The RLock will only stall if a Lock is already being held. |
|
Not when you are concurrently trying to acquire a write lock (like in this case the MQTT routine).
|
|
Of course. But the writer doesn‘t have the lock either. So who has? |
|
Still 153. It is exactly the behavior described in the docs I quoted. |
|
Whaaaaat. Youre right. Never noticed that. |
|
@andig this line is the cause of it 285b22e#diff-64161edf08f807019f3ade5b7d32ce0f06b9a42bab3450090d8223f3ec6c2ee0R85 Just did a git bisect and given the previous explanations makes total sense. FYI if you want to recreate
This will cause the deadlock within 2 minutes max every time on the above commit, the commit before no issues. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
evcc stops updating meters after some time, no mqtt activity from meters solar etc..
Also disconnects from mqtt broker as indicated by the broker updating the evcc/status topic to offline
Steps to reproduce
Configuration details
Log details
What type of operating system or environment does evcc run on?
Docker container
External automation
Nightly build
Version
0.133.0
The text was updated successfully, but these errors were encountered: