QObject::killTimers

[kiwidude]

Does anyone else see this message when running calibre-debug -g?

QObject::killTimers: timers cannot be stopped from another thread
QObject::killTimers: timers cannot be stopped from another thread
QObject::killTimers: timers cannot be stopped from another thread
QObject::killTimers: timers cannot be stopped from another thread

I've been seeing this sporadically for a few weeks now. It occurs when I have a dialog window (from my plugin) open in Calibre, and I just leave it open without performing any activity for a minute or two.

I didn't mind so much when it was just messages, but today it is causing the calibre process to crash and close.

My dialog is just a normal modal one inheriting from QDialog no different to my other plugins, being displayed using d.exec_(), nothing special about the controls etc.

Any ideas what may be happening? Is Calibre running some sort of operation in the background after a period of inactivity or something?

[kovidgoyal]

That typically means that you have some sort of threading snafu in your code. Threading can be tricky to get right in PyQt (even more than normal) because of garbage collection and Qt threads. In what context is this dialog being opened? Does it use a QTimer or a QThread?

[kiwidude]

That's what I find confusing. I have never used threading or timers in any of my plugins. Like I said above it is just a bog standard dialog with the "normal" set of widgets like QTableWidget, QLabel, buttons etc. There is no stack trace in the command window output so I have no idea where the debug messages are coming from?

[kovidgoyal]

You're not going to get a stack trace that error happens inside the Qt libraries in C++ code, so that is the most you're going to get.

[kovidgoyal]

Originally Posted by kiwidude

That's what I find confusing. I have never used threading or timers in any of my plugins. Like I said above it is just a bog standard dialog with the "normal" set of widgets like QTableWidget, QLabel, buttons etc. There is no stack trace in the command window output so I have no idea where the debug messages are coming from?

There has to be something non standard about the dialog, or the context in which it is being launched, you just have to figure out what

[chaley]

I get these all the time during shutdown, but never during normal processing. I think that it is a bug in Windows Qt, where it incorrectly handles QObject timers during shutdown. I have tried, and failed, to find a triggering occurrence. Calibre uses timers for several things such as metadata backup throttling, but all the uses are correct. It is unreasonable for a program to traverse all QObjects and manually stop the timers, but that is what seems to be necessary.

The fact that you are seeing the messages while calibre is running is different from what I see. Look for any places where timers could implicitly be used, such as network timeouts, double-click timeouts, and the like. My guess is something like the first, with the timeout being delivered to the wrong event queue.

[kiwidude]

Thanks Kovid/chaley. In terms of context the dialog is just being opened in response to a triggered event of a QAction toolbar or menu item.

I can't see anything special or clever about the dialogs but if I can consistently replicate it that would be a start. However the error appearing is completely intermittent, it can be many hours of development of Calibre restarts etc before I happen to come across it again. That it happened to coincide with me "doing nothing" a few times made me think it was perhaps some sort of garbage collection or background operation going on.

I was curious whether other Calibre developers had seen it - perhaps it is a Windows Qt thing as chaley says which is why Kovid perhaps hasn't come across it. I'll keep an eye on it, it has been behaving itself since I posted in typical fashion.

[kiwidude]

I've been continuing to battle with this extremely intermittent issue. Every time I can replicate it a couple of times in a row I get all excited as to a possible scenario I can give you and then of course it fails to happen the next 20 times I try it.

What I have concluded is that while it does occur using some of my plugins, I can also get it to occur when not even loading my plugins (i.e. normal Calibre usage). I believe (one) of the culprits is the cover browser. Certainly with it visible I have the highest chance of repeating the issue. I am on Windows 7 64-bit, one of my plugin testers (dwanthny) is on Windows XP and we get the same QObject:killTimers message before Calibre immediately dies.

I have had this happen while sitting in the library view doing nothing and typing this post. Prior to that I managed to get it to happen while using the edit metadata dialog to "Generate default cover" for 50 books. It got about 22% of the way through according to the progress dialog and then crashed. this was after a clean start of calibre-debug -g with not starting any of my plugins

My normal view lately has been with the tag browser, cover browser and book details panel visible. But it seems to be the cover browser that most often causes this issue to show itself.

Any ideas/suggestions welcomed - particularly if chaley/Kovid et al could re-cast their eye over the threading around the cover browser and see if they can spot a possible cause.

[DoctorOhh]

Windows XP sp3 - Calibre 0.7.49

One more piece of the puzzle.

Creating covers with the plugin I would run into this error on cover creation virtually every time. I once was able to create 3 covers before it crashed calibre with this error showing in debug.

QObject::killTimers: timers cannot be stopped from another thread
QObject::killTimers: timers cannot be stopped from another thread

On Kiwidude's recommendation I hid the cover browser and I was successful in creating 32 covers in a row before I grew tired.

[kovidgoyal]

Hmm, I still dont see anything that could cause this, but I've made some changes to the cover browser, see if it makes a difference in the next release.

[DoctorOhh]

Originally Posted by kovidgoyal

Hmm, I still dont see anything that could cause this, but I've made some changes to the cover browser, see if it makes a difference in the next release.

Whatever you did was successful.

I just used the cover generation plugin to create multiple covers with the cover browser open and the QObject::killTimers error never reared its ugly head.

[kovidgoyal]

Glad to hear it