This is caused by latest MS security update. After applying these two 3126587 and 3126593 previous versions of Incredibuild stopped working.
Command line error D8037 : cannot create temporary il file
The solution is to uninstall it
https://support.microsoft.com/en-us/kb/3126587
https://support.microsoft.com/en-us/kb/3126593
On Windows 10 the responsible update is KB3135173
Also it’s necessary to disable these updates in auto-update!
class UltraView : public QQuickView {
protected:
void keyPressEvent(QKeyEvent*event) override {
if(event->key()==Qt::Key_F5){
auto oldSource=source();
setSource({});
engine()->clearComponentCache();
setSource(oldSource);
}
}
};
else if(event->key()==Qt::Key_F10) {
QUnifiedTimer::instance()->setSlowModeEnabled(true);
QUnifiedTimer::instance()->setSlowdownFactor(10);
} else if(event->key()==Qt::Key_F11) {
QUnifiedTimer::instance()->setSlowModeEnabled(false);
QUnifiedTimer::instance()->setSlowdownFactor(1);
}
SET QSG_VISUALIZE=batches or SET QSG_VISUALIZE=clip or SET QSG_VISUALIZE=changes or SET QSG_VISUALIZE=overdraw qmlviewer test.qml
Notes about compiling QtWebEngine (instead of QtWebkit) together with Qt 5.5.1
Qt 5.5.0 configure switches for ICU:
configure \
-icu \
-I Q:\SharedLibraries\icu4c-51_1\icu\include \
-L Q:\SharedLibraries\icu4c-51_1\icu\lib64
Starting with 5.5.1 it shouldn’t be necessary to compile and ship ICU libraries because ICU should be included in Qt package itself.
It’s necessary to compile it as standalone module.
cd Qt/qtwebkit perl Tools\Scripts\build-webkit
Much easier solution seem to be to use http://www.awesomium.com/ 😉
As temporary fix, set following environment variable in VS (Debugging->Environment):
So, one more attempt. Previous articles (part1, part2) mentioned possible solutions to fix crash insinde the QTreeWidget and QAccessibleTableCell.
Unfortunately, deselecting current item still doesn’t fix all issues. The problem with deselection is that it’s not handled correctly via QAccessibleTableCell:
If current index isn’t valid, QAccessible doesn’t correctly update currect QAccessibleTableCell object which caused all this evil crashes.
So there are two ways how to fix it. One is to manually set QAccessibleTableCell but I didn’t find a way how to do that. The second way is to disable QAccessible for Property editor. Unfortunately it’s not an easy task. In QAccessible exists method setActive:
QAccessible::setActive(false)
But this method works only with AccessibleObserver class but not with QPlatformAcessibility which handles real QAcessible::isActive result. Because of this it’s necessary to update setActive method in file qacessible.cpp inside the Qt.
Original method:
void QAccessible::setActive(bool active)
{
for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)
qAccessibleActivationObservers()->at(i)->accessibilityActiveChanged(active);
}
and updated version:
void QAccessible::setActive(bool active)
{
#ifndef QT_NO_ACCESSIBILITY
if ( QPlatformAccessibility *pfAccessibility = platformAccessibility() )
pfAccessibility->setActive(active);
#endif
for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)
qAccessibleActivationObservers()->at(i)->accessibilityActiveChanged(active);
}
In case you will find better way how to turn off accessibility, please let me know.
But there is still one more problem. Occasionally OS X decides to switch accessible back on:
And this is probably the reason why everything works ok on older OS X but not on 10.10. Because OS X 10.10 randomly turns accessible on which causes this crash. Accessible is usually turned on when opening some modal dialog.
This explains why opening an empty dialog increased the probability to crash the application. The only solution I have found is to disable QAccessible every time the PropertyEditor is cleared up.
As mentioned in the first part of this article, the workaround with focus unfortunately didn’t work. In some cases application is still crashing. So after next hours of debugging and unsuccessful consulting the problem on stack overflow I probably found a the core reason of this bug and the solution too.
The core of this problem doesn’t lie in the QTreeModel, but in Qt implementation of Cocoa Accessible. The problem is that although the PropertyTree is correctly cleared, there is object QAccessibleTableCell which isn’t correctly updated after
clear()
.
This means that although the PropertyTree and TreeWidget is empty, the QAccessibleTableCell object still holds m_index variable to invalid element. And when
NSAcessibleEntryPointrAttributeNames
is executed, m_index is translated to QTreeWidget element pointer and accessed. And this means that application completely crashes.
The solution is pretty simple. Together with property editor clear set also current index and selected index to NULL.
propertyBrowser->clear(); propertyManagers->clear(); propertyManagers->treeWidget()->setCurrentItem(NULL); propertyManagers->treeWidget()->setItemSelected(NULL, false);
And that is it. Thanks for this your application will not crash any more (on this bug 😉 ).
This crash took me about 40hr+ to replicate and find a way how to eliminate it (unfortunately not to fix it). This crash occurred only on OS X 10.10, not 10.9, not Linux, not Windows.
Bug occurred in slightly modified QtTreePropertyBrowser where we have additional buttons for each property.
When any of these buttons caused property tree refresh, application randomly crashed. But when these actions were executed by buttons outside of the property tree, everything worked fine.
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.qt-project.QtWidgets 0x0000000103f49290 QTreeModel::index(QTreeWidgetItem const*, int) const + 176 1 org.qt-project.QtWidgets 0x0000000103f4950b QTreeModel::parent(QModelIndex const&) const + 75 2 org.qt-project.QtWidgets 0x0000000103f23bb7 QTreeView::isIndexHidden(QModelIndex const&) const + 71 3 org.qt-project.QtWidgets 0x0000000103f17e0d QTreeView::visualRect(QModelIndex const&) const + 93 4 org.qt-project.QtWidgets 0x0000000103ec490d QAccessibleTableCell::rect() const + 29 5 org.qt-project.QtWidgets 0x0000000103ec46f2 QAccessibleTableCell::state() const + 146 6 libqcocoa.dylib 0x00000001071913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58 7 libqcocoa.dylib 0x000000010718df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398 8 com.apple.AppKit 0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115 9 com.apple.AppKit 0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56 10 com.apple.AppKit 0x00007fff95e2a62a CopyAttributeNames + 216 11 com.apple.HIServices 0x00007fff9768cbce _AXXMIGCopyAttributeNames + 252 12 com.apple.HIServices 0x00007fff976950c6 _XCopyAttributeNames + 385 13 com.apple.HIServices 0x00007fff97671109 mshMIGPerform + 199 14 com.apple.CoreFoundation 0x00007fff99259c79 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 15 com.apple.CoreFoundation 0x00007fff99259beb __CFRunLoopDoSource1 + 475 16 com.apple.CoreFoundation 0x00007fff9924b767 __CFRunLoopRun + 2375 17 com.apple.CoreFoundation 0x00007fff9924abd8 CFRunLoopRunSpecific + 296 18 com.apple.HIToolbox 0x00007fff9695d56f RunCurrentEventLoopInMode + 235 19 com.apple.HIToolbox 0x00007fff9695d2ea ReceiveNextEventCommon + 431 20 com.apple.HIToolbox 0x00007fff9695d12b _BlockUntilNextEventMatchingListInModeWithFilter + 71 21 com.apple.AppKit 0x00007fff95a489bb _DPSNextEvent + 978 22 com.apple.AppKit 0x00007fff95a47f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 23 libqcocoa.dylib 0x000000010717b29d QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2093 24 org.qt-project.QtCore 0x0000000104b0337d QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 381 25 org.qt-project.QtWidgets 0x0000000103e6c192 QDialog::exec() + 514
I updated methods from signals-slots mechanism to QEvent system. Unfortunately this didn’t help as well. Next attempt was QTimer usage instead of QEvent or signal-slot to simulate real click. But also without any success.
0 org.qt-project.QtWidgets 0x000000011112f62e QTreeModel::data(QModelIndex const&, int) const + 46 1 org.qt-project.QtWidgets 0x00000001110aa7bb QAccessibleTableCell::state() const + 347 2 libqcocoa.dylib 0x00000001143913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58 3 libqcocoa.dylib 0x000000011438df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398 4 com.apple.AppKit 0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115 5 com.apple.AppKit 0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56
With a lot of luck I finally found the reason for the crash. It’s caused by erasing a property tree (and inner QTreeWidget) together with an active focus on this widget. Unfortunately I’m not able to fix it in the QtCore because according to callstack there is only some QModelIndex manipulation without any sight of what’s going wrong.
The effective solution how to fix this wrong behaviour is to temporally set focus to another widget (or parent), clear the tree and set focus back to property tree. Unfortunately this solution doesn’t work. Check part II of this article for better solution
QWidget* pObject = qobject_cast<QWidget*>(m_propertyBrowser->parent());
if (pObject!=NULL);
pObject->setFocus();
m_propertyBrowser->clear();
m_propertyBrowser->setFocus();
If anyone know how to fix that, I will be glad for any info.
Error message:
wordpress update Could not create directory This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Solution:
#set persmissions for writing to all find -type d -print0 | xargs -0 chmod 777 find -type f -print0 | xargs -0 chmod 666 #revert back find -type d -print0 | xargs -0 sudo chown deploy find -type f -print0 | xargs -0 sudo chown deploy find -type d -print0 | xargs -0 chmod 755 find -type f -print0 | xargs -0 chmod 664 #set permissions to correct user sudo chown deploy ./wp-includes/js/tinymce/plugins/wpemoji/*
This error can be caused by many things but I know about one more which I didn’t find anywhere else ;-).
In case you compile and deploy your app by using qtmacdeploy and sign your application immediately, everything will probably works fine. The problem occurs, when you need to copy your application to different location (for example during dmg building). In such cases, this error can occur:
bundle format is ambiguous (could be app or framework)
Althought codesign is executed as always, singing isn’t successful:
codesign --deep --force --verbose --sign "$SIGNNAME" ./Skipper.app /path/Skipper.app/Contents/Frameworks/QtCore.framework: bundle format is ambiguous (could be app or framework)
The problem is, that during the copy it’s necessary to keep all symbolic links inside frameworks. Without this, singing will fail.
So instead of
cp -r ./Source ./Destination
it’s necessary to use
cp -R ./Source ./Destination
When user use ESC to close the dialog and press it very quickly two or more times in a row, QDialog::reject can be invoked also multiple times.
This is very dangerous and unpredictable because in case your reject will contain some one-time-execute routine the application will start crashing.
The only solution I found is to add these routines to QDialog destructor instead of to reject/accept.
curl -X POST --user user:apitoken http://server/job/JOB_NAME/build?delay=0sec
Api token:
http://server/user/USER_NAME/configure
