Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Stefan_S_
Beginner
121 Views

Qt Support during Thread Error Analysis

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/GUI... 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.

0 Kudos
6 Replies
Bernard
Black Belt
121 Views

>>>Qt-APIs>>> What does it mean?
Mark_D_Intel
Employee
121 Views

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/ind... 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
Black Belt
121 Views

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

@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
Employee
121 Views

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/GUI...
Stefan_S_
Beginner
121 Views

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.
Reply