Crash on return 0

Hi, I've got a nasty problem that's been bugging me for almost a week now. I will start off with a general question because I have the feeling it can be solved that way;

Has anyone of you had the problem that a program crashed on the return line of a function? If so, what did you do to solve it?

It comes down to this:

Code:

---

puts("\n Stopped!");
getch();
return 0;

---

^ the end of the function GoLive.

And:

Code:

---

GoLive(br_cnt, "\0", -1);
puts("Returned?");

---

^ calling the function


Now "Stopped!" is printed on the screen, but "Returned?" isn't.... :(


Any ideas? I've checked and rechecked, but I can't find anything wrong.

Thanks very much in advance,

René

I would need a little bit more code to be able to answer that question but if I had to guess, GoLive seems to be of type void and you return an integer.

Quote:

---

Originally Posted by KONI

I would need a little bit more code to be able to answer that question but if I had to guess, GoLive seems to be of type void and you return an integer.

---

Nope, GoLive is of type integer:

Code:

---

  int GoLive(int bdrate, char summary[256], int filter);

---

What part of the code would you need?

When a program crashes upon the return of a function, I believe that is possibly related to the stack getting corrupted.

This can be done by passing in incorrect parameters to a function (involving pointers or arrays). For instance, GoLive() is expecting a non-const array of 256 chars, and you're giving it a const pointer to a char.... Is that OK? I have no idea. Depends what GoLive() is doing. :)

But I'm exhausted, so perhaps I'm totally way off base with this one.

Make sure your GoLive function isn't writing before the bounds of the summary array it has been given.

Quote:

---

Originally Posted by MacGyver

When a program crashes upon the return of a function, I believe that is possibly related to the stack getting corrupted.

This can be done by passing in incorrect parameters to a function (involving pointers or arrays).

But I'm exhausted, so perhaps I'm totally way off base with this one.

---

I see...

Code:

---

GoLive(br_cnt, "\0", -1);

---

Would the underlined part be passing in an incorrect parameter?


Function declaration is:

Code:

---

int GoLive(int bdrate, char summary[256], int filter);

---

Did you try assigning the return value of GoLive to a variable ? I'm not experienced enough to know if there are compilers that might have problems with that but I can't see anything else at the moment. Could you post the entire GoLive function (if it isn't too big).

On another note, are you aware that you are passing a string literal as 2nd argument which is read-only ?

Quote:

---

Would the underlined part be passing in an incorrect parameter?

---

Not if you use it correctly, as a string literal (a constant). If you want a real string as parameter, then you need to do this:

Code:

---

char parameter[256] = "\n";
GoLive(br_cnt, summary, -1);

---

This code doesn't create a string literal but rather an initialization of the string parameter, which can then be correctly passed to the function. What you have at the moment is approximately:

Code:

---

const char test[256] = "\n";
char *p = test;
GoLive(br_cnt, p, -1);

---

Quote:

---

Originally Posted by Rashakil Fol

Make sure your GoLive function isn't writing before the bounds of the summary array it has been given.

---

Sorry, I don't think I understand you. "Writing before the bounds of the summary array" ?

Whatever your problem is, it is not caused by the return keyword. As has been said in a few posts you are more than likely corrupting the stack and/or causing an access violation at some point in your function.

Quote:

---

Originally Posted by KONI

Could you post the entire GoLive function (if it isn't too big).

---

I don't think you want to go through all its 677 lines :P

Quote:

---

Originally Posted by KONI

This code doesn't create a string literal but rather an initialization of the string parameter, which can then be correctly passed to the function. What you have at the moment is approximately:

---

Hmm, if I understand you correctly then I think you misunderstand the reason for the "\0" in the function call.
I'm passing "\0" into the function to let the function know that in this case there isn't a summary file available. It has to do with this part of the code:

Code:

---

  if(strlen(summary)!=0)
  {
      strcpy(identifier_list, summary);
      strcat(identifier_list, "/temp/id.txt");
  }
 
  if( (fpin=fopen(identifier_list, "rb")) != NULL )
  {
      etc...

---

So it only uses the identifier_list functionality when the function is called with a valid summary file (string length > 0).

Thanks a lot for the help so far.





Edit

Quote:

---

Originally Posted by Bubba

Whatever your problem is, it is not caused by the return keyword. As has been said in a few posts you are more than likely corrupting the stack and/or causing an access violation at some point in your function.

---

Yeah, I thought so... do you maybe have any tips for me to debug this problem? When it comes to stack and access violations I'm a complete noob.

Where identifier_list is declared? Do you check the buffer bounds?

Quote:

---

Originally Posted by vart

Where identifier_list is declared? Do you check the buffer bounds?

---

Hmm I didn't actually, good point! :) I've corrected that now, but it doesnt solve the problem. Thanks though!

attach the GoLive function as a file to your next message, I'll have a look (if you want).

Alrighttt I've found the problem! Thanks a lot for helping me everyone... your suggestions have pointed me in the right direction.
It was a combination of problems that lead to the crash on the return line. Due to a hardware buffer overflow (reading CAN messages) the software received wrong values for datalength (myMsg.LEN in the example below).

Code:

---

  for(i=0;i<myMsg.LEN;i++)
  {
//      printf("B %d) %d %d %d\n", i, myMsg.LEN, strlen(buffer2), strlen(buffer) );
      sprintf(buffer2," %3d",myMsg.DATA[i]);
      strcat(buffer,buffer2);
  }

---

Normally the myMsg.LEN is 8 at max. Due to the buffer overflow in the hardware, myMsg.LEN was passed into the softaware with a value of around about 600. This caused the for loop to loop 600+ times and therefore the string length of buffer (declared as buffer[512]) was well over the declared size. I've added the following line:

Code:

---

if(myMsg.LEN<=8)

---

before the for loop and the crashing has stopped! :D


Finally! :D Thanks again everyone!

René


Edit: and thanks for your offer KONI, well appreciated.