El código de los años 80 que impulsa la fiabilidad moderna y los errores que todavía comete

Code for some Erlang/OTP modules is older than most modern junior developers. These files are the true digital patriarchs. For decades, they have made sure that banking transactions, telephone networks, and messaging systems are all working properly. We decided to take a look under the hood of this long-lived language to see what exactly lies behind the lines that millions of users rely on today. In this article, let's see what we found. Introducción Antes de pasar a discutir las advertencias, me gustaría decir algunas palabras sobre el proyecto. El viaje de Erlang comenzó en 1986 en uno de los laboratorios de Ericsson. Joe Armstrong estaba experimentando con Prolog mientras intentaba construir un programa telefónico. Es un lenguaje de programación diseñado para sistemas tolerantes a fallos donde el fracaso es inaceptable.Piensa en un interruptor telefónico donde una llamada caída cuenta como una emergencia, o una transacción bancaria que debe pasar sin importar lo que.Estas son las tareas para las que se utiliza. Permite a un sistema dividirse en millones de procesos aislados e independientes, por lo que cuando uno falla, el resto continúa funcionando sin perder un golpe. Erlang El Ecuador va de la mano con el , a framework that provides powerful tools, patterns, and behaviors for building distributed, fault-tolerant applications. This built-in toolkit enables systems written with it run continuously for years without ever needing to stop. Open Telecom Platform (OTP) Hemos construido el proyecto siguiendo estos Lo comprobamos en la Rango de uso Y el Nos enfrentamos a ningún problema con la construcción del proyecto, así que kudos a los desarrolladores. Instrucciones maint-28 Analizador PVS-Studio Código de Visual Studio El artículo incluye sólo advertencias de nivel alto y medio. That concludes our introduction. Now, let's move on to the warnings. We'll divide them into three categories: errores de lógica; critical errors; Errores de memoria. Errores lógicos Fragment N1 El aviso del PVS-Studio: Existen subexpresiones idénticas '(!esock_is_integer((env), (argv[3])))' a la izquierda y a la derecha del operador de 'annoo. V501 prim_socket_nif.c 6035 static ERL_NIF_TERM nif_sendfile(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { .... BOOLEAN_T a2ok; if ((! (a2ok = GET_INT64(env, argv[2], &offset64))) || (! GET_UINT64(env, argv[3], &count64u))) { if ((! IS_INTEGER(env, argv[3])) || (! IS_INTEGER(env, argv[3]))) return enif_make_badarg(env); if (! a2ok) return esock_make_error_integer_range(env, argv[2]); else return esock_make_error_integer_range(env, argv[3]); } .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa En el código, los desarrolladores querían convertir los argumentos tercero y cuarto a tipos de 64 bits (los firmados y los no firmados, respectivamente). La función devuelve temprano si uno de los argumentos no es un número. El código fijo: .... if ((! IS_INTEGER(env, argv[2])) || (! IS_INTEGER(env, argv[3]))) return enif_make_badarg(env); .... Entrar en modo de pantalla completa Salir en modo de pantalla completa Fragment N2 El aviso del PVS-Studio: Existen subexpresiones idénticas 'n->type == ycf_node_type_on_save_yield_state_code' a la izquierda y a la derecha del operador de ' Fhole'. V501 ycf_node.c 218 static void uniqify_local_vars_in_node(ycf_node* n) { if (n->type == ycf_node_type_code_scope) { uniqify_local_vars_in_scope(&n->u.code_scope); } else if(n->type == ycf_node_type_on_restore_yield_state_code) { uniqify_local_vars_in_scope(&n->u.special_code_block .code.if_statement->u.code_scope); } else if (n->type == ycf_node_type_on_save_yield_state_code || n->type == ycf_node_type_on_save_yield_state_code || n->type == ycf_node_type_on_destroy_state_code || n->type == ycf_node_type_on_return_code || n->type == ycf_node_type_on_destroy_state_or_return_code) { uniqify_local_vars_in_scope(&n->u.special_code_block .code.if_statement->u.code_scope); } .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Here's another interesting copy-paste case. We have the función, que maneja recursivamente los nodos de árboles y encuentra áreas de visibilidad con variables locales. Luego llama la función de unificación del nombre de la variable para cada una de estas áreas. La rama, el La situación se duplicó después de operator. uniqify_local_vars_in_node else if n->type == ycf_node_type_on_save_yield_state_code || Desafortunadamente, no tengo una corrección adecuada para este fragmento. A juzgar por la cadena de comparación, los valores de la siguiente lista se ordenan en el orden en que se declaran: typedef enum { .... ycf_node_type_on_save_yield_state_code, ycf_node_type_on_restore_yield_state_code, ycf_node_type_on_destroy_state_code, ycf_node_type_on_return_code, ycf_node_type_on_destroy_state_or_return_code } ycf_node_type; Entrar en modo de pantalla completa Salir en modo de pantalla completa Sin embargo, el constante se verifica en el anterior Así que, supongo que hay un cheque duplicado aquí después de todo, y podemos borrarlo. ycf_node_type_on_restore_yield_state_code else if Fragment N3 El aviso del PVS-Studio: Tipo posible en la ortografía de un nombre de macro predefinido. ‘Macro es similar a’ « . . V1040 WIN_32 WIN32 inet_drv.c 13506 static int tcp_send_error(tcp_descriptor* desc, int err) { /* EPIPE errors usually occur in one of three ways: * 1. We write to a socket when we've already shutdown() the write side. * On Windows the error returned for this is ESHUTDOWN * rather than EPIPE. * 2. The TCP peer sends us an RST through no fault of our own (perhaps * by aborting the connection using SO_LINGER) and we then attempt * to write to the socket. On Linux and Windows we would actually * receive an ECONNRESET error for this, but on the BSDs, Darwin, * Illumos and presumably Solaris, it's an EPIPE. * 3. We cause the TCP peer to send us an RST by writing to a socket * after we receive a FIN from them. Our first write will be * successful, but if the they have closed the connection (rather * than just shutting down the write side of it) this will cause their * OS to send us an RST. Then, when we attempt to write to the socket * a second time, we will get an EPIPE error. On Windows we get an * ECONNABORTED. * * What we are going to do here is to treat all EPIPE messages that aren't * of type 1 as ECONNRESET errors. This will allow users who have the * show_econnreset socket option enabled to receive {error, econnreset} on * both send and recv operations to indicate that an RST * has been received. */ #ifdef __WIN_32__ if (err == ECONNABORTED) err = ECONNRESET; #endif if (err == EPIPE && !(desc->tcp_add_flags & TCP_ADDF_SHUTDOWN_WR_DONE)) err = ECONNRESET; return tcp_send_or_shutdown_error(desc, err); } Entrar en modo de pantalla completa Salir en modo de pantalla completa Este es un caso bastante inusual de comprobar si un proyecto compila bajo Windows. Erlang tiene otras comprobaciones en Windows ([ ] , [ ], [ ], etc.), pero este es único. Esto se parece mucho a un simple tipo (más probablemente, debería ser ) de 1 2 3 __WIN32__ Pero ¿por qué es así? por curiosidad, buscé Para ver lo que se puede encontrar, aquí están los resultados: "__WIN_32__" As you can see, there are almost no results. It's funny that one of the links leads to the file we're looking at on He agarrado el proyecto para no encontrar definiciones de macro similares. También pensé que podría estar integrado en algún compilador, como MinGW. Después de intentar comprender el propósito de la macro, creo que este código es defectuoso. Debian Sources El experimento Como solución, sugiero usar el cheque que encontré anteriormente en otras partes del proyecto: static int tcp_send_error(tcp_descriptor* desc, int err) { .... #if defined(__WIN32__) || defined(_WIN32) || defined(_WIN32_) if (err == ECONNABORTED) err = ECONNRESET; #endif .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Fragment N4 El aviso del PVS-Studio: La lógica operativa del código no corresponde con su formatación. La segunda declaración siempre se ejecutará. V640 Dializador.c 246 int main(int argc, char** argv) { .... if (argc > 2 && strcmp(argv[1], "+P") == 0) { PUSH2("+P", argv[2]); argc--, argv++; argc--, argv++; } else PUSH2("+P", "1000000"); .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Here's an interesting example of a common coding error that can be difficult to spot later on. Take a look at the La estructura: PUSH2 #define QUOTE(s) s #define PUSH(s) eargv[eargc++] = QUOTE(s) #define PUSH2(s, t) PUSH(s); PUSH(t) Entrar en modo de pantalla completa Salir en modo de pantalla completa Uh-huh, it's a macro that expands into two constructs. Let's expand the code as a preprocessor would: int main(int argc, char** argv) { .... if (argc > 2 && strcmp(argv[1], "+P") == 0) { eargv[eargc++] = "+P"; eargv[eargc++] = argv[2]; argc--, argv++; argc--, argv++; } else eargv[eargc++] = "+P"; eargv[eargc++] = "1000000"; .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Como resultado, si la evaluación se , sólo la primera asignación será ejecutada condicionalmente, mientras que la segunda siempre ocurrirá después de la rama. false Escribir y usar macros La solución perfecta sería deshacerse de ellos, pero ajustémonos a una solución menos radical. Construcción cuando necesitan combinar varias acciones en una dentro de una macro. Atraer a los bugs do {...} while (0) #define PUSH2(s, t) do { PUSH(s); PUSH(t); } while (0) Entrar en modo de pantalla completa Salir en modo de pantalla completa Fragment N5 The PVS-Studio warning: The condition 'i >= 0' of loop is always true. V645 Página de inicio.cpp 236 ERL_NIF_TERM wxeReturn::make_array_objs(wxAuiPaneInfoArray& arr, WxeApp *app, const char *cname) { ERL_NIF_TERM head, tail; ERL_NIF_TERM class_name = enif_make_atom(env, cname); tail = enif_make_list(env, 0); for (unsigned int i = arr.GetCount() - 1; i >= 0; i--) { head = make_ref(app->getRef((void *) &arr.Item(i),memenv), class_name); tail = enif_make_list_cell(env, head, tail); } return tail; } Entrar en modo de pantalla completa Salir en modo de pantalla completa Echa un vistazo a la de la ciudad, prestando especial atención a su situación, ya que induction variable is of the tipo con un rango de valores de , the loop becomes infinite. After the loop iterates with La variable se vuelve igual a como resultado de la disminución, y el ciclo continúa. for i unsigned int [0; UINT_MAX] i == 0 UINT_MAX Corregimos el código de la siguiente manera: for (int64_t i = arr.GetCount() - 1; i >= 0; i--) { .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Alertas similares: V654 La condición 'i >= 0' de la loop es siempre verdadera. wxe_return.cpp 248 V654 The condition 'i >= 0' of loop is always true. wxe_return.cpp 260 Fragment N6 El aviso del PVS-Studio: El uso de 'si (A) {...} otro si (A) {...}' patrón fue detectado. Hay una probabilidad de presencia de error lógico. líneas de comprobación: 2903, 3053. V517 erl_bif_info.es 2903 BIF_RETTYPE system_info_1(BIF_ALIST_1) { .... if (is_tuple(BIF_ARG_1)) { // L2778 .... } else if (BIF_ARG_1 == am_scheduler_id) { // L2782 .... } .... else if (BIF_ARG_1 == am_garbage_collection) { // L2903 .... } else if (BIF_ARG_1 == am_fullsweep_after) { // L2921 .... } else if (BIF_ARG_1 == am_garbage_collection) { // L3053 .... } else if (BIF_ARG_1 == am_instruction_counts) { // L3056 .... } .... else if (ERTS_IS_ATOM_STR("halt_flush_timeout", BIF_ARG_1)) { // L3552 .... } } Enter fullscreen mode Exit fullscreen mode El analizador ha detectado varias ramas con controles idénticos en una función que contiene un gran número de Declaraciones - Aproximadamente Sin embargo, cada uno de ellos tiene una lógica diferente: el y Dado el número de ramas y la brecha de 150 líneas entre los duplicados, no es sorprendente que esto pueda ocurrir.El análisis estático ayuda a prevenir tales casos.Desafortunadamente, no puedo pensar en una solución, así que dejaré eso a los desarrolladores. if-else if 800 líneas más largas Primera comprobación La segunda comprobación Fragment N7 El aviso del PVS-Studio: A part of conditional expression is always false: (arity == 0). V560 Bif.c 3145 BIF_RETTYPE delete_element_2(BIF_ALIST_3) { .... ptr = tuple_val(BIF_ARG_2); arity = arityval(*ptr); ix = signed_val(BIF_ARG_1); if ((ix arity) || (arity == 0)) { BIF_ERROR(BIF_P, BADARG); } .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa Aquí tenemos un ejemplo que involucra a las matemáticas.El analista nos informa que el último Las palabras siempre son falsas, ¿por qué? arity == 0 Si el flujo de control llega al punto donde se evalúa esta subexpresión, sabremos que las dos subexpresiones anteriores son . We can also learn the following: false ix >= 1 ix = 1 arity I'll also leave fixing this code to the developers, since my only suggestion is to remove the condition. Errores críticos Fragment N8 El PVS-Studio advierte: El valor del índice 'prefix_len' podría llegar a 262. V557 erl_alloc_util.c 5375 El valor del índice 'prefix_len' podría llegar a 262. V557 erl_alloc_util.c 5378 El valor del índice 'prefix_len' podría llegar a 262. V557 erl_alloc_util.c 5381 #define MAX_ATOM_CHARACTERS 255 static void make_name_atoms(Allctr_t *allctr) { char alloc[] = "alloc"; char realloc[] = "realloc"; char free[] = "free"; char buf[MAX_ATOM_CHARACTERS]; size_t prefix_len = sys_strlen(allctr->name_prefix); if (prefix_len > MAX_ATOM_CHARACTERS + sizeof(realloc) - 1) erts_exit(ERTS_ERROR_EXIT, "Too long allocator name: %salloc\n" allctr->name_prefix); sys_memcpy((void *) buf, (void *) allctr->name_prefix, prefix_len); sys_memcpy((void *) &buf[prefix_len], (void *) alloc, sizeof(alloc) - 1); allctr->name.alloc = am_atom_put(buf, prefix_len + sizeof(alloc) - 1); sys_memcpy((void *) &buf[prefix_len], (void *) realloc, sizeof(realloc) - 1); allctr->name.realloc = am_atom_put(buf, prefix_len + sizeof(realloc) - 1); sys_memcpy((void *) &buf[prefix_len], (void *) free, sizeof(free) - 1); allctr->name.free = am_atom_put(buf, prefix_len + sizeof(free) - 1); } Entrar en modo de pantalla completa Salir en modo de pantalla completa Tenemos una función que genera nombres para las funciones de asignación y desasignación basándose en el prefixo que se le transmite. Se utiliza un buffer de 255 bytes para generarlos. A juzgar por el contenido de la función, no habrá un terminador nulo en el buffer generado, ya que pasa el tamaño total de la cadena generada. am_atom_put The very first thing the developers did was calculate the prefix size. Then, they limited the prefix size: if it exceeds the sum of La longitud de la string (the longest postfix), the function is called. MAX_ATOM_CHARACTERS realloc noreturn Luego, copiaron el prefijo al buffer, añadieron el postfix y pasaron la cadena al buffer. Los desarrolladores realizaron todas estas acciones secuencialmente para todos los postfixes: , de , y . am_atom_put alloc realloc free ¿Puede detectar la captura? La verificación de retorno temprano se realizó incorrectamente. El buffer debe tener suficiente espacio para escribir el postfix más largo, que es siete caracteres. Si la cadena de prefixo es entre 256 y 262 caracteres de largo, el retorno temprano no ocurre, por lo que la La función sobrepasa el buffer. Esta operación tiene un comportamiento indefinido. sys_memcpy Suponiendo que el La función funciona con cuerdas no más de Corregimos el código de la siguiente manera: am_atom_put MAX_ATOM_CHARACTERS if (prefix_len > MAX_ATOM_CHARACTERS - sizeof(realloc) + 1) Entrar en modo de pantalla completa Salir en modo de pantalla completa Ahora, la longitud máxima del prefixo es de 248 caracteres. Cuando se escribe el postfix máximo, no ocurrirá sobrecarga. Similar warnings: V557 Array overrun is possible. The value of 'i' index could reach 40. ycf_lexer.c 493 V557 Array overrun is possible. The value of 'n' index could reach 16. erl_call.c 1663 Fragment N9 Me gustaría presentar este ejemplo de una manera inusual. Primero, echemos un vistazo a esta función: static const char* event_state_flag_to_str(EventStateFlags f, const char *buff, int len) { switch ((int)f) { case ERTS_EV_FLAG_CLEAR: return "CLEAR"; case ERTS_EV_FLAG_USED: return "USED"; /* other cases that return string literals */ default: snprintf((char *)buff, len, "ERROR(%d)", f); return buff; } } Entrar en modo de pantalla completa Salir en modo de pantalla completa El function converts the enumeración a una cadena. para no- branches, devuelve una cadena literal. De lo contrario, la función crea una cadena en el buffer proporcionado y le devuelve un puntero. Nota cómo exactamente lo hace: el buffer descarta forzadamente la constancia. Según el estándar C, esto sólo se permite si el buffer de fuente no ha sido declarado como C11 El C23 ). event_state_flag_to_str EventStateFlags default switch const 6.7.3 El 6 6.7.4.1.7 ¿Realmente es así? miremos el punto de invocación: static ERTS_INLINE void print_flags(erts_dsprintf_buf_t *dsbufp, EventStateFlags f) { const char buff[64]; if (f & ERTS_EV_FLAG_WANT_ERROR) { erts_dsprintf(dsbufp, "WANTERR|"); f &= ~ERTS_EV_FLAG_WANT_ERROR; } erts_dsprintf(dsbufp, "%s", event_state_flag_to_str(f, buff, sizeof(buff))); } Enter fullscreen mode Exit fullscreen mode La función en cuestión se llama al pasar el buffer constante como el segundo argumento. Desafortunadamente, obtenemos comportamiento indefinido. encontramos este error usando el analizador, pero emitió una advertencia confusa: El buffer no inicializado 'buff' se utiliza. considere comprobar el segundo argumento real de la función 'event_state_flag_to_str'. V614 erl_check_io.c 2833 Vamos a corregir el código eliminando la constancia del buffer: static ERTS_INLINE void print_flags(erts_dsprintf_buf_t *dsbufp, EventStateFlags f) { char buff[64]; if (f & ERTS_EV_FLAG_WANT_ERROR) { erts_dsprintf(dsbufp, "WANTERR|"); f &= ~ERTS_EV_FLAG_WANT_ERROR; } erts_dsprintf(dsbufp, "%s", event_state_flag_to_str(f, buff, sizeof(buff))); } Entrar en modo de pantalla completa Salir en modo de pantalla completa También proponemos cambiar el función de firma, por lo que el parámetro puede tomar una Esto hace claro que la función puede modificar el buffer pasado a ella.No vamos a romper mucho código en el proceso ya que la función existe sólo en el archivo compilado y está marcado como . event_state_flag_to_str char* static Fragment N10 El aviso del PVS-Studio: The uninitialized class member 'a' is used when initializing the base class 'BeamAssemblerCommon'. V1050 beam_asm.hpp 87 class BeamAssemblerCommon : public ErrorHandler { BaseAssembler &assembler; protected: BeamAssemblerCommon(BaseAssembler &assembler); .... }; struct BeamAssembler : public BeamAssemblerCommon { BeamAssembler() : BeamAssemblerCommon(a) { /* .... */ } protected: a64::Assembler a; .... }; Entrar en modo de pantalla completa Salir en modo de pantalla completa This fragment contains a small class hierarchy where a reference to a non-static member function of the derived class, , se pasa al constructor de la clase base, . This operation won't cause any issues as long as the base class constructor doesn't interact with this member function. Why? The lifetime of an object from a derived class starts when the required initializer in the initialization list has been executed or, if there's no initializer, when the control flow enters the constructor body. BeamAssembler BeamAssemblerCommon Con esta información en mente, echemos un vistazo al constructor de clase base. ¿No utiliza este objeto, ¿verdad? BeamAssemblerCommon::BeamAssemblerCommon(BaseAssembler &assembler_) : assembler(assembler_), .... { .... #ifdef DEBUG assembler.addDiagnosticOptions(DiagnosticOptions::kValidateAssembler); #endif assembler.addEncodingOptions(EncodingOptions::kOptimizeForSize | EncodingOptions::kOptimizedAlign); .... } Enter fullscreen mode Exit fullscreen mode Nope :) Una función de miembro no estático se llama a un objeto de una clase derivada a través de una referencia cuando su vida aún no ha comenzado. También me resulta difícil sugerir una corrección en este caso, así que lo dejaré a los desarrolladores. Errores de memoria Fragment N11 El aviso del PVS-Studio: La función "libre" se llama dos veces para desalojar el mismo espacio de memoria. El 586 erl_call.c 668 int main(int argc, char *argv[]) { int fd; char *p = NULL; ei_cnode ec; .... int i = 0; ei_x_buff reply; .... if (ei_rpc(&ec, fd, "c", "c", p, i, &reply) < 0) { free(p); ei_x_free(&reply); fprintf(stderr,"erl_call: can't compile file %s\n", fname); } free(p); /* FIXME complete this code FIXME print out error message as term if (!erl_match(erl_format("{ok,_}"), reply)) { fprintf(stderr,"erl_call: compiler errors\n"); } */ ei_x_free(&reply); .... } Enter fullscreen mode Exit fullscreen mode juzgando por el nombre, is a . A negative number is returned if the operation fails. If the remote call fails, some resources are cleaned up. The Pointer se traslada a la function and an error is logged to Luego, independientemente del resultado de la llamada de la función, el again. Memory is released twice. ei_rpc remote procedure call p free stderr free The fix is pretty simple: either stop the program execution or set the freed pointers to zero. To fix the issue, I would interrupt execution here: if (ei_rpc(&ec, fd, "c", "c", p, i, &reply) < 0) { free(p); ei_x_free(&reply); fprintf(stderr,"erl_call: can't compile file %s\n", fname); return 1; } free(p); Entrar en modo de pantalla completa Salir en modo de pantalla completa Fragment N12 El aviso del PVS-Studio: El puntero 'pkey' se utilizó antes de ser verificado contra nullptr. líneas de control: 581, 582. V595 Página 581 static int get_pkey_public_key(ErlNifEnv *env, const ERL_NIF_TERM argv[], int algorithm_arg_num, int key_arg_num, EVP_PKEY **pkey, ERL_NIF_TERM *err_return) { .... if (enif_is_map(env, argv[key_arg_num])) { password = get_key_password(env, argv[key_arg_num]); *pkey = ENGINE_load_public_key(e, id, NULL, password); if (!pkey) assign_goto(*err_return, err, EXCP_BADARG_N(env, key_arg_num, "Couldn't get public key from engine")); } /* other branches */ ret = 1; done: .... return ret; err: .... *pkey = NULL; ret = 0; goto done; } Entrar en modo de pantalla completa Salir en modo de pantalla completa Aquí tenemos un fragmento de código bastante interesante. intenta extraer la clave pública hasta el quinto parámetro. if successful and si no. En este último caso, la llave pública también está cero. Funciones 1 0 The analyzer warns that, in one of the function branches, the el indicador es dereferenciado antes de ser comprobado para la validez. Sin embargo, otras ramas no parecen tener tales comprobaciones. Podemos concluir que la función tiene el siguiente contrato: "El parameter must never be equal to a ." Podemos confirmar esto buscando llamadas a esta función en el mismo archivo ([ ], [ ] , [ ])—the variable address is passed everywhere. pkey pkey nullptr 1 2 3 In fact, the developers intended to handle the incorrect result of the La función de saltar a la No obstante, hicieron un tipo al olvidar colocar un asterisco antes de la Un compilador moderno esta verificación en la liberación. Como resultado, la función volverá a , y un puntero nulo terminará en el quinto parámetro. ENGINE_load_public_key err ! Optimiza la distancia 1 Vamos a hacer el cheque: .... *pkey = ENGINE_load_public_key(e, id, NULL, password); if (!*pkey) assign_goto(*err_return, err, EXCP_BADARG_N(env, key_arg_num, "Couldn't get public key from engine")); .... Enter fullscreen mode Exit fullscreen mode Fragment N13 A menudo recibimos mensajes que dicen que el analizador advierte sobre el paso de un puntero nulo a Después de todo, los estándares dicen que no pasará nada terrible. Sobre un caso similar. free article Sí, eso está bien, pero tal código es probablemente sospechoso. Esto nos ayudó a encontrar una interesante fuga de memoria en el código. The PVS-Studio warning: The null pointer is passed into 'free' function. Inspect the first argument. V575 erl_misc_utils.c 264 void erts_cpu_info_destroy(erts_cpu_info_t *cpuinfo) { if (cpuinfo) { cpuinfo->configured = 0; cpuinfo->online = 0; cpuinfo->available = 0; #ifdef HAVE_PSET_INFO if (cpuinfo->cpuids) free(cpuinfo->cpuids); #endif cpuinfo->topology_size = 0; if (cpuinfo->topology) { cpuinfo->topology = NULL; free(cpuinfo->topology); } free(cpuinfo); } } Enter fullscreen mode Exit fullscreen mode En este fragmento, el pointer is explicitly set to Antes de llamar Como resultado, la operación de liberación de memoria es inútil, ya que does nothing. This results in memory leaks because the original memory block that Se dice que nunca se liberan. cpuinfo->topology NULL free free(NULL) cpuinfo->topology We can fix the issue by swapping the operations: if (cpuinfo->topology) { free(cpuinfo->topology); cpuinfo->topology = NULL; } Entrar en modo de pantalla completa Salir en modo de pantalla completa Fragment N14 The PVS-Studio warning: The function was exited without releasing the 'entry' pointer. A memory leak is possible. V773 wxe_gl.cpp 88 typedef struct _wxe_glc { wxGLCanvas *canvas; wxGLContext *context; } wxe_glc; void setActiveGL(wxeMemEnv *memenv, ErlNifPid caller, wxGLCanvas *canvas, wxGLContext *context) { ErlNifUInt64 callId = wxe_make_hash(memenv->tmp_env, &caller); wxe_glc * entry = glc[callId]; gl_active_index = callId; gl_active_pid = caller; if (!entry) { entry = (wxe_glc *) malloc(sizeof(wxe_glc)); entry->canvas = NULL; entry->context = NULL; } if (entry->canvas == canvas && entry->context == context) return; entry->canvas = canvas; entry->context = context; glc[gl_active_index] = entry; .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa In the La función, el indicador se declara e inicia a través de un elemento de array. Si este elemento es un indicador null, la memoria se asigna utilizando . Next, the pointers are compared. If it evaluates to , ocurrirá un retorno temprano. Sin embargo, si se produjo la asignación dinámica, la memoria no se liberará. setActiveGL entry malloc true Sí, tal situación es bastante rara y poco probable que suceda, porque requiere una serie entera de eventos: when the function is called, zero pointers are passed as the third and fourth arguments. glc[callId] contiene un puntero nulo. However, we can ensure that a leak will never occur, not even theoretically. Let's modify the code a little: ErlNifUInt64 callId = wxe_make_hash(memenv->tmp_env, &caller); wxe_glc * entry = glc[callId]; gl_active_index = callId; gl_active_pid = caller; bool new_alloc = false; if (!entry) { entry = (wxe_glc *) malloc(sizeof(wxe_glc)); entry->canvas = NULL; entry->context = NULL; new_alloc = true; } if (entry->canvas == canvas && entry->context == context) { if (new_alloc) { free(entry); } return; } .... Entrar en modo de pantalla completa Salir en modo de pantalla completa Similar warnings: V773 The function was exited without closing the file referenced by the 'f' handle. A resource leak is possible. erl_poll.c 2423 V773 El indicador 'erl_errno_p' se asignó valores dos veces sin liberar la memoria. es posible una fuga de memoria. ei_pthreads.c 195 V773 La función se salió sin cerrar el archivo referenciado por el manejo 'fp'. es posible una fuga de recurso. cpu_sup.c 433 V773 The exception was thrown without releasing the 'data' pointer. A memory leak is possible. wxe_wrapper_4.cpp 1300 V773 La excepción se lanzó sin liberar el puntero 'datos'. una fuga de memoria es posible. wxe_wrapper_4.cpp 1330 V773 La excepción se lanzó sin liberar el puntero 'datos'. una fuga de memoria es posible. wxe_wrapper_4.cpp 1663 V773 La excepción se lanzó sin liberar el puntero 'datos'. una fuga de memoria es posible. wxe_wrapper_4.cpp 1690 V773 The exception was thrown without releasing the 'data' pointer. A memory leak is possible. wxe_wrapper_4.cpp 1715 V773 La excepción se lanzó sin liberar el puntero 'alfa'. una fuga de memoria es posible. wxe_wrapper_4.cpp 1718 V773 The exception was thrown without releasing the 'data' pointer. A memory leak is possible. wxe_wrapper_4.cpp 1747 V773 The exception was thrown without releasing the 'alpha' pointer. A memory leak is possible. wxe_wrapper_4.cpp 1750 V773 La excepción se lanzó sin liberar el puntero 'alfa'. una fuga de memoria es posible. wxe_wrapper_4.cpp 2680 V773 The exception was thrown without releasing the 'data' pointer. A memory leak is possible. wxe_wrapper_4.cpp 2715 V773 La excepción se lanzó sin liberar el puntero 'datos'. una fuga de memoria es posible. wxe_wrapper_4.cpp 2733 Fragment N15 El aviso del PVS-Studio: realloc() posible fuga: cuando realloc() falla en la asignación de la memoria, se pierde el puntero original 'outbuf_base'. V701 run_erl.c 1324 static void outbuf_append(const char* buf, int n) { .... /* * Allocate a larger buffer if we still cannot fit the data. */ if (outbuf_base+outbuf_total < outbuf_in+n) { int size = outbuf_in - outbuf_out; outbuf_total = size+n; outbuf_base = realloc(outbuf_base, outbuf_total); outbuf_out = outbuf_base; outbuf_in = outbuf_base + size; } .... } Enter fullscreen mode Exit fullscreen mode Hay un patrón tricky con la función, donde el puntero original es inmediatamente sobreescrito por el valor de devolución. realloc The function takes the buffer for reallocation as its first argument and the new buffer size as its second argument. If the operation is successful, the function will return a pointer to the newly allocated memory. The memory passed as the first argument becomes , incluso si sólo se ha producido una simple expansión de bloque de memoria. Si la operación falla, la función devuelve una La memoria pasó como el primer argumento permanece . invalid null pointer untouched Así, si reescribimos inmediatamente el puntero original con una llamada a , we will get a memory leak. realloc Let's fix the code as follows: static void outbuf_append(const char* buf, int n) { .... /* * Allocate a larger buffer if we still cannot fit the data. */ if (outbuf_base + outbuf_total < outbuf_in + n) { int size = outbuf_in - outbuf_out; outbuf_total = size+n; char *tmp = realloc(outbuf_base, outbuf_total); if (!tmp) { /* somehow handle this scenario * the `outbuf_base` buffer here is still valid */ } outbuf_base = tmp; outbuf_out = outbuf_base; outbuf_in = outbuf_base + size; } .... } Enter fullscreen mode Exit fullscreen mode En el ejemplo fijo, también debemos abordar la situación en la que Este puede ser un lanzamiento excepcional, un intento de asignar un buffer de un tamaño diferente, y así sucesivamente. realloc Fragment N16 El aviso del PVS-Studio: El puntero 'end' en la expresión 'end - mm->sua.top' equivale a nullptr. El valor resultante no tiene sentido y no debe utilizarse. V769 erl_mmap.es 2411 static void add_free_desc_area(ErtsMemMapper* mm, char *start, char *end) { ERTS_MMAP_ASSERT(end == (void *) 0 || end > start); if (sizeof(ErtsFreeSegDesc) sua.top` always will * compare as larger than all segment pointers * into the super carrier... */ mm->sua.top -= ERTS_PAGEALIGNED_SIZE; mm->size.supercarrier.used.total += ERTS_PAGEALIGNED_SIZE; #ifdef ERTS_HAVE_OS_PHYSICAL_MEMORY_RESERVATION if (!virtual_map || os_reserve_physical(mm->sua.top, ERTS_PAGEALIGNED_SIZE)) #endif add_free_desc_area(mm, mm->sua.top, end); mm->desc.reserved += (end - mm->sua.top) / sizeof(ErtsFreeSegDesc); } .... } Entrar en modo de pantalla completa Salir en modo de pantalla completa El analista ha detectado aritmética de direcciones sospechosas.Vamos a ver qué está mal aquí. Introduzca la rama de código donde De hecho, es un punto cero. data member is also a pointer, but we don't know its value yet. According to the C standard, the behavior of pointers that differ is defined only when they both point to elements of the same array (C11 ; C23 ). The null pointer doesn't point to any array element. So, the behavior of this operation is undefined, which isn't good. end mm->sua.top 6.5 6.8 6.5.7 El 10 I was wondering what happens in the Funcionamiento . add_free_desc_area static void add_free_desc_area(ErtsMemMapper* mm, char *start, char *end) { ERTS_MMAP_ASSERT(end == (void *) 0 || end > start); if (sizeof(ErtsFreeSegDesc) <= ((UWord) end) - ((UWord) start)) { .... } Enter fullscreen mode Exit fullscreen mode Aquí también se utiliza la subtracción del puntero, pero con una diferencia: primero, los punteros se convierten en números. El C23 ), which is much better. 6.3.2 El 6.3 6.3.2 El 6.3 Unfortunately, I can't suggest a proper fix. The developers might want to take a look into this issue. Conclusión Well, that concludes the article. As expected with any large project that has had a long and eventful history, we found various errors. They're also part of the project, though. It's important to keep in mind that finding these kinds of issues in a code base that's over three decades old isn't a sign of weakness. Rather, it's proof of the code's incredible scale and longevity. There are millions of code lines written by hundreds of developers, and the system has been running for years without rebooting. This project deserves the deepest respect, not because it's perfect, but because it has stood the test of time and proven its real power. Thanks to constantly evolving modern technologies, developers have powerful tools at their disposal to improve code reliability. For example, static analyzers help identify hidden errors and potential vulnerabilities. I invite you to see it for yourself :) You can get a trial version of PVS-Studio analyzer . Aquí