Because you're doing something that is quite wrong. One may then debate to what degree you should be shown the problem and to what degree you should go figure it out. Since it's something that is happening in your own function you ought to be able to figure it out with printf. Depending on how and what you print it may be tricky to figure out the exact cause but you'll at least be able to figure out where it happens which gives you a very limited amount of code to focus your debugging on. But that's C for you isn't it? Requiring you to navigate that. You've also got the test code here

• char* res=calloc(strlen(s),1);
  

  this does not account for the nul terminator (1 byte is missing)

• char* res=(char*)malloc(strlen(od));
  

  same remark

• if(*s=='\0'){
    return "";
  

the tests expect the returned string to be free()-able. "" is a string literal that cannot be freed

• if(*od=='\0'){
    char* cp=NULL;
    strcpy(cp,s);
  

you are attempting to write at the null pointer here. this will crash. you have to allocate memory for `cp`.



your code passes once all these are fixed.

The famous C++'s "Unsafe memory" ))

I'd try to reproduce it locally, at the very least you should be able to find out what inputs it happens for by printing (and flushing to ensure it isn't stuck in a buffer) and probably throw ASan or similar at it to see if it notices anything. Of course, it might be something unexpected going on in the test code that you can't reproduce yourself - for which I suppose very carefully finding out how your function should behave is a start.

When i run your code against the tests and print out the indata, it turns out it does happen for an obviously special test case, so there's a good chance you don't need to dig any further than that.

That may be subjecive, but given that there are mentions in description of constraints that include arrays of length ~100_000, that in itself should suggest "performance".

What you're trying to do is input probing and doesn't make a lot of sense. What I'm understanding is you're trying to return a certain result based on a very specific input, but you're not taking into account the other argument, k. If k is negative, then the same string vector can yield back "" from your solution, and, likewise, it should return "wlwsasphmxxowiaxujylentrklctozmymu" if k is 2. Regardless, the answer you have so far is correct regardless as you've noticed.

We need to see your code to tel you what is wrong with it.

Not a kata issue.

Not an issue, and not language specific. The translation was created by the Kata author themselves, and all translations I've looked at test for the empty string. The author is probably practicing some sort of vacuous truth - dealing with 0 substrings yields back 0 substrings, or an empty string in other words. You'll see this is a lot on Codewars; a lot of Kata make sure to test an empty input unless explicitly stated otherwise.

Oh, why would that be?

yes,of course you can everyone has the road to solve it, so it has a 10000 trick to solve it;

Yep, there are no high performance requirements

Sorry, I may have misread your code (this would be less likely to happen if you use proper markdown tags for readability, see there); however your first loop condition is weird for the same reason I have pointed out before. You should print stuff to see where your code is failing : https://docs.codewars.com/training/troubleshooting/