Review Request 125123: [WIP] CMake plugin: prevent the QFileSystemWatcher from hitting the open file limit
René J.V. Bertin
rjvbertin at gmail.com
Sat Sep 12 17:08:22 UTC 2015
On Thursday September 10 2015 14:42:39 Milian Wolff wrote:
> Crashing in a dynamic cast means the pointer is invalid, and non-null. This should not happen, and I don't see how that is related to what you touch here.... Find out why it crashed (see below). This patch here looks like it's working around an issue, instead of fixing it.
Does this help in figuring out what goes wrong during that dynamic cast (for instance, to determine which one goes awry?!) ?
ASSERT: "DUChain::lock()->currentThreadHasReadLock() || DUChain::lock()->currentThreadHasWriteLock()"
2 libsystem_c.dylib 0x00007fff8c205b1a abort + 125
3 QtCore 0x000000010dc3a08b qt_message_output(QtMsgType, char const*) + 171
4 QtCore 0x000000010dc3b42a qt_message(QtMsgType, char const*, __va_list_tag*) + 506
5 QtCore 0x000000010dc39b8f qFatal(char const*, ...) + 159
6 libkdevplatformlanguage.8.dylib 0x000000010e2e8420 KDevelop::DUContext::visit(KDevelop::DUChainVisitor&) + 112
7 libkdev4cppduchain.dylib 0x000000012300c2f9 Cpp::CppDUContext<KDevelop::TopDUContext>::visit(KDevelop::DUChainVisitor&) + 313
8 libc++abi.dylib 0x00007fff991feb25 __dynamic_cast + 315
9 kdevcmakemanager.so 0x000000012ea8a509 CMakeCommitChangesJob::makeChanges() + 745
I've gotten a bit further with what happens in QKQueueFileSystemWatcher::addPaths() . Rather than hitting the open file limit in the initial open (qt_safe_open) call where it results in skipping the rest of the operation, we first hit it while doing an fddup of that opened file descriptor. And in that case the error is simply ignored.
When I patch the function to handle that situation appropriately (close fd, skip) then the crash disappears and I could actually quit KDevelop gracefully (tested once only).
More information about the KDevelop-devel