Fixing a segmentation fault [closed] - c

Question

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm getting a segmentation fault, which I've narrowed down to a for loop in a callback function. It's strange because the program was previously working, now it's not!
struct debuggerth_command debuggerth_protocol[] = { /*
* Note: These strings are NOT null-terminated. The
* strings are 4 bytes long for memory alignment and
* integer-cast comparisons.
*/
{ "run ", debuggerth_startprocess },
{ "stop", 0 },
{ "inp ", 0 },
{ "sig ", 0 },
{ 0, 0 }
};
And this is the code:
int debuggerth_callback (struct libwebsocket_context * context,
struct libwebsocket * wsi,
enum libwebsocket_callback_reasons reason,
void * user,
void * in,
size_t len){
switch (reason) {
case LWS_CALLBACK_RECEIVE:
if (len < 4){
/* send error */
return -1;
}
/* Getting a segmentation fault
* within this loop.
*/
// I used this break to determine where the seg fault starts
// break
int i = 0;
for (; debuggerth_protocol[i].cmd; i++)
if (cmpcmd (debuggerth_protocol[i].cmd, in)) break;
//break;
if (!debuggerth_protocol[i].cmd){
int byteswritten = sprintf
(debuggerth_message,
debuggerth_format,
debuggerth_headers[0],
debuggerth_errors [0]);
libwebsocket_write (wsi, debuggerth_message,
byteswritten,
LWS_WRITE_TEXT);
return -1;
}
break;
This is the string comparison macro:
#define cmpcmd(cmd, str) ((*(int*)(cmd)) == (*(int*)(str)))
Anyone have any ideas?

Answer 1

One idea: relying on the fact that your strings are exactly the size of an int is rather horrendous.
People often try to do clever things like that only to be badly bitten when the underlying assumptions change, such as moving to a platform where the int type is eight bytes.
I'd ditch that macro and rewrite it to use strcmp or strncmp (a).
There's also a couple of other things to do.
First, print out (or use a debugger to examine) all variables before attempting to use them. It may be that in is NULL.
Or maybe you attempt to call the NULL commands like stop or sig, or even if you get a command that's not in your table and you blindly call it when i is equal to 4. These particular possibilities are in code not shown, following the loop, so it's pure, though I'd like to think educated, speculation on my part.
Another possibility is that you're running on an architecture that disallows unaligned access. Some architectures are optimised for accessing on specific boundaries (such as getting 32-bit values from 32-bit aligned addresses) and will run slower if you violate that alignment.
However, some architectures won't allow unaligned access at all, instead giving something like a BUS error if you try.
Since you've now indicated in a comment that you're using ARM, that's almost certainly the case. See here for some more information.
If that's the case, it's even more reason to get rid of the tricky macro and use a more conventional solution.
(a): You may also want to investigate the term "strict aliasing" at some point since this may technically be undefined behaviour.

Answer 2

Given this is running on ARM, I think your problem is that it's doing an unaligned memory access, which will either fail or be quite slow. It is not exactly a seg fault. See this question for example, and as suggested there -Wcast-align will probably flag it as risky. You can turn on a software workaround but that's probably slower than just fixing it in your code.
One option would be to use memcmp which gcc may be able to compile down to something nearly as simple as a word read, in the case that it is aligned.
Another option, if performance is critical, is to unwind the loop into a case statement switching by the first byte of the command. Then just check the following characters are as expected.

Answer 3

I looked at some of the changes to my code, as #Jonothan Leffler suggested. This was the change I made:
struct debuggerth_command {
char * cmd;
int (*function)(struct debuggerth_session *, char * input);
};
struct debuggerth_command {
char cmd[4]; // changed this an array
int (*function)(struct debuggerth_session *, char * input);
};
So, when I initialized the structure here:
struct debuggerth_command debuggerth_protocol[] = { /*
* Note: These strings are NOT null-terminated. The
* strings are 4 bytes long for memory alignment and
* integer-cast comparisons.
*/
{ "run ", debuggerth_startprocess },
{ "stop", 0 },
{ "inp ", 0 },
{ "sig ", 0 },
{ 0, 0 } /* Zero used to be a pointer value,
* but now it's the first element in a
* 4 byte array
*/
};
Which changed the evaluation of the for loop:
int i = 0;
for (; debuggerth_protocol[i].cmd; i++)
if (cmpcmd (debuggerth_protocol[i].cmd, in)) break;
To always evaluate true, because cmd is now a valid pointer to a 4-byte array - of which, the first value is 0.
I'll remove the macro, since it might not perform well on some architectures. But, couldn't this be fixed with the use of C11's alignas feature?