My program seg faults

Hey all,

I am having some segmentation issues. Basically main() reads in a text file, and stores the necessary information in a 2d array. It reads and passes the necessary information to FindPath() on a line-by-line basis.

Sample input file:

Code:

---

2
4
1 2 4 2 2 2
2 1 4 2 2 3
2 2 4 2 2 1
-1 -1 -1 -1 -1 -1

---

First line is saying I have a 2x2 grid map and the second a 4 tracks. The remaining three strings of numbers are basically description of element placements on the 2x2 map. Example: 1 2 4 2 2 2 says element (1,2) has outlet 4 connected to inlet 2 of element (2,2). This file can of course have hundreds of such lines describing element placement. -1 -1...-1 means the end of the file

When main() successfully passes the third line (1 2 4 2 2 2), the called function to an extent does its job, but there is a seg fault before the main() can pass the information of the remaining lines to the called function.

Source code: C pastebin - collaborative debugging tool
Sample output:

Code:

---

grid is 2
main passing 1,2  2,2
 parentXval is 1 parentYval is 2
a = 0. b = 1
Cost 0,1 is 44
a = 1. b = 1
Cost 1,1 is 30
a = 2. b = 1
a = 0. b = 2
Cost 0,2 is 30
a = 1. b = 2
a = 2. b = 2
Cost 2,2 is 10
a = 0. b = 3
a = 1. b = 3
a = 2. b = 3
Parent is 1,2
Logical length from 1,2 is 1
Segmentation fault

---

Any help would be appreciated.

Well, the elementary step in tracking a seg fault is to run the executable thru a debugger. It will tell you the instruction during which the seg fault occurred.

Using gcc and gdb, compile:

gcc -g mycode.c

Then:

gdb ./a.out

where "a.out" is the executable name. When the prompt appears, type "run". The program will run and you will be told exactly where the seg fault occurs.

That's step number one. Until you do that, you are mostly just wasting time making guesses, etc.

I get this when it seg faults. But it really doesnt help me:

Quote:

---

received signal SIGSEGV, Segmentation fault.
0xb7e16288 in __uflow () from /lib/tls/i686/cmov/libc.so.6

---

You didn't think it would help anyone if you actually posted a small [not]working example?


Quzah.

How about, when you run it in the debugger and it segfaults, you type

Code:

---

where

---

so that you get a stack trace of your crash location. That will help pin down the cause.

So, like MK27 said, but we'll add some warnings too; we may find a hint there:

Code:

---

gcc -g -Wall -pedantic -std=c99 mycode.c

---

Now open the program in the debugger:

Code:

---

gdb ./a.out

---

Then set the argument you require

Code:

---

set args myfile.txt

---

Now run the program:

Code:

---

run

---

When it crashes type:

Code:

---

where

---

And you should get a full stack trace. Copy and paste the full stack trace here.

rags_to_riches, thank you for that quick tutorial. I was able to get some meaningful output, much better than I posted previously.
After running run:

Code:

---

Program received signal SIGSEGV, Segmentation fault.
0x0804a0fc in FindPath (startingX=2, startingY=2, targetX=2, targetY=2) at online.c:252
252                        whichList[a][b] = onOpenList;

---

After running where:

Code:

---

#0  0x0804a0fc in FindPath (startingX=2, startingY=2, targetX=2, targetY=2) at online.c:252
#1  0x0804a7c4 in main (argc=Cannot access memory at address 0x25
) at online.c:455

---

This happens when I run with an input file with the contents of post number #1. Here is a one liner that does work (no seg faults):

Code:

---

5
10
1 3 4 5 4 2
-1 -1 -1 -1 -1 -1

---

Updated code: C pastebin - collaborative debugging tool

I see that the values of a or b are greater than 100+ when the program crashes (line 252; the array is usually smaller than this). The values are not suppose to exceed the array size. I am unable to post the output from gdb (too much), so if you are able to run the code and go through the output, that would be of great help

This is a pretty simple problem. You never check to see if k walks off the end of your array.

Edit: Actually you have all sorts of terrible practices here. Which is especially poor when you're trying to find out what's wrong. You always seem to assume your input is valid. There aren't any boundary checks for startX and startY, and you have a million variables in there--most of which don't seem to be used, at a glance. You need to trim all the extra crap out of your program and get it in a nice, clean, readable state. It's not that you have a terrible style, you just have a ton of seemingly unused stuff. You also apparently forgot the type of a bunch of variables. You really need to compile with warnings on.


Quzah.

quzah, please elaborate. 'k' is only used in main() as is incremented.

Yep, it's incremented. You don't seem to care how many times it gets incremented though. You never check the upper boundary. You just keep incrementing it. Now that my not be the issue in this case, if your data set has say only five valid lines (because you have a massive array you're using) -- but it's still a lousy habit.

You need to stop assuming things are all valid input--that's why you get segfaults. You need to start testing all of your input to see that it will fit in the bounds of the arrays you are trying to use.

Also, 'FindPath' is enormous. You should consider breaking it up into smaller manageable tasks (functions).


Quzah.

Okay, I have changed line 165 to:

Code:

---

if (a > 0 && b > 0 && a <= grid.map_xy && b <= grid.map_xy)

---

so that if a and b are out of bounds, then it should not use those values. It no longer seg faults using the inputs from post #1. However when I try to feed it more inputs (different input file), it seg faults, but at a different location: pastebin - collaborative debugging tool

Using gdb, it seg faults at line 341:
tempx = parentX[pathX][pathY];
The weird thing is that line 337, where pathX is changed, does really get changed. gdb shows that targetX has a value of 4, but pathX has a value of -1209380337. This value of pathX never changes even as lines 341-343 gets executed.

Code:

---

Program received signal SIGSEGV, Segmentation fault.
0x0804a478 in FindPath (startingX=2, startingY=5, targetX=4, targetY=3) at online.c:341
341                        tempx = parentX[pathX][pathY];       

#0  0x0804a478 in FindPath (startingX=2, startingY=5, targetX=4, targetY=3) at online.c:341
#1  0x0804a84c in main (argc=1, argv=0xbfaac554) at online.c:455

---

I am really at loss as to why is doesn't work properly.

What are the values of pathX and pathY when it segfaults?


Quzah.

pathY is -1209735804 and pathX is now -1209794033.

At line 337, it has:
pathX = targetX; pathY = targetY;
where targetX is 4 and targetY is 3. However, it seems this assignment never gets done, as the above pathX and pathY vaules are used with the do...while() loop and just messes up everything.

:confused:

Quote:

---

Originally Posted by user_name_void

I get this when it seg faults. But it really doesnt help me:

---

Visual Studio pwns, its debugger will take you to the line of code that caused the problem.

Quote:

---

Originally Posted by user_name_void

pathY is -1209735804 and pathX is now -1209794033.

At line 337, it has:
pathX = targetX; pathY = targetY;
where targetX is 4 and targetY is 3. However, it seems this assignment never gets done, as the above pathX and pathY vaules are used with the do...while() loop and just messes up everything.

:confused:

---

The assignment is only done if the if on line 332 is true. Then, it is immediately changed when you call the loop.

Is that a goto I see? :shakehead:


Quzah.