Bug 217492

Summary: Python plasmoid crashes on exit when calling "time.sleep(1)" on a secondary thread (QThread was also used)
Product: [Unmaintained] bindings Reporter: Giacomo Lacava <g.lacava>
Component: generalAssignee: kde-bindings
Status: RESOLVED WORKSFORME    
Severity: crash CC: andresbajotierra, cfeck, dcmair, nik, thomas.mueller
Priority: NOR Keywords: triaged
Version: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Giacomo Lacava 2009-12-05 20:49:08 UTC
Application that crashed: plasmoidviewer
Version of the application: 1.0
KDE Version: 4.3.4 (KDE 4.3.4)
Qt Version: 4.5.2
Operating System: Linux 2.6.31-16-generic i686
Distribution: Ubuntu 9.10

What I was doing when the application crashed:
In a python applet-plasmoid, I had some code calling KIO.NetAccess.download and emitting some (arbitrary) signals when done, which was working fine. I put this code in a QThread to make it work asynchronously, and now the applet crashes the entire plasma-desktop on exit. Note that the plasmoid does complete all tasks, including secondary-threaded ones; it crashes only on exit. 
The QThread job is launched from the applet "init" method (not "__init__").
PyKDE documentation advises about such cases as a result of not subclassing KMainWindow, but this is not possible for plasmoids.
I'm on Kubuntu 9.10 with ptyhon-kde4-dbg, python-qt4-dbg, kdelibs5-dbg, let me know if I need to reproduce with other packages installed.

 -- Backtrace:
Application: Plasma Widget Viewer (plasmoidviewer), signal: Segmentation fault
[Current thread is 1 (Thread 0xb772d710 (LWP 3791))]

Thread 2 (Thread 0xaafb6b70 (LWP 3796)):
#0  0x00dbf422 in __kernel_vsyscall ()
#1  0x0184f142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x01f167e4 in pthread_cond_timedwait () from /lib/tls/i686/cmov/libc.so.6
#3  0x00a8adef in QWaitConditionPrivate::wait (this=0x9453ba0, mutex=0x9453b9c, time=30000) at thread/qwaitcondition_unix.cpp:85
#4  QWaitCondition::wait (this=0x9453ba0, mutex=0x9453b9c, time=30000) at thread/qwaitcondition_unix.cpp:159
#5  0x00a7f9ae in QThreadPoolThread::run (this=0x93b6520) at concurrent/qthreadpool.cpp:140
#6  0x00a89e32 in QThreadPrivate::start (arg=0x93b6520) at thread/qthread_unix.cpp:188
#7  0x0184a80e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0x01f097ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb772d710 (LWP 3791)):
[KCrash Handler]
#6  0x0211492a in PySys_GetObject (name=0x218653b "exitfunc") at ../Python/sysmodule.c:53
#7  0x0210ebd6 in call_sys_exitfunc () at ../Python/pythonrun.c:1681
#8  Py_Finalize () at ../Python/pythonrun.c:399
#9  0x01b66200 in KPythonPluginFactoryCleanup_PostRoutine () at ../../../../python/pykde4/kpythonpluginfactory/kpythonpluginfactory.cpp:67
#10 0x00b7ac00 in qt_call_post_routines () at kernel/qcoreapplication.cpp:163
#11 0x00ee9ba8 in ~QApplication (this=0xbfe9b2cc, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:971
#12 0x00399a9a in ~KApplication (this=0xbfe9b2cc, __in_chrg=<value optimized out>) at ../../kdeui/kernel/kapplication.cpp:904
#13 0x0804f99d in _start ()

Reported using DrKonqi
Comment 1 Dario Andres 2009-12-05 21:22:08 UTC
Offtopic detail: KIO functions shouldn't be used with Threads... (as it can cause problems AFAIK). You should use the SIGNAL-SLOTS method.
This could be a problem in bindings too.
Regards
Comment 2 Giacomo Lacava 2009-12-05 23:51:56 UTC
I tried removing the KIO calls and I still got a crash. I'll try to reduce the scope further...
Comment 3 Giacomo Lacava 2009-12-05 23:58:14 UTC
The culprit was a call to time.sleep(1) in the secondary thread.

Guess I just verified the old assumption that mixing QThreads and python threads is not a good idea.
Comment 4 nik 2009-12-28 03:52:44 UTC
I have a very similar problem with my plasmoid :

#5  0x00007f5d50dcdc3d in PySys_GetObject (name=0x7f5d50e3d377 "exitfunc") at ../Python/sysmodule.c:53

I can remove the applet from plasmoidviewer (or plasma-desktop) without a problem, but when plasmoidviewer or plasma-desktop exits I get the crash.

If you have any hint/idea please help me - I already spent hours on that..

What I do in the code:
1. load a library via ctypes (pulseaudio library)
2. install a callback function (to get notified by state-changes of pulseaudio)
3. start an external thread that "runs inside the library"
OnExit: I stop that external thread and do the required cleanup 

- When I call sys.exit(0) inside my code plasmoidviewer exits without a crash (bot I don't want plasma-desktop to exit when I remove the plasmoid).
- When I do not set a callback function, I get no crash
---

Is this a threading problem? Maybe ctypes starts a thread for the callback function? Whats the relation between PySys_GetObject("exitfunc") and threads?


the plasmoid: http://www.kde-look.org/content/show.php/?content=116676
Comment 5 nik 2010-03-23 01:09:17 UTC
Could be related to this python-bug: http://bugs.python.org/issue6869
Comment 6 Nicolas L. 2010-08-20 10:17:49 UTC
*** Bug 221049 has been marked as a duplicate of this bug. ***
Comment 7 Nicolas L. 2010-08-20 10:18:04 UTC
*** Bug 248412 has been marked as a duplicate of this bug. ***
Comment 8 Christoph Feck 2013-09-12 21:45:37 UTC
This crash report is at least 3 years old and there were no further comments or status updates since then.

Therefore we believe that this crash is already fixed in recent KDE 4 versions or the backtrace is no longer applicable to the current KDE 4 sources.

If the crash still happens with a recent KDE version (4.10.5 or 4.11), please add an updated backtrace or provide steps to reproduce. For more information, see http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports

(To prevent automatic closing of this bug in the future, please set the bug status to ASSIGNED or CONFIRMED)
Comment 9 Andrew Crouthamel 2018-09-24 02:20:44 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 10 Andrew Crouthamel 2018-10-27 03:46:47 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!