C语言出现*** stack smashing detected ***报错，社会模拟程序求助

Hey there! Let’s tackle that stack smashing detected error you’re running into—those can be frustrating, but let’s break down the most likely culprits given your program’s setup.

First, a quick reminder: stack smashing almost always means your code is writing data beyond the bounds of a stack-allocated variable (like a small array or buffer). Given your setup with message queues, the gestore process spawning A/B roles via execve, here are the key areas to investigate:

• Message queue buffer mismatches
  When sending or receiving messages between gestore, A, and B, if your buffer size doesn’t match the actual message size, you’re risking overflow. For example:

  • If your message struct is 64 bytes, but you’re using a 32-byte stack buffer to receive it with msgrcv, that’s a guaranteed stack smash.
  • Ditch unsafe string functions like strcpy—use strncpy with explicit length limits, or snprintf when formatting data to send. Always account for the null terminator when dealing with strings!

• Broken execve argument setup
  execve requires a NULL-terminated array of strings for argv. If you forget to add that final NULL, or if one of your argument strings overflows its buffer when you build it (like converting an integer to a string in a tiny buffer), that can corrupt the stack.

  • Double-check that your argv array ends with NULL. For example:

    char *args[] = {"./roleA", attribute_str, NULL}; // NULL is critical here
    

  • When converting numeric attributes to strings for execve, use snprintf with a buffer that’s definitely large enough. A 32-byte buffer works for most integer values—don’t skimp here!

• Small stack buffers in child processes
  When your A/B role processes start, if they’re declaring stack buffers that are too small for the data they pull from the message queue, that’s a common trigger. For example:

  // This is bad—reading 100 bytes into a 32-byte stack buffer
  char tiny_buf[32];
  msgrcv(msg_queue_id, tiny_buf, 100, 0, 0);
  

  Always make sure the size parameter in msgrcv matches the exact size of your buffer or message structure.

• Uninitialized stack variables
  Using uninitialized stack variables can lead to weird behavior that trips the stack protector. Make sure all stack-allocated buffers, structs, and variables are initialized (set to zero or valid values) before you use them.

• Turn on compiler warnings
  If you’re using GCC, compile with -Wall -Wextra—it’ll catch a lot of buffer overflow issues before you even run the program. The stack protector (enabled by default in most modern compilers) is what’s yelling about the smash, so compile-time warnings can point you straight to the problem.

If you can share small snippets of code related to message handling, execve argument building, or child process setup, that’d help narrow things down even more—but checking these areas should get you well on your way to fixing the issue.

内容的提问来源于stack exchange，提问作者mastodilu