LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Any way to jump to program crash point? (https://www.linuxquestions.org/questions/programming-9/any-way-to-jump-to-program-crash-point-539616/)

johnpaulodonnell 03-22-2007 07:25 AM

Any way to jump to program crash point?
 
Hi.

When I run an executable I have I am getting a segmentation fault - code itself (fortran 90) compiles fine with intel fortran compiler...

I am trying out various things to fix this segmentation fault, but thing is I have to wait about 90 minutes each time I change something to see if fault is still there (which it invariably is!), as this is when the crash occurs...

Also I cannot run multiple versions at the same time as ~ 1Gb is required to run the code at all...

So as a question is there any known general way to get around this waiting?

thanks

wjevans_7d1@yahoo.co 03-22-2007 10:29 AM

I think the answer to the actual question is "No, there is nothing you can do."

But there's more to this. I've had stuff like this happen, and rather than "trying out various things" to see if the problem goes away, it's usually best to understand the underlying problem thoroughly.

To do this, copy to one side the current version of what you're running. Then do a split-the-difference sort of simplification.

The first step is to rip out half of the program and throw it away. Run what's left and see if you still get the problem.

If you do, then rip out half of what remains.

If the problem went away, take the original program and either rip out just a quarter of it, or find another way to rip it in half (some other code that comprises half of the source), and rerun it.

Keep going until you have the simplest possible program which reproduces the bug. It will be much easier to find the problem.

It sounds tedious. But:
  1. Simplifying the program until you understand the problem is likely to take maybe a week or two, rather than months (if not forever).
  2. Even if you did "try out various things" and found something that caused the symptom to go away, but you don't know exactly why, it's very likely that the underlying problem is still there, and is manifesting itself elsehow, including the possibility of outputting results that look reasonable but are wrong.

In your case, perhaps the best half to remove first is the half which, when removed, causes your execution time to drop dramatically, so you don't spend so much time waiting for a test to complete. (grin)

Hope this helps.

bigearsbilly 03-22-2007 10:51 AM

do you get a core dump?

can you use gdb?

with a core dump you can read where the dump occured.

johnpaulodonnell 03-22-2007 10:57 AM

learning how to use gdb at the minute...very basic commands though.

Do I need to produce a core dump? Can gdb obtain more info from the core dump than it can form just passing it the executable?

I don't know alot about this stuff!

bigearsbilly 03-22-2007 11:00 AM

yeah, I can't remember exactly but
something like
gdb executable corefile

then type where (i think)
and it takes you directly to where the crash occurred.
easy-peasie lemon squeezy.

try using ddd which is a lovely graphical interface to gdb.
really nice.

johnpaulodonnell 03-22-2007 11:03 AM

Thanks Billy.

Will give it a shot

johnpaulodonnell 03-27-2007 06:32 AM

intel debugger (idb) has a facility that allows you to take a 'snapshot' of the process at a chosen place...then if you accidentally move the process forward beyond where the crash occurs, you can revert to the position of the 'snapshot', and debug further...


All times are GMT -5. The time now is 03:13 AM.