- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Understanding the support, if any, in Inspector XE to mask detecting use of recycled memory by third party memory managers as data sharing violations.
Firstly, did such support make it into the latest release? If so, can someone shed any details. Thanks!
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel Inspector XE 2011 can detect memory errors & thread errors in all modules at runtime (native code only), including 3rd-party libraries, system libraries, etc. This is default operation.
The user can select all modules in report, or select interest of module in report, like as below.
![](/skins/images/8492E06DAD1A420837AF16E991F628F9/2021_redesign/images/image_not_found.png)
Regards, Peter
The user can select all modules in report, or select interest of module in report, like as below.
![](/skins/images/8492E06DAD1A420837AF16E991F628F9/2021_redesign/images/image_not_found.png)
Regards, Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting rachidh
Firstly, did such support make it into the latest release? If so, can someone shed any details. Thanks!
Hi,
Not at the moment. You might have found some user API functions in the ittnotify.h that are similar to what youre asking for. However, we do not claim support of that functionality for the current release.
Please, provide your particular examples on how you think the 3-rd party/custom memory managers have to be supported by Inspector XE, just for better understanding of what you expect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel Inspector XE uses a race detection algorithm that correctly recognizes the use of mutexes to perform ownership transfers.
If the third party memory manager is thread safe and correctly synchronized with system APIs then we will recognize that the thread that frees the memory and the thread that later allocates (recycles) the memory acquired the lock protecting the memory manager in a well defined order. We will not report a race on the recycled memory.
If Inspector XE is reporting races on data that is managed by a third-party memory manager then there are three possibilities:
1. there is actually a race in the program.
2. the third-party memory manager has a synchronization bug.
3. the third-party memory manager is correctly synchronized, but is using hand-crafted synchronization routines that Inspector XE is not automatically recognizing as being synchronization routines.
The best thing to do in thelast case is to "teach" Inspector XE about the synchronization routines using the itt annotation API. (The same API that was available in Thread Checker 3.1).
If the third party memory manager is thread safe and correctly synchronized with system APIs then we will recognize that the thread that frees the memory and the thread that later allocates (recycles) the memory acquired the lock protecting the memory manager in a well defined order. We will not report a race on the recycled memory.
If Inspector XE is reporting races on data that is managed by a third-party memory manager then there are three possibilities:
1. there is actually a race in the program.
2. the third-party memory manager has a synchronization bug.
3. the third-party memory manager is correctly synchronized, but is using hand-crafted synchronization routines that Inspector XE is not automatically recognizing as being synchronization routines.
The best thing to do in thelast case is to "teach" Inspector XE about the synchronization routines using the itt annotation API. (The same API that was available in Thread Checker 3.1).
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page