IDB (Linux) locks running program when OMP_NUM_THREADS>1

IDB (Linux) locks running program when OMP_NUM_THREADS>1

I have IDB v13.0 running on Linux. When debugging  correct OpenMP threaded programs, the program being debugged always  hangs under IDB. That is, the program appears to have stopped running, and I have to break into IDB to see where it is stuck. Always the same place...

_ZN34_INTERNAL_12_src_pdbx_cpp_67bc0b7b4pdbx2io17log_communicationEv ()        libpdbx.so.5    0x00002B30D48AEB75
_ZN4pdbx6pdbx_t9configureEv ()        libpdbx.so.5    0x00002B30D48A824E
_ZN4pdbx6pdbx_t11synchronizeERKNS_6syncidE9mem_orderPKv ()        libpdbx.so.5    0x00002B30D48ACD8F
__itt_sync_acquired ()        libpdbx.so.5    0x00002B30D48BC4EC
_Z18__kmp_fork_barrierii ()        libiomp5.so    0x00002B30D23014A3
__kmp_internal_fork ()        libiomp5.so    0x00002B30D2300047
__kmp_fork_call ()        libiomp5.so    0x00002B30D22FC6A1

 

If I set OMP_NUM_THREADS=1, IDB functions as expected and the running program runs to completion.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hello,

could it be that the debugger does not hang but is slowed down? Did you enable PDBX in IDB (idb sharing on)? If yes, this is slowing down the execution because of tracking memory accesses. You can also find out the status of PDBX via idb sharing status.

Maybe you compiled your application with -debug parallel without intending to use PDBX. This option can involve additional communication to an attached debugger, even though PDBX is disabled.

With Intel(R) Composer XE 2013 SP1 we're providing an improved version of GNU* GDB (gdb-ia) that replaces IDB. This one also has PDBX support, which can be enabled via pdbx enable. Some more information can be found here:
http://software.intel.com/en-us/articles/debugging-intel-xeon-phi-applications-on-linux-host#Data%20Race%20Detection
(this article is for debugging Intel® Xeon Phi™ applications, but the data race detection is the same as for the host)

Finally, I'd like to formally mention that IDB has been deprecated and won't be available with the next major version following Intel(R) Composer XE 2013 SP1:
http://software.intel.com/en-us/forums/topic/489196
Please try our GDB version instead and let me know whether this helps.

Thank you & best regards,

Georg Zitzlsberger

The program was not compiled -debug parallel ( see below)

"idb) idb sharing off
The "idb sharing off" command has failed because the executable is not linked with libpdbx.so. Try rebuilding your executable with the option "-debug parallel".

It is not just running slow, it appears to be simply stuck although all CPUs are running 100%. Breaking into the code shows the same location always.

"Serialize Execution" also makes the issue go away.

When IDB ( and presumably) IDB-GUI is retired what GUI debugger do we use? Don't make me go back to the command-line!

Hello,

I guess I see what's wrong. Did you link libpdbx.so.5 somehow to your application (please check "ldd <application>").
If this library gets linked to an application w/o telling the compiler you might face a (massive) slowdown.
Could you please check this? If that's the case, please omit that library.

Although we continue to work only with GDB, you can use Eclipse* IDE (CDT) as a GUI interface for gdb-ia. The only disadvantage is that extensions we added to GDB (PDBX, BTRACE, ...) won't be directly accessible in the GUI.

Thank you & best regards,

Georg Zitzlsberger

Hi Georg,

libpdbx.so.5 is not linked in, confirmed by ldd
 

That's kind of bad news regarding lack of a Intel supported GUI for gdb-ia. 

Andrew

Hello,

we've found the root cause:
For the "idb" script $INTEL_LIBITTNOTIFY32 & $INTEL_LIBITTNOTIFY64 were set. Please replace those by the following two lines:

export INTEL_LIBITTNOTIFY64=""
export INTEL_LIBITTNOTIFY32=""

 

If you use "idbc", please add the following three lines on top (after INSTALLDIR=...):

export INTEL_ITTNOTIFY_GROUPS=sync
export INTEL_LIBITTNOTIFY64=""
export INTEL_LIBITTNOTIFY32=""

This is a problem within the official startup-scripts. Unfortunately we won't be able to fix that because there's no more update in time and with the next major version IDB will go away.

Even though you've unset those variables, PDBX (the data race detector) will still work, provided that you compiled your application with -debug parallel.

I hope that solves your problem!

Thank you very much for your patience & best regards,

Georg Zitzlsberger

Leave a Comment

Please sign in to add a comment. Not a member? Join today