[Omega] Cannot terminate kodi when addon is enabled #738
Labels
bug
Something isn't working
Comments
rien333
changed the title
|
Interesting, I just upgraded to Kodi 21 Omega today and Kodi froze and locked up when I attempted to "Restart Kodi" from the UI Power menu (CoreELEC). I even waited 10 mins. I had to SSH into the Kodi box and "systemctl restart kodi". Never had to do this in Kodi 20 Nexus |
While somewhat similar, these observations may not be the product of the same issue. Can you reproduce this consistently? Does this only happen with this addon enabled? (my guess is that it isn't, since |
|
This doesn't seem to be directly related to this plugin. In your log you can see that the plugin service has responded to the abort signal and properly shutdown. The hangs that can occur on shutdown due to plugins, occur when this doesn't happen. The Python invoker thread that is running the plugin service is also being successfully terminated. At that point the plugin is completely out of the picture as far as I can tell. However your log does appear to be a bit odd. The Edit: Perhaps try running with Valgrind and see what it shows? |
Good find, but this doesn't seem to be the cause. To quote xbmc/xbmc#21240 (comment):
So, FDEventMonitor is alsa specific. If I launch kodi with
Good point, you are probably correct here. My reason for still bothering addons developers about this is that, nonetheless, the issue only happens with specific addons enabled. I think your suggesting to try Valgrind/debugging tools is the way forward, as it would allow me to determine who's responsible here (the kodi devs, the addon devs, or if this is all entirely on me). |
This comment was marked as outdated.
This comment was marked as outdated.
|
Wasn't suggesting that The referenced issue is identifying that the Plugins don't have any direct control over such low level Kodi internals, so your best bet is to open a Kodi issue. But I am curious to see the gdb and Valgrind output. As an aside, I have started (trying) to make sure that long lived instances of the Kodi specific Python modules are now being explicitly deleted, based on some unusual behaviour that is observed with interactions of multiple Addon and Settings instances. Don't have any evidence that they are not being properly destructed and garbage collected, and don't know how any of those modules would be holding windowing components open but you can try and see if there is any difference |
I know, I wasn't trying to draw a connection between this and that FWIW:
On it! Still poking around with gdb (I've never debugged multithreaded programs, so there's a bit of a learning curve)
I'm going to try this in a second! Thanks for the help and the interest 🙂 |
7 tasks
|
Unfortunately, #740 did not change anything. You can find my valgrind log in the second post over at xbmc/xbmc#25114, EDIT: weird, the output of valgrind without any potentially problematic addons enabed is incredibly long? |
Expected, Kodi has many non problematic memory leaks that Valgrind lists. When Kodi hangs Valgrind never reaches the stage where it checks for memory leaks. |
|
I noticed this as well with 7.0.5 after recent upgrades. None of the 7.0.6.x versions do this on my system. |
|
I mean, I tried with 7.0.7 (beta) and 7.0.6, so that seems like a different issue? |
|
Any difference if you disable InputStream.Adaptive to prevent the http server from starting? |
No, that unfortunately does not make a difference in terms of kodi being able to exit gracefully. Inputstream.adaptive having to do with this is a good guess though, because all/most affected addons use that. When I find the time, I might look at |
|
I found something!! So, Arch shipped kodi omega and python 3.12 pretty close to each other. This got me wondering: did 3.12 change anything wrt to threading code? Or perhaps something else of importance? Turns out, it might have, since I cannot reproduce this issue with python 3.11.8! |
|
I'm tring also to find out why Kodi can't exit, reboot or power off the system after updating python to 3.12. Journalctl shows me this: May 05 20:30:53 archbox xinit[136266]: [E] pw.loop [loop.c:67 pw_loop_new()] 0x60d3009f4d80: can't make support.system handle: No such file or directory
May 05 20:38:44 archbox kernel: LanguageInvoker[136291]: segfault at 79852c3a40d0 ip 0000798558772d11 sp 000079851a9ff5a8 error 4 in libpython3.12.so.1.0[79855867c000+266000] likely on CPU 0 (core 0, socket 0)
May 05 20:38:44 archbox kernel: Code: ff ff 48 89 ee ff d0 e9 cf fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 8b 57 f0 48 85 d2 74 26 48 8b 4f f8 <48> 8b 42 08 48 83 e1 fc 83 e0 03 48 09 c8 48 89 11 48 89 42 08 48
May 05 20:38:44 archbox systemd[1]: Started Process Core Dump (PID 136495/UID 0).
May 05 20:39:12 archbox systemd-coredump[136496]: [🡕] Process 136266 (kodi.bin) of user 1000 dumped core.kodi_crashlog-20240505_203913.log and then: May 05 20:39:13 archbox systemd[1]: [email protected]: Deactivated successfully.
May 05 20:39:13 archbox systemd[1]: [email protected]: Consumed 22.071s CPU time.
May 05 20:39:13 archbox xinit[136261]: /usr/bin/kodi: line 215: 136266 Segmentation fault (core dumped) ${KODI_BINARY} ${ENV_ARGS} $SAVED_ARGS
May 05 20:39:13 archbox xinit[136261]: Crash report available at /home/user/kodi_crashlog-20240505_203913.log |
|
Crashes with Python 3.12 are probably due to an upstream issue, see xbmc/xbmc#24440. To verify you have to install GDB and produce a stack trace (ideally with enabled Debuginfod). |
I don't think this is related to InputStream.Adaptive, but I asked you to disable it in the plugin settings because when it is enabled the plugin will launch a http server running in a separate thread, and an uneducated look at the gdb output does seem to indicate that it is related to Python threading The plugin checks the GUI settings to determine whether debug logging is enabled and will then prints additional details, including plugin settings, to the log. Unfortunately you have debug logging enabled via Enabling any of the following settings will enable the http server: Can you check these settings are all disabled when using #740 (note that it has been updated since you last tried it, please pull latest changes if you can), and see if the same thing still happens?
pezz is also using Arch with Python 3.12, but in v7.0.6.x they are having an issue where the http server is not launching and the associated player monitor threads were closing immediately, which may explain why they see this issue in v7.0.5 but not in v7.0.6.x |
|
Running from moojmidge's master branch (i.e. most recent version of #740), the issue still exist under python 3.12, even if I make sure the http server is not started by disabling aforementioned settings. (I double checked this by scanning for open ports using Here's the debug log, this time with debug logging enabled through the GUI: debug log |
|
Thanks for checking. I'm all out of ideas unfortunately. From your log this plugin should no longer be creating any additional threads, but I have no idea whether Python may be trying to obtain a lock for some other plugin thread or lock, or whether it is trying to obtain a lock for some other functionality that is not directly related to specifically creating a new thread in the running Python code. No idea as well what the difference may be between your setup and the one that pezz is using. One last random check would be to try Python 3.13 to see whether any of the threading related changes also resolve this issue, but not even sure whether Kodi would compile successfully |
|
According to this discussion (python/cpython#118618) the issue has probably already been solved. |
|
@nebulosa2007 While I'm curious to try python3.13, I'm not entirely sure how that issue relates. Also, as I've pointed out before, our issues are different, at least in terms of their symptoms: you are seeing a crash, I am seeing a hang. Those are not the same things. |
|
Confirmed this as a python issue. If apply this backported patch, everything works fine again. Sorry for the noise, and thanks for all your troubles and assistance! |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
Please provide any relevant information about your setup
Expected Behavior
If I have the youtube addon enabled, and quit kodi from the UI (or by issuing
/bin/kodi-send -a "ShutDown()"), kodi should exit normally. Likewise, if I run the kodi binary directly, it should exit normally when I type Ctrl-c .Current Behavior
If I have this addon enabled, kodi will not quit, except by sending it a force quit signal (e.g. something like
killall -9 kodi). Kodi does exit normally, however, if I disable this addon.As the log shows, kodi gets part of the way there (for instance, the UI is completely torn down), but ultimately fails to terminate completely.
I did not see this behavior on nexus (kodi v20).
Steps to Reproduce
Please provide detailed steps for reproducing the issue.
Log
https://gist.github.com/rien333/b63bb1b05c6fcb4be72c73b5ab3893fd
Additional Information
It should be emphasized that this behavior did not occur with nexus. Moreover, I've noticed that enabling a select group of other addons (notably, the Twitch and Netflix addons) leads to the exact same problem.
I'm 100% sure this problem only occurs when this is the only addon enabled (Together, of course, with its dependencies, such as inputstream adaptive. I cannot reproduce the issue with only inputstream adaptive enabled.)
Reports from the forum indicate that addons can sometimes cause these types of issues. Just some examples:
https://forum.kodi.tv/showthread.php?tid=358820
https://forum.kodi.tv/showthread.php?tid=288333
The text was updated successfully, but these errors were encountered: