idb SIGBUS

idb SIGBUS

Could someone please example while the following code generates a SIGBUS when stepped through using idb?

Here is the complete sequence of steps. Code is shown at the end of the post.

MacBookPro 5% ifort -g -132 -save-temps -traceback -o testcase ./testcase.f
MacBookPro 6% idb testcase
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.319]
------------------ 
object file name: testcase 
Reading symbols from /Users/jchauvin/Desktop/intel_debug_test/testcase...done.
(idb) break main
Breakpoint 1 at 0x100000b79: file /Users/jchauvin/Desktop/intel_debug_test/testcase.f, line 14.
(idb) run
Starting program: /Users/jchauvin/Desktop/intel_debug_test/testcase

Breakpoint 1, main () at /Users/jchauvin/Desktop/intel_debug_test/testcase.f:14
14	      aString='abcd'
(idb) step
(idb) step
(idb) step
(idb) step
(idb) step
(idb) step
(idb) step
(idb) step
Program received signal SIGBUS

Here is the code:

      PROGRAM Main
      
      IMPLICIT NONE
C     ..
C     .. Local Scalars ..
      DOUBLE PRECISION results
      CHARACTER*4 aString
C     ..
C     .. External Function ..
      DOUBLE PRECISION Test_Function
C     ..
C     .. Executable Statements ..
               
      aString='abcd'

      results = Test_Function(aString)

      STOP
      
      END 
      DOUBLE PRECISION Function Test_Function(aString)

      IMPLICIT NONE
C     ..
C     .. Scalar Arguments ..
      CHARACTER*4 aString
C     ..
C     .. Local Scalars ..
      DOUBLE PRECISION var3
C     ..
C     .. Executable Statements ..
                                           
      IF (aString.EQ.'abcd') THEN
          var3 = 650.0D0
      END IF
      
      Test_Function = var3
      
      RETURN
      END

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

Thanks for the simple example, it really helped.

2 things on compilation:
1) source /opt/intel/Compiler/11.1/080/bin/ifortvars.sh intel64
2) add -gdwarf-2 to compilation AND -O0 (to prevent inlining of the external function)
ifort -g -traceback -132 -save-temps -gdwarf-2 -o testcase testcase.f -O0

IDB:
Next, use 'next' command to advance to next instruction and 'step' when you want to step into a function:

fordprefect:70978 rwgreen$ idb testcase
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.319]
------------------
object file name: testcase
Reading symbols from /Users/rwgreen/quads/forums/70978/testcase...done.
(idb) break 14
Breakpoint 1 at 0x100001389: file /Users/rwgreen/quads/forums/70978/testcase.f, line 14.
(idb) run
Starting program: /Users/rwgreen/quads/forums/70978/testcase

Breakpoint 1, main () at /Users/rwgreen/quads/forums/70978/testcase.f:14
14 aString='abcd'
(idb) next
16 results = Test_Function(aString)
(idb) step
test_function (astring=(...), .tmp.ASTRING.len_V$e=4) at /Users/rwgreen/quads/forums/70978/testcase.f:33
33 IF (aString.EQ.'abcd') THEN
(idb) next
34 var3 = 650.0D0
(idb) next
37 Test_Function = var3
(idb) next
39 RETURN
(idb) next
40 END
(idb) next
main () at /Users/rwgreen/quads/forums/70978/testcase.f:16
16 results = Test_Function(aString)
(idb) next
18 STOP
(idb) next
Program exited normally.

Quoting - Ronald W. Green (Intel)
Thanks for the simple example, it really helped.

2 things on compilation:
1) source /opt/intel/Compiler/11.1/080/bin/ifortvars.sh intel64
2) add -gdwarf-2 to compilation AND -O0 (to prevent inlining of the external function)
ifort -g -traceback -132 -save-temps -gdwarf-2 -o testcase testcase.f -O0

IDB:
Next, use 'next' command to advance to next instruction and 'step' when you want to step into a function:

fordprefect:70978 rwgreen$ idb testcase
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.319]
------------------
object file name: testcase
Reading symbols from /Users/rwgreen/quads/forums/70978/testcase...done.
(idb) break 14
Breakpoint 1 at 0x100001389: file /Users/rwgreen/quads/forums/70978/testcase.f, line 14.
(idb) run
Starting program: /Users/rwgreen/quads/forums/70978/testcase

Breakpoint 1, main () at /Users/rwgreen/quads/forums/70978/testcase.f:14
14 aString='abcd'
(idb) next
16 results = Test_Function(aString)
(idb) step
test_function (astring=(...), .tmp.ASTRING.len_V$e=4) at /Users/rwgreen/quads/forums/70978/testcase.f:33
33 IF (aString.EQ.'abcd') THEN
(idb) next
34 var3 = 650.0D0
(idb) next
37 Test_Function = var3
(idb) next
39 RETURN
(idb) next
40 END
(idb) next
main () at /Users/rwgreen/quads/forums/70978/testcase.f:16
16 results = Test_Function(aString)
(idb) next
18 STOP
(idb) next
Program exited normally.

Thanks for the reply. Do I type the following command in the terminal window? What exactly is this command doing?

source /opt/intel/Compiler/11.1/080/bin/ifortvars.sh intel64

According to the manual, the -g option should automatically generate debug information using the DWARF2 format.
Why do I have to call it out explicitly (and how would I know to do it in the first place)

Thanks for the help

Quoting - chauvjo

Thanks for the reply. Do I type the following command in the terminal window? What exactly is this command doing?

source /opt/intel/Compiler/11.1/080/bin/ifortvars.sh intel64

According to the manual, the -g option should automatically generate debug information using the DWARF2 format.
Why do I have to call it out explicitly (and how would I know to do it in the first place)

Thanks for the help

The source command sets up your path and library paths correctly to ensure that you get the 64bit compiler from version 11.1.080. Without this, you pick up the 'ifort' command from /usr/bin - this USUALLY isn't a problem, and the compiler SHOULD default to 64bit mode, but if you have multiple versions of the compiler on the system, the source command insures you get the exact version you desire. It also sets up paths for MKL and IDB. In short, I use it as a safety measure to insure that I get exactly the compiler, MKL, and IDB I expect.

-gdwarf-2 vs -g : you are correct, -g sets dwarf2 correctly. There was a time in distance past when you needed it for the Mac compiler, but no longer.

Quoting - Ronald W. Green (Intel)

The source command sets up your path and library paths correctly to ensure that you get the 64bit compiler from version 11.1.080. Without this, you pick up the 'ifort' command from /usr/bin - this USUALLY isn't a problem, and the compiler SHOULD default to 64bit mode, but if you have multiple versions of the compiler on the system, the source command insures you get the exact version you desire. It also sets up paths for MKL and IDB. In short, I use it as a safety measure to insure that I get exactly the compiler, MKL, and IDB I expect.

-gdwarf-2 vs -g : you are correct, -g sets dwarf2 correctly. There was a time in distance past when you needed it for the Mac compiler, but no longer.

Reviewing your suggestions, only theuse of the 'next' command to advance to next instruction and 'step' when you want to step into a function solved the problem. On other systems, I have been able to step into the code behind a specific fortran statement (i.e. like WRITE) to pinpoint a problem. Is this not a option with the Intel compiler? Doesn't the factor that an error occur while stepping "behind the code" indicate some type of bug?

Quoting - chauvjo

Reviewing your suggestions, only theuse of the 'next' command to advance to next instruction and 'step' when you want to step into a function solved the problem. On other systems, I have been able to step into the code behind a specific fortran statement (i.e. like WRITE) to pinpoint a problem. Is this not a option with the Intel compiler? Doesn't the factor that an error occur while stepping "behind the code" indicate some type of bug?

When I used 'step' like in your first post I never got a sigbus. I just kept going. What I THINK is happening is that we started stepping one asm instruction at a time, hence no source lines are shown. But I kept stepping maybe 30 times more than in your example with no sigbus.

I'll have someone from the IDB team take a look.

ron

Quoting - chauvjo

Reviewing your suggestions, only theuse of the 'next' command to advance to next instruction and 'step' when you want to step into a function solved the problem. On other systems, I have been able to step into the code behind a specific fortran statement (i.e. like WRITE) to pinpoint a problem. Is this not a option with the Intel compiler? Doesn't the factor that an error occur while stepping "behind the code" indicate some type of bug?

Hmmm - just a few comments that I hope are helpful in this discussion.

I think the question is whether you have symbol info for the Fortran library functionsl like write. If you do, then step shouldstep into the function and allowyou to continue stepping in it.

As Ron pointed out "next" does a step over such a function call, whereas "step" would step into it and allow you to step inside it.

If you do not have full symbol info for the library or shared object where write() is defined however you will be stepping into assembly code. The first step into the function header should be ok, but the next step will try to reach a Fortran source line that is not present and if the code is nested it may loose the callstack and not know how to get back again. In that scenario you could use stepi or nexti to step through the function call using assembly level steps until your write() function returns.

I am not saying that there could not be some defect in compiler or debugger here, but stepping behavior is such a standard functionality that Iwould be srurprised if something got broken there.

What is confusing to me is that the SIGBUS signal seems to have a dependency on how you step. This would indicate that you may be stepping into a protected memory area or such ..... which is odd even if you step into code without symbol info and involuntarily end up doing a run ....

Quoting - Robert MuellerAlbrecht (Intel)

Hmmm - just a few comments that I hope are helpful in this discussion.

I think the question is whether you have symbol info for the Fortran library functionsl like write. If you do, then step shouldstep into the function and allowyou to continue stepping in it.

As Ron pointed out "next" does a step over such a function call, whereas "step" would step into it and allow you to step inside it.

If you do not have full symbol info for the library or shared object where write() is defined however you will be stepping into assembly code. The first step into the function header should be ok, but the next step will try to reach a Fortran source line that is not present and if the code is nested it may loose the callstack and not know how to get back again. In that scenario you could use stepi or nexti to step through the function call using assembly level steps until your write() function returns.

I am not saying that there could not be some defect in compiler or debugger here, but stepping behavior is such a standard functionality that Iwould be srurprised if something got broken there.

What is confusing to me is that the SIGBUS signal seems to have a dependency on how you step. This would indicate that you may be stepping into a protected memory area or such ..... which is odd even if you step into code without symbol info and involuntarily end up doing a run ....

Robert,

I am not familiar with the libraries available on the Mac operating system but would assume Intel would have detail information. What does your Mac expert say on this topic? Is my executable linked to different libraries when I select the -g compiler option? Since I have seen detailed tracebacks in the Console window, it would appear to me that this is possible but again you are the experts. Ron mentioned that he never got a SIGBUS while stepping. Did he run this on a Mac? It would be helpful, if you run your test cases on a Mac. Telling me that something works under Linux is not much help unfortunately. Thanks....

Leave a Comment

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