在Golang中调用C代码触发SIGSEGV错误的技术求助

Let’s walk through the most likely causes and fixes for your SIGSEGV error when calling a C library from your Go gRPC server. The mismatch between your function typedef and the actual C function signature jumps out as a critical red flag first, but we’ll cover all key areas:

1. Fix the Function Signature Mismatch (Most Likely Root Cause) #

Looking at your code, there’s a clear mismatch between the typedef for createTable and the actual createOFATableEntry function:

• Your typedef defines a function with 4 parameters: (char *, unsigned int, char *, unsigned int)
• The actual createOFATableEntry has 5 parameters: (char *tableName, char *prefix, unsigned int prefixLen, char *nextHop, unsigned int outPort)

When you use dlsym to get a function pointer and cast it to createTable, calling this pointer will push the wrong number of arguments onto the stack. This corrupts the stack frame immediately, leading to a SIGSEGV.

Fix: Update your typedef to match the actual function signature exactly:

typedef int (*createTable)(char *, char *, unsigned int, char *, unsigned int);

2. Validate Dynamic Library Loading #

Ensure you’re correctly loading the .so file and checking for errors at every step—silently ignoring failures here will lead to invalid function pointers and crashes:

• Always check if dlopen returns NULL. Use an absolute path to the .so file if relative paths are causing issues:

  void *handle = dlopen("/path/to/your/library.so", RTLD_NOW);
  if (handle == NULL) {
      fprintf(stderr, "dlopen failed: %s\n", dlerror());
      return -1;
  }
  

• After dlsym, check for errors again to confirm you’re getting a valid function pointer:

  createTable func = (createTable)dlsym(handle, "createOFATableEntry");
  char *err = dlerror();
  if (err != NULL) {
      fprintf(stderr, "dlsym failed: %s\n", err);
      dlclose(handle);
      return -1;
  }
  

3. Ensure Memory Safety Between Go and C #

Go’s garbage collector and C’s manual memory management can clash if you’re not careful:

• String handling: When passing Go strings to C, use C.CString() to create a C-compatible string, but remember to free it with C.free() after the call to avoid leaks. Also, keep a reference to the original Go string in your Go code to prevent the GC from reclaiming the memory while C is using it:

  tableNameC := C.CString(tableName)
  defer C.free(unsafe.Pointer(tableNameC))
  // Repeat for other string parameters
  

• Integer type matching: Make sure Go’s integer types match C’s exactly. For unsigned int in C, use uint in Go (not int) to avoid sign extension or size mismatches on 32/64-bit systems.

4. Debug with GDB to Pinpoint the Crash #

If you’re still hitting SIGSEGV after fixing the above, use GDB to get a stack trace and see exactly where the crash happens:

1. Compile your Go program with debugging symbols (disable optimizations):

   go build -gcflags="-N -l" -o your-server
   

2. Run the program in GDB:

   gdb ./your-server
   

3. Start the program with run, and when it crashes, use the bt command to print the stack trace. This will show if the crash is happening in your Go-to-C call, inside the C library’s code, or due to a bad function pointer.

5. Check Library Compatibility #

• Verify that the .so file matches your system’s architecture (32-bit vs 64-bit). Use file yourlibrary.so to check.
• Ensure all dependencies of the .so are available. Run ldd yourlibrary.so to see if any required libraries are missing.

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