Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`recursion/gnark-ffi` frees C strings allocated by Go from Rust code

Abierto
  • ¿Algo no está bien?
#14 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
go, rust
Área
backend

Línea de trabajo

Comienza con recursion/gnark-ffi/go/main.go en las líneas 41–44 y con el código Rust FFI que analiza las cadenas de error devueltas; lee primero la documentación enlazada de Rust sobre CString/from_raw y las cadenas de cgo. Confirma el propietario de cada asignación y asegúrate de que tanto la ruta normal como las rutas de cadenas de error utilicen el mecanismo de liberación compatible con el allocator; terminado significa que ninguna Rust CString toma posesión de punteros asignados por Go.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

From https://github.com/wormhole-foundation/wp1/pull/222#discussion_r1613607167:

The usage of CString by recursion/gnark-ffi seems incorrect when compared to what the Rust documentation says about ownership. Specifically:

  • As far as I can tell, these strings are allocated by the Go code here
  • The CString documentation explicitly says "Other usage (e.g., trying to take ownership of a string that was allocated by foreign code) is likely to lead to undefined behavior or allocator corruption."
  • This means the string is allocated by Go, but being freed by Rust. This seems possibly unsafe.
  • The documentation also says: "Note: If you need to borrow a string that was allocated by foreign code, use CStr. If you need to take ownership of a string that was allocated by foreign code, you will need to make your own provisions for freeing it appropriately, likely with the foreign code’s API to do that."
  • The correct solution would be to return these pointers and have the Go side free them from Go
  • The CGo documentation for strings says: 
    // Go string to C string
// The C string is allocated in the C heap using malloc.
// It is the caller's responsibility to arrange for it to be
// freed, such as by calling C.free (be sure to include stdlib.h
// if C.free is needed).
func C.CString(string) *C.char
  • CString in Rust is actually allocated from the Rust global allocator and not C's malloc/free functions. So this code is freeing something allocated by malloc with Rust's allocator, which is just incorrect in terms of safety
  • Since this code does seem to work, in some cases where Rust and Go are using the same libc on the same system, this is likely to be incidentally fine
  • Further, in some cases, such as when binaries are distributed in pre-compiled formats, it is possible for there to be a version mismatch between libcs used, leading to further issues even if the Rust global allocator ends up using malloc/free
  • This same mishandling is present when parsing the error strings returned by Go
Lenguaje dominante
Rust
Estrellas
80
Forks
8
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de argumentcomputer/sphinx

Todos los issues de argumentcomputer/sphinx

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.