Closed gsaviane closed 1 month ago
Thank you for raising the issue. Debugging this is going to be fun :) Are you able to isolate the Python code that's causing the issue and share it?
Thank you for raising the issue. Debugging this is going to be fun :) Are you able to isolate the Python code that's causing the issue and share it?
Unfortunately stderr is only receiving this from the dying process
Thread 0x0000007fa31164c0 (most recent call first): (no Python frame) Fatal Python error: Segmentation fault
The code causing the segfault is attached here [removed]
OK, I might have found the cause. This little piece of python code is executed as a telegraf input plugin to collect data from the Tapos and forward it to an MQTT topic. The plugin was set to run every 5 secs with a 4 sec timeout if it does not complete in that time window. Normally the plugin takes less than 1 sec to complete, but in some occasions (network lags, device not ready) it goes past the timeout, and Telegraf preempts it with a SIGTERM. Just by increasing the timeout it's not happening again, and the problem is reproducible. If you have a Tapo P1XX device, just execute it as a normal python program and send it a SIGTERM before it exits (probably you would need a sleep()). It may lack some graceful disposal of the threads created in by tokio upon a SIGTERM
Thank you for the update.
I was not able to replicate the issue without TaskGroups. Did you? Have you tried handling the SIGTERM on the Python side and cancelling the TaskGroups?
PS: I removed the zip file you've attached because it looked like it contained your Tapo password. You might want to change it.
Good catch! What an airhead I am, I changed it right away. Tomorrow I will try what you suggested
Thanks!
Il sab 15 giu 2024, 21:43 Mihai Dinculescu @.***> ha scritto:
Thank you for the update.
I was not able to replicate the issue without TaskGroups. Did you? Have you tried handling the SIGTERM on the Python side and cancelling the TaskGroups?
PS: I removed the zip file you've attached because it looked like it contained your Tapo password. You might want to change it.
— Reply to this email directly, view it on GitHub https://github.com/mihai-dinculescu/tapo/issues/228#issuecomment-2170595255, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5KCCWC6PRMGXVXGCKCZ63ZHSKMLAVCNFSM6AAAAABJHGMLTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZQGU4TKMRVGU . You are receiving this because you authored the thread.Message ID: @.***>
Hi, I tried with a SIGTERM handler to cancel the tasks but it fails in the same way. However, now I can get logged more details about the error
Thread 0x0000007f9df514c0 (most recent call first):
Are you able to try out the suggested solution to use the pyo3 auto-initiatize feature?
What you suggest is to rebuild the python package with that PyO3 feature enabled? If so, I need some guidance. By the way, I upgraded the tapo Python package to 0.3.1, and now my script hangs occasionally requiring a sigterm to exit. I needed to revert to 0.3.0
Closing this as a duplicate of https://github.com/mihai-dinculescu/tapo/issues/245.
I get random segfaults executing a python module that uses ApiClient to query a P110 device. Unfortunately the Python stack frame is not available when the process receives the signal, but I could catch a core dump that I analyzed with gdb. This is what it says
I can provide the dumped file if needed. Seen on 0.2.1 and 0.3.0 versions