Qt Support during Thread Error Analysis

[Stefan_S_]

Hi everyone,

we are evaluating Inspector XE and we have made a few successful test runs. However we get a lot of false positives regarding Qt.
Regarding to this site: http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/inspectorxe/lin/ug_docs/GUID-46AF40B7-E211-47E3-9D91-C03894575EA0.htm the inspector should be able detect the Qt-APIs we are using. Although we are also using QMutexLocker, but since this is only a convenient wrapper for QMutex it should be fine.

So my first assumption is that it has something to do with the fact that we are compiling Qt ourselves, instead of using the binaries from Qt itself. As far as i know our Qt source derives from version 4.7. My thought is that our Qt compile is missing something. So my first question is: How does the inspector recognize the Qt locking mechanisms?

Furthermore is there a way to "teach" the inspector to recognize a certain locking mechanism? We also have a custom spinlock and it would be nice if inspector doesn't list it as a false positive.

[Bernard]

>>>Qt-APIs>>> What does it mean?

[Mark_D_Intel]

For the last question, to inform Inspector about your lock, look in the help under the "User-defined Synchronization API" section. http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/inspectorxe/lin/ug_docs/index.htm#GUID-46AF40B7-E211-47E3-9D91-C03894575EA0.htm Inspector recognizes QMutex by function name (QMutex::lock, or the mangled version, _ZN6QMutex4lockEv ). Check that this function name is available in your Qt libraries. Also, are you compiling dynamically? If the Qt libraries are linked statically, Inspector will not be able to instrument them.

[Bernard]

>>>For the last question, to inform Inspector about your lock, look in the help under the "User-defined Synchronization API" section>>> Thanks.

[Stefan_S_]

@iliyapolak: With "Qt-APIs" I meant the Qt synchronization classes like QMutex, QReadWriteLock, QSemaphore. @mark-dewing: The help article you provided seems promising. I will definitly try that later. We are linking Qt dynamically, so that should be fine. I checked the function name with Dependency Walker, to make sure that the functions are really in the DLL: Mangled: ?lock@QMutex@XYZ@@QAEXXZ Unmangled: void XYZ::QMutex::lock(void) Where XYZ is the name of our global namespace. Is it allowed to have a surrounding namespace or does this cause a problem? Also the mangled version does not look like yours at all. Maybe thats because of different compiler or different compiler options. I think we are on the right track now. I will be looking further into it.

[Mark_D_Intel]

Yes, the global namespace is likely the problem. ( The mangled name I gave was for Linux. For Windows, its ?lock@QMutex@@QAEXXZ .) Two possible solutions are 1. Compile Qt w/o the global namespace (Although this might be too involved a change to be feasible) 2. Add the user synchronization APIs to the Qt code For using the user synchronization API's, here's the link for the Windows documentation for the section on headers and libraries that is OS specific. (The previous links in this thread are to the Linux documentation) http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/inspectorxe/win/ug_docs/GUID-CB37212F-2387-4A2A-94A1-7F0AE3EA5C38.htm

[Stefan_S_]

Ok, I pretty much figured the 2 possible solutions out myself ... I already tried the first one. At first it worked really smooth, but it required to rebuild everything, which takes a lot of time. So later on I unavoidably came to a DLL which I don't have the source code, but which also required the QtCore-DLL with the XYZ namespace. So I got stuck. For now I'm trying to do it the second way, but that will take some time. I'll keep you informed.