I don't understand how you are able to run the code locally. The code is failing because it is generating a segmentation fault with the first if statement in the main do/while loop - both at the check50 servers and on my system. Have you made any changes to the .h file or the makefile? Is your IDE up to date with update50? Are you running in a different environment?
Rather than debug that, I'm going to let you have a shot at it, along with a suggestion for redesign. If you reread the pset specification, it says that a signature will appear as the FIRST 4 bytes of a 512 byte block. Your code tests every byte from the beginning of the data until the first signature is found. Consider that random data could match a signature in the middle of a 512 byte block. Your code would find it and would report a false positive for a signature. From there on, all of the results would be garbage. This also takes a lot of time, so if it did compile, it could potentially time out.
Since you don't have to check every byte before the first signature, most of the code before the do/while loop could be removed, streamlining the process.
Next, using a char type for your buffers, which is actually a signed char, can present problems. As mentioned in lecture, an unsigned one byte type is better. It will hold data without modifying it or applying 2's complement logic (that's how negative numbers are handled, remember?). Look into unsigned char or uint8_t. You could use these to declare a BYTE type, as was done in resize.
Speaking of streamlining, take a look at your if conditions. It's basically "4 compares for signature A or 4 compares for string B". You need to think about efficient programming whenever writing code. In this case, instead of 8 different comparisons, you could write this as 5. Since the first three bytes are the same in both signatures, you could write
( buffer == jpeg0 && buffer == jpeg0 && buffer == jpeg0
&& (buffer == jpeg0 || buffer == jpeg1) )
But there's still a problem. The spec says that the 4th byte can be anything from 0xE0 to 0xEF, so a change is in order.
There may well be other problems, but this should give you quite a lot to think about. Depending on how you recode, problems may go away and new ones appear. If you still have trouble, you should consider a new question with the revised code.
If this answers your current question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)