void Setup runs more than once when using ARDOSC and a callback function

I guess I need some clues as to what might reset the processor

I guess if you read the posting guidelines, they would indicate that you should post your code, otherwise you're just wasting everyone's time.
Clues are for Sherlock Holmes.

#include <SPI.h>
#include <Ethernet.h>

#include <ArdOSC.h>

byte myMac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte myIp[]  = { 10, 32, 26, 33 };
int  serverPort  = 10023;

float t=0;

OSCServer server;

void setup(){   
 Serial.begin(9600);
 Ethernet.begin(myMac ,myIp); 
 server.begin(serverPort);
 //set callback function
 server.addCallback("/ch/01/mix/fader",&fader);
 Serial.println("Setup Run"); 
}
  
void loop(){
  if(server.aviableCheck()>0){
  }
}

void fader(OSCMessage *_mes){
  t = _mes->getArgFloat(0);
  Serial.println(t); 
}
if(server.aviableCheck()>0)

What does "aviableCheck" do?

It checks for any incoming messages and if I have specified a callback it looks to see if there is a match and then calls back the function I have specified in this case setFader

sorry I have just called it "fader" this time

You've just called what "fader"?

I typed "setFader" but the function in the code I posted is just "fader"

But it is worth mentioning that if a match is not found and the callback function "fader" is never fired then setup is not called more than once, so the availablecheck runs in the loop without causing setup to run again. The problem seems to only occur if and when a callback function is called.

I typed "setFader" but the function in the code I posted is just "fader"

I have no idea what you are talking about.
"aviable" != "available", which leads me to suspect that you're not actually posting your code, but rather what you imagine your code to be.

I'm not familiar with the ArdOSC library. Can you post a link to it?

From the symptoms, I would suspect either memory corruption, or a logic fault causing an invalid function pointer to be used. Memory overflow would be one possible cause of memory corruption. The sketch itself looks pretty simple but I can't guess how much memory it uses. What other resources and/or external action would be necessary for somebody else to reproduce the problem?

I'm sorry if i'm annoying you, I just made a typo "setFader" instead of "fader" thats all.
As far as the code I posted goes, that is the code I am running.
"server.aviableCheck" is a function of the ArdOSC library, it obviously has a spelling mistake, but it does not change its functionality

Here is the link I used, thanks

How can you make a spelling mistake with cut and paste?

As for other resources to reproduce, I am using an iPad mixer application from Behringer for the X32 mixer it is a free download. But I guess any software that could send an OSC message might work also, I will have a look to see if I can find something else. Just thought you could use another Arduino board to send the OSC message, I will put a code example together and post it to make it easy to reproduce.

The spelling mistake is in the ArdOSC lib

There's nothing obviously wrong in the library implementation although the way it's passing around function pointers and copying string addresses could easily hide a bug. Unfortunately I don't have anyway to generate an OSC message without writing my own client, which I'm too lazy to do, so I can't try to reproduce your problem.

Can you find out exactly where the crash occurs?

Presumably it's triggered by a call to OSCServer::aviableCheck() calling Pattern::paternComp() calling Pattern::execFunc() calling fader() so to start with I suggest you take that outermost call out of its IF and put some trace before and after calling it so you can see whether it actually returns from that call and what value it returns. If it fails inside the call then you could edit the library to add trace to paternComp() and execFunc() to see whereabouts it is failing. Remember when using trace statements to locate a crash that you need the code to stop and wait for the trace output to finish transmission before you move on. You can do that by calling Serial.flush() after each Serial.println().

You could also try commenting out the body of fader() to see whether the problem is being triggered somehow by that call to getFloatArg().

Thanks for your help Peter, it looks like the problem lies in the socket recvfrom function, if I remove that line and modify the pattern code to just call the callback function without regard to what is received, "fader" function is called without the setup running again.

Doing a quick search sounds like there is an issue with a buffer overrun in recvfrom function, so I will try to find a fix for that.

TomKeith:
Thanks for your help Peter, it looks like the problem lies in the socket recvfrom function, if I remove that line and modify the pattern code to just call the callback function without regard to what is received, "fader" function is called without the setup running again.

Doing a quick search sounds like there is an issue with a buffer overrun in recvfrom function, so I will try to find a fix for that.

Good catch. The implementation of recvfrom() looks wrong - it attempts to return whatever is waiting in the input queue, regardless of how big the supplied buffer was. Do you know how big your OSC messages will be? Current the receive buffer size is set to 100 bytes in OSCommon.h - if you need a bigger buffer, and assuming you have enough RAM spare, you could just increase that to fit the biggest message you need to deal with. (Or you could try to fix the Ethernet library implementation, but that seems like a harder approach.)

I have it working now and it didn't make any difference making a change to the kMaxReceiveData only in that as soon as it worked (above 20) it failed. But in the socket.cpp the specific line that failed I replaced data_len with 100 and it works I assume there is a size mismatch from source to dest. I'm a bit new to this language so I might just run it like that.

    case SnMR::UDP :
      W5100.read_data(s, (uint8_t *)ptr, head, 0x08); 
      ptr += 8;
      // read peer's IP address, port number.
      addr[0] = head[0];
      addr[1] = head[1];
      addr[2] = head[2];
      addr[3] = head[3];
      *port = head[4];
      *port = (*port << 8) + head[5];
      data_len = head[6];
      data_len = (data_len << 8) + head[7];

      W5100.read_data(s, (uint8_t *)ptr, buf, 100 ); // data copy. //data_len
      ptr += data_len;

      W5100.writeSnRX_RD(s, ptr);
      break;

Groove:
How can you make a spelling mistake with cut and paste?

Surprising as it may seem, the "ardosc" code linked do, does indeed declare a function call "aviableCheck()".