- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since there's no forum for thread checker, I'll post here.
I run tcheck_cl but it just hangs a bit into the application initialization. Strace shows an infinite loop with these calls being made:
1187212293.249620 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1187212293.249677 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
gdb shows the following backtrace:
#0 0x0000002a95676913 in pthread_sigmask () from /lib64/tls/libpthread.so.0
#1 0x0000002a95d3655c in __kmd_monitor_exit () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#2 0x0000002a95d0d039 in __kmdc_run () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#3 0x0000002a95d0d7d8 in __kddc_run () from /.../tcheck/bin/32e//libassuret40.so
#4 0x00000000007a25b5 in std::_Rb_tree_iterator<:PAIR> > >::operator== (this=0x7fbffe24d8,
__x=@0x7fbffe24c0) at stl_tree.h:209
#5 0x0000000000816bc9 in std::_Rb_tree >, std::_Select1st<:PAIR> > >, std::less, std::allocator<:PAIR> > > >::find (this=0x7fbffed3c0,
__k=@0x7fbffe2730) at stl_tree.h:1108
#6 0x000000000080fad5 in std::map, std::less, std::allocator<:PAIR> > > >::find (this=0x7fbffed3c0, __x=@0x7fbffe2730) at stl_map.h:498
I've read the FAQ and it says that Intel thread checker does not work w/ staticly linked pthreads library. But I checked and my app links against the libpthreads.so dynamically so this shouldn't be a problem.
Has anybody seen anything like this issue before?
FYI, I'm using ZThreads as a convenience interface on top of pthreads.
Thanks for any help!
-Matt
I run tcheck_cl
1187212293.249620 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1187212293.249677 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
gdb shows the following backtrace:
#0 0x0000002a95676913 in pthread_sigmask () from /lib64/tls/libpthread.so.0
#1 0x0000002a95d3655c in __kmd_monitor_exit () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#2 0x0000002a95d0d039 in __kmdc_run () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#3 0x0000002a95d0d7d8 in __kddc_run () from /.../tcheck/bin/32e//libassuret40.so
#4 0x00000000007a25b5 in std::_Rb_tree_iterator<:PAIR>
__x=@0x7fbffe24c0) at stl_tree.h:209
#5 0x0000000000816bc9 in std::_Rb_tree
__k=@0x7fbffe2730) at stl_tree.h:1108
#6 0x000000000080fad5 in std::map
I've read the FAQ and it says that Intel thread checker does not work w/ staticly linked pthreads library. But I checked and my app links against the libpthreads.so dynamically so this shouldn't be a problem.
Has anybody seen anything like this issue before?
FYI, I'm using ZThreads as a convenience interface on top of pthreads.
Thanks for any help!
-Matt
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, actually there is a general forum for discussing Threading issues on Intel Architectures. Here is the link: http://software.intel.com/en-us/forums/. So this discussion would fit there better. Also Thread Checker is a commercial product, which means that its users are entitled to have technical support througth http://premier.intel.com.
regards,
Anton
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Matthew Gumbel (Intel)
Since there's no forum for thread checker, I'll post here.
I run tcheck_cl but it just hangs a bit into the application initialization. Strace shows an infinite loop with these calls being made:
1187212293.249620 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1187212293.249677 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
gdb shows the following backtrace:
#0 0x0000002a95676913 in pthread_sigmask () from /lib64/tls/libpthread.so.0
#1 0x0000002a95d3655c in __kmd_monitor_exit () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#2 0x0000002a95d0d039 in __kmdc_run () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#3 0x0000002a95d0d7d8 in __kddc_run () from /.../tcheck/bin/32e//libassuret40.so
#4 0x00000000007a25b5 in std::_Rb_tree_iterator<:PAIR> > >::operator== (this=0x7fbffe24d8,
__x=@0x7fbffe24c0) at stl_tree.h:209
#5 0x0000000000816bc9 in std::_Rb_tree >, std::_Select1st<:PAIR> > >, std::less, std::allocator<:PAIR> > > >::find (this=0x7fbffed3c0,
__k=@0x7fbffe2730) at stl_tree.h:1108
#6 0x000000000080fad5 in std::map, std::less, std::allocator<:PAIR> > > >::find (this=0x7fbffed3c0, __x=@0x7fbffe2730) at stl_map.h:498
I've read the FAQ and it says that Intel thread checker does not work w/ staticly linked pthreads library. But I checked and my app links against the libpthreads.so dynamically so this shouldn't be a problem.
Has anybody seen anything like this issue before?
FYI, I'm using ZThreads as a convenience interface on top of pthreads.
Thanks for any help!
-Matt
I run tcheck_cl
1187212293.249620 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1187212293.249677 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
gdb shows the following backtrace:
#0 0x0000002a95676913 in pthread_sigmask () from /lib64/tls/libpthread.so.0
#1 0x0000002a95d3655c in __kmd_monitor_exit () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#2 0x0000002a95d0d039 in __kmdc_run () from /.../intel/itt/tcheck/bin/32e//libassuret40.so
#3 0x0000002a95d0d7d8 in __kddc_run () from /.../tcheck/bin/32e//libassuret40.so
#4 0x00000000007a25b5 in std::_Rb_tree_iterator<:PAIR>
__x=@0x7fbffe24c0) at stl_tree.h:209
#5 0x0000000000816bc9 in std::_Rb_tree
__k=@0x7fbffe2730) at stl_tree.h:1108
#6 0x000000000080fad5 in std::map
I've read the FAQ and it says that Intel thread checker does not work w/ staticly linked pthreads library. But I checked and my app links against the libpthreads.so dynamically so this shouldn't be a problem.
Has anybody seen anything like this issue before?
FYI, I'm using ZThreads as a convenience interface on top of pthreads.
Thanks for any help!
-Matt
I had the same problem, and it was solved by using the "--noinstrument" flag with tcheck_cl.
Hope this helps.

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