Have Geek Brain

Error that is not displayed when debugger is connected

I am using Intel FORTRAN compiler to compile a numeric library. The test case contains errors in libc.so.6. When I attach the Intel Debugger (IDB), the application runs successfully. How do I debug an error where the debugger is preventing the error? Note that the same error occurred with gfortran.

I am working on OpenSUSE 11.2 x64.

Error:

forrtl: strong (408): fort: (3): Subscript 1 of array B has a value of -534829264, which is less than lower bound 1

+2


a source to share


2 answers


The error message is pretty clear to me, you are trying to access a non-existent array element. I suspect the value -534829264 is either undesirable when you use an uninitialized variable to identify an element in an array, or the result of an integer arithmetic overflow. In any case, you must enable the compile flag to force the bounds of the array and run some tests. I think there will be a flag for the Intel compiler -CB

, but check the documentation.

As to why the program appears to work successfully in the debugger, I can't help much, but perhaps the debugger is overlaying some default values ​​for variables that the runtime system itself doesn't do. Or some other factor is entirely responsible.

EDIT:



Does the runtime system show you which line of code is causing the problem? A few more things to try and diagnose the problem. Use a compiler to warn you about

  • using variables before their initialization;
  • integer arithmetic overflow (not sure if the compiler can figure this out?);
  • any forced conversions from one type to another and from one kind to another in the same type.

Also, make sure the default integer size is what you expect from it and, more importantly, what all your code expects from it.

+3


a source


Not an expert in the field, but a few things to consider:

1) The debugger first initializes the variable used as an index, but debug does not, and so the variable starts with the value "garbage" (if old version of Pascal was used before).



2) Are you using thread? If so, then debugging changes the order of execution, so some preparatory threads are terminated in time.

+1


a source






More articles:


All Articles