Which code model are you using? I see this crash when I use the “Clang Code Model”. I do not see it when using QtCreators “Built-in” code model.
The programs you create are compiled by your compiler. Any crashes in your programs are your bugs. ;-) My short opinion is at the bottom so we can separate out real answers from my missives. — Mike Jackson BlueQuartz Software > On Oct 22, 2015, at 7:12 PM, [email protected] wrote: > > One could say if Qt Creator cannot run with stability, how about > the programs it generates? > > Are the spawn of Qt Creator subject to the same level of reliability? > > Anybody from QT have a comment on what seems Mike Jacksons' casual > acceptance of Qt Creator instability? > > md > > > On 10/22/2015 5:04 PM, Mike Jackson wrote: >> Yep, >> That happens all the time. >> >> -- >> Mike J. >> >>> On Oct 22, 2015, at 6:04 PM, Jason H <[email protected]> wrote: >>> >>> Process: Qt Creator [244] >>> Path: /Users/USER/*/Qt Creator.app/Contents/MacOS/Qt >>> Creator >>> Identifier: org.qt-project.qtcreator >>> Version: 3.5.1 (3.5.1) >>> Code Type: X86-64 (Native) >>> Parent Process: ??? [1] >>> Responsible: Qt Creator [244] >>> User ID: 501 >>> >>> Date/Time: 2015-10-22 18:02:46.470 -0400 >>> OS Version: Mac OS X 10.10.5 (14F27) >>> Report Version: 11 >>> Anonymous UUID: 57991C14-344B-68C4-A500-C9F1516C91C7 >>> >>> >>> Time Awake Since Boot: 2800 seconds >>> >>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >>> >>> Exception Type: EXC_BAD_ACCESS (SIGSEGV) >>> Exception Codes: EXC_I386_GPFLT >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libTextEditor.dylib 0x0000000111874704 >>> TextEditor::FunctionHintProposalWidget::eventFilter(QObject*, QEvent*) + 340 >>> 1 org.qt-project.QtCore 0x000000010a944bac >>> QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, >>> QEvent*) + 220 >>> 2 org.qt-project.QtWidgets 0x0000000109bb73dc >>> QApplicationPrivate::notify_helper(QObject*, QEvent*) + 28 >>> 3 org.qt-project.QtWidgets 0x0000000109bbaced >>> QApplication::notify(QObject*, QEvent*) + 9421 >>> 4 org.qt-project.QtCore 0x000000010a944983 >>> QCoreApplication::notifyInternal(QObject*, QEvent*) + 115 >>> 5 org.qt-project.QtWidgets 0x0000000109bb7e4b >>> QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, >>> QWidget*, QWidget**, QPointer<QWidget>&, bool) + 987 >>> 6 org.qt-project.QtWidgets 0x0000000109c16600 0x109b86000 + 591360 >>> 7 org.qt-project.QtWidgets 0x0000000109c1580f 0x109b86000 + 587791 >>> 8 org.qt-project.QtWidgets 0x0000000109bb74bb >>> QApplicationPrivate::notify_helper(QObject*, QEvent*) + 251 >>> 9 org.qt-project.QtWidgets 0x0000000109bba89e >>> QApplication::notify(QObject*, QEvent*) + 8318 >>> 10 org.qt-project.QtCore 0x000000010a944983 >>> QCoreApplication::notifyInternal(QObject*, QEvent*) + 115 >>> 11 org.qt-project.QtGui 0x000000010a205f79 >>> QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) >>> + 2185 >>> 12 org.qt-project.QtGui 0x000000010a204e03 >>> QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) >>> + 131 >>> 13 org.qt-project.QtGui 0x000000010a1f19da >>> QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) >>> + 346 >>> 14 libqcocoa.dylib 0x000000010d0c01a1 0x10d09d000 + 143777 >>> 15 com.apple.CoreFoundation 0x00007fff8f41aa01 >>> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>> 16 com.apple.CoreFoundation 0x00007fff8f40cb8d >>> __CFRunLoopDoSources0 + 269 >>> 17 com.apple.CoreFoundation 0x00007fff8f40c1bf __CFRunLoopRun + 927 >>> 18 com.apple.CoreFoundation 0x00007fff8f40bbd8 CFRunLoopRunSpecific >>> + 296 >>> 19 com.apple.HIToolbox 0x00007fff8585956f >>> RunCurrentEventLoopInMode + 235 >>> 20 com.apple.HIToolbox 0x00007fff858591ee >>> ReceiveNextEventCommon + 179 >>> 21 com.apple.HIToolbox 0x00007fff8585912b >>> _BlockUntilNextEventMatchingListInModeWithFilter + 71 >>> 22 com.apple.AppKit 0x00007fff88bc78ab _DPSNextEvent + 978 >>> 23 com.apple.AppKit 0x00007fff88bc6e58 -[NSApplication >>> nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 >>> 24 com.apple.AppKit 0x00007fff88bbcaf3 -[NSApplication run] >>> + 594 >>> 25 libqcocoa.dylib 0x000000010d0bf08d 0x10d09d000 + 139405 >>> 26 org.qt-project.QtCore 0x000000010a94207d >>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 381 >>> 27 org.qt-project.QtCore 0x000000010a944f5a >>> QCoreApplication::exec() + 346 >>> 28 org.qt-project.qtcreator 0x0000000109916897 main + 21943 >>> 29 org.qt-project.qtcreator 0x000000010990e674 start + 52 >>> _______________________________________________ >>> Qt-creator mailing list >>> [email protected] >>> http://lists.qt-project.org/mailman/listinfo/qt-creator >> >> _______________________________________________ >> Qt-creator mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/qt-creator >> > > > -- > No spell checkers were harmed during the creation of this message. > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator <opinion>My acceptance isn’t casual either, just the reality of the situation for QtCreator on OS X. If you want a better coding experience with QtCreator with the least amount of headaches then I would highly suggest trying QtCreator on Windows or Linux. The results are much better. Leave Clang and LLDB completely out of the picture. Use GCC with GDB on Linux or the Visual Studio compilers on Windows (but still be in QtCreator). After waiting for almost a year now on QtCreator to become usable** for my team on OS X we have decided to migrate to either other platforms with QtCreator or other IDE’s. I am a long time Mac user (25 years) but even we have our breaking point. We wrote our own LLDB/python codes to peek inside the main types of Qt objects (Vector, Map, List, Object, String) and now have that working in Xcode, as an alternative to debugging with QtCreator. I *love* the way QtCreator presents our project. Simple. Mimics the file system. No extra crap like Xcode and Visual Studio throw in. The code coloring is awesome. The completion (when it finally kicks in [see below]) is spot all with the suggestion. The integration with Qt’s help system is great. The build system (ninja) is fast. The editor is configurable to our standards for indentation and style. I love the idea of Qt for Cross platform C++ development. It is highly consistent and easy to learn. There is a wealth of ready made classes and widgets to learn. My entry programmers can learn the frameworks very quickly. But I just can not ignore the productivity loss any more when pairing OS X and QtCreator. There was a build of 3.5.1 on SEPT 10, 2015 that mostly works. The completion is almost fast enough. It does not seem to crash that much(once a week maybe) and the debugger generally works if you know some “rules” to use it by. </opinion> **Usable. First we waited on proper cmake support. Then the cmake support “sort of worked” but didn’t get all the include paths correct. Then we had to wait on CMake 3.3.0 to come out so the solution that QtCreator needed was available All that time when trying to debug or own program, QtCreator would either crash, python would spin off into the ether or QtCreator would just spin forever. The LLDB integration is possibly getting better, but I can not tell because now the editing is completely unusable because the code completion takes 10 seconds to offer a suggestion, and that is after QtCreator spins with a beach ball for a bit. Our main development machines are 2014 MacBook Pro 15”, 16GB RAM, 1TB PCIe hard drives, 2.7GHz processors. so the machines should not really be the issue here. _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
