C - 分段错误将char指针传递给函数

Question

I am getting a segmentation fault when I call an array to mark the bit position of the corresponding bit position in an unsigned int set[9] with its index in the global names array names[320][30]. When I run the program, I use ./a.out < data.dat and load a list of 320 words in a list. None are more than 30 characters.

Also, typedef unsinged int Set[10];

Here is the code where I call the addName2Set function

//add name to unsigned int set
void addName2Set(Set set, char *key){
    int index;

    //binary search to get index for key
    index = binarySearch(names, key, 0, 319);
    //call add2set to add index to set
    add2Set(set, index);
}

Here is add2Set

//add value passed to set passed
void add2Set(Set set, int index){
  int element, position;

  //find which element, set[element] of set index is in
  element = findArrayElement(index);

  //convert index to bit position 0-31 in set[element]
  position = findElementPos(element, index);

  //in set[element], set bit position 'position' to 1
  set[element] = set[element] | (1 << position);
}

Here is the findArrayElement and findElementPos function

//for unsigned int set[i], return i
int findArrayElement(int index){
  //index range [j,i]
  int i;
  int j=0;
  //element in set array
  int element;

  //loop through [j,i], return element if range true
  for(i=31; i<320; i+=32){
    if(i <= i && index >= j){       
      return element;
    }
    j+=32;
    element++;
  }
}

//find bit position 0-31 corresponding to index
int findElementPos(int element, int index){
    int j;
    int position;

    j = element*32;
    position = index - j + 1;

    //return bit position
    return position;
}

And finally here is where I call the addName2Member function

//declare key pointer
char *key = (char*)malloc(30);

//set search word to pointer key
strcpy(key, "clean");

//addName2Set
addName2Set(set1,key);

Anyone see why there would be a segmentation fault when I run the program? "Clean" is the first word in the data.dat list.

Here are the results from valgrind

==1645== Invalid read of size 4

==1645== at 0x8048860: add2Set (set.c:61)

==1645== by 0x8048A5D: addName2Set (set.c:145)

==1645== by 0x80485D2: main (driver.c:29)

==1645== Address 0x9DBED860 is not stack'd, malloc'd or (recently) free'd

==1645==

==1645== Process terminating with default action of signal 11 (SIGSEGV)

==1645== GPF (Pointer out of bounds?)

==1645== at 0x8048860: add2Set (set.c:61)

==1645== by 0x8048A5D: addName2Set (set.c:145)

==1645== by 0x80485D2: main (driver.c:29)

Answer 1

Without seeing the whole program (including the definitions of findArrayElement() and findElementPos() it's hard to tell.

You can use a brute force approach and run the program in GDB:

gdb ./a.out

And from the GDB shell, call

run < data.dat

When the segfault happens the program will be stopped in the debugger. You can then call

bt

To see exactly where in your program the segfault happened.

Answer 2

It looks like you are missing a return statement at the end of findArrayElement . This might be your problem right there.

After OP corrected findArrayElement with a return -1 at the end:

Note that you will also need a check for that -1 returned from findArrayElement , otherwise you might be underindexing the set array.

UPDATE: The exact reason why leaving the return statement off is causing the OP's problem is that the function is promising to return an integer (it's return type is int ), so when there is no return statement to set the return value, the memory/register where the return value would be stored will contain "garbage" (whatever happens to be in memory/register at that time). The seg.fault occured because the garbage "return value" caused indexing into the array to access an element that did not belong to the application. This behavior is erratic as it depends on what value the "garbage" happens to be (it might even have been a value that would be within the range of valid results), thus making it hard to find in certain circumstances.

The best way I know of to prevent such errors from happening is to set the compiler's warning level high, so it gives a warning about missing return statements, and possibly also to set the compiler to turn all warnings into errors -- warnings usually describe issues that should be addressed to avoid possible bad behavior. If there is a certain warning that the programmer knows is not an issue, the compiler can be configured (possibly through pre-processor statements, although that is not a portable approach, as it is compiler-dependent) to ignore those specific warnings.

Answer 3

if your program named a.out. Then, use valgrind like this valgrind --tool=memcheck a.out < data.dat then valgrind will run your program in a special memory , and it will tell you where is wrong. Do NOT forget use gcc -g for add debug info to your bin-file.