Problem with 'idb session save' in idbc using absolute paths

Problem with 'idb session save' in idbc using absolute paths

I think I've encountered a bug in the 'idb session save' command of idbc on Linux, but I'd like to get confirmation from users in other environments before declaring it as such.

I specified session_file with an absolute path, but idbc reports it tried to create the default $sessiondir. While this is not the intended behavior, at least the handling was graceful. If I try to do the same at a breakpoint in my program, it throws an error with stack trace due to an unexpected condition.

I have been able to work around the absolute path issue by setting $sessiondir to my preferred destination, but at present (in my environment) the documentation and idbc executable are not in sync.

Terminal example: (important lines in bold)

login2$ idbc diagonalize_8
Intel(R) Debugger for applications running on Intel(R) 64, Version 13.0, Build [79.936.23]
object file name: diagonalize_8
Reading symbols from /home1/02146/jblair42/bin/diagonalize_8...done.
(idb) break 371
Breakpoint 1.1 at 0x407b74: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 372.
Breakpoint 1.2 at 0x40800d: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 372.
(idb) break 403
Breakpoint 2 at 0x4080ed: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 404.
(idb) break 405
Breakpoint 3 at 0x408116: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 406.
(idb) break 423
Breakpoint 4.1 at 0x408955: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 424.
Breakpoint 4.2 at 0x409162: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 424.
(idb) break 435
Breakpoint 5.1 at 0x408cc0: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.2 at 0x408cde: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.3 at 0x408d0d: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.4 at 0x408d17: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.5 at 0x408d2d: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.6 at 0x408ecf: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.7 at 0x408f81: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
Breakpoint 5.8 at 0x408fad: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 436.
(idb) break 452
Breakpoint 6 at 0x409176: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 454.
(idb) break 438
Breakpoint 7.1 at 0x408d72: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 438.
Breakpoint 7.2 at 0x408fd2: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 438.
Breakpoint 7.3 at 0x408fe3: file /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90, line 438.
(idb) idb session save /home1/02146/jblair42/bin/idb_customizations.cmd
Cannot create session directory '/home1/02146/jblair42.idb/sessions/'.

(idb) run
Starting program: /home1/02146/jblair42/bin/diagonalize_8
[New Thread 22288 (LWP 22288)]
 Time to load hamiltonian into memory:  4.1000000E-03
 Size of Chunk:           2

Breakpoint 1.1, diagonalize () at /home1/02146/jblair42/src/diagonalize_parallel_csr_sym.f90:372
372      allocate(prodPart(dim_hamiltonian), stat=ierr2)
(idb) idb session save /home1/02146/jblair42/bin/idb_customizations.cmd
Assertion failed: "!savedSessionSaveState" ./src/ui/cmds/cmdsession.C:300
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.

/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_ZN15IDBAssertFailed3runEPKcS1_j+0xe) [0x61220e]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_ZN14DTLU_namespace12assertFailedEPKcS1_j+0x1e) [0xb671ce]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_ZN14CmdSessionSave5do_itER19CmdExecutionContextRN10BaseForCmd9CmdResultE+0xe5) [0xa17507]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_ZN10BaseForCmd7executeEb+0xfc5) [0x65e419]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb() [0x60fbf8]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_Z15ProcessCommandsv+0x54) [0x60ff08]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(__gxx_personality_v0+0x41d) [0x60dd25]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(_Z7idbMainiPPKcS1_+0x180) [0x60dfb6]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(main+0x3a) [0x60dcca]
/lib64/ [0x38cc81ecdd]
/opt/apps/intel/13/composer_xe_2013.2.146/bin/intel64/iidb(__gxx_personality_v0+0x232) [0x60db3a]

Linux info:
login2$ uname -a
Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I've tested this with several different programs. The behavior does not seem to be related to the program being run within idbc. Could someone else please test the 'idb session save' behavior and comment?

Thanks for your help

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

Dear Jonathan,

both of these behaviors  do look like a defect to me. The handling of the top level directory saving may actually just be a documentation defect, but either way I will double-check with our development team.

(idb) idb session save /home1/02146/jblair42/bin/idb_customizations.cmd
Cannot create session directory '/home1/02146/jblair42.idb/sessions/'.

followed by

"Assertion failed: "!savedSessionSaveState" ./src/ui/cmds/cmdsession.C"

is definitely a big concern though.

I know you state that you can reproduce it with any given application. For me to escalate it to our development team it would still be good if you could upload a small test case in a private message. Just to make sure we see the exact problem you are seeing.

Thanks, Rob

As a secondary note - In the following thread:

you may find details on us deprecating the Intel Debugger and putting a lot of development work into improving Fortran awareness in GDB instead. This will impact the priority we can give you reported issue above.It may be worth your while to have a look at our GDB implementation and the work we are doing with regards to Fortran with GDB.



Hi Robert,

Perhaps I need to buy a hat to eat because I just wrote a test loop as a program which does not result in the stack trace incident. This is not a general error, and I'm starting to get the feeling it may be related to the issue I was working to debug in my program. That issue is optimization level dependent, and for -O1 the issue seems to be in the Intel OpenMP library (segfault on _kmp_enter_single() in

I tried removing the big dependencies from my program, and the stack trace behavior stopped (still printed attempt to create default directory, though). I'm willing to forward my source and dependencies, but since I'm using a sparse matrix solver on top of Lapack and BLAS, I would like a second opinion on whether this is a severe enough case (for the Debugger) to warrant diagnosing the stack trace instance. Particularly since you pointed out that work on that front is waning.


Hi Rob,

I have narrowed down the stack trace issue and it's now simple and repeatable. After the warning "Cannot create session directory 'blah'" is issued, if you input 'idb session save /absolute/path/to/file' again, the stack trace is printed. Since this isn't tied to my bulky project and occured for a 17 line test program, I'll forward the test case to you in a PM with accompanying instructions to reproduce.


Thank you Jonathan,

I now have all the information to escalate it to our development team. I'll give you our defect tracking number in a separate message and will keep you posted on the development team feedback.

In the meantime have you had a chance to look at and the improvements around Fortran debug in our own Intel enhanced GDB? Is that something you would be interested in?


Thanks, Rob


Leave a Comment

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