errror handling with "return" causes Stack smashing protect failure

Using Arduino Programming Questions
1

Hi,
I'm stuck in handling errors using the "return" structure

In my main code

void loop() {
if(!NachrichtSenden(1, 0)) {Serial.println("error");};                
delay(10000);
}

I call that function.

bool sendMsg(int code, long dauer) {
char msg [] = "01305222020_18412212.311110000035000";
bool resp = false;

resp = SendGPRS(msg);

if (resp == false) {
    Serial.print("No success sending");
    return false;
    }
  else {
    Serial.print("Success sending");
    return true;
    }
  }

Within that one I call the next one (makes sense in the full context):

bool SendGPRS( char msg [37]) {
 if (!modem.gprsConnect(apn, gprsUser, gprsPass)) {
    Serial.println(" [fail]");
    delay(10000);
    return false;
  }

If now modem.gprsConnect is returning "false" the " [fail]" is printed but then I get

Stack smashing protect failure!

abort() was called at PC 0x400d6320 on core 1

Backtrace: 0x4008b560:0x3ffb1e20 0x4008b78d:0x3ffb1e40 0x400d6320:0x3ffb1e60 0x400d20aa:0x3ffb1e80 0x400d2292:0x3ffb1f30 0x400d2315:0x3ffb1f90 0x400d2ea9:0x3ffb1fb0 0x40088215:0x3ffb1fd0

I assume I did something wrong with the "return" but really no clue what. Origin to my code is that example: TinyGSM/WebClient.ino at master · vshymanskyy/TinyGSM · GitHub
Line 187 is the "modem.gprsConnect" call. The main difference is, that TinyGSM uses the "return" to stop the code and start the loop function again. That works for me as well, but in my case the "return" is in a function inside another functoin...

Thanks a lot for your help!

Markus

2

Do you have any recursive function call?

3

Hi, no that's not the reason. But quite easy:

defined bool SendGPRS( char msg [37]) but passed a variable of type char longer than 37...

Strangely the the error resulted in a crash first by calling return.

Thanks for your help anyway

4

using a fixed size array as an argument is not advisable, actually since the char array is not 'null' terminated, the moment that the function that you call that takes a char* as an argument gets into trouble.

5

Deva_Rishi:
using a fixed size array as an argument is not advisable, actually since the char array is not 'null' terminated, the moment that the function that you call that takes a char* as an argument gets into trouble.

Which char array is not null terminated? The msg array in sendMsg is null terminated and is exactly 37 chars long (the 37th char is the null terminator). Besides that, the size in the msg array parameter in SendGPRS is ignored. The msg parameter is, for all SendGPRS knows, a pointer to char.

Besides that, the stack corruption happens before msg is even used in that function.

6

thanks for your answers! really appreciate your help!
by now it's running again. and as it's unnecessary, I removed the size parameter from SendGPRS if it's of no use anyway

7