10 notábeis erros de C e C++ atopados en proxectos de código aberto en 2025

Durante todo o ano, estabamos montando polas vastas chairas de código aberto, investigando crimes, eliminando vulnerabilidades e recollendo trofeos.Hoxe, decidimos entrar no salón máis poeirento: un xerife experimentado inclínase contra a barra e lembra sobre os dez bugs máis atrevidos e perigosos do Oeste Salvaxe. Queres unha historia interesante? Durante todo o ano, loitamos contra varios bugs de proxectos de código aberto C e C++. Atopamos cada un deles, interrogámolo e rexistramos as súas faltas no ficheiro. Hoxe vou contarvos unha historia sobre os 10 bugs máis interesantes que atopamos en diferentes recunchos do Oeste Salvaxe. Para cada un destes fragmentos, temos un arquivo separado - un artigo completo. Como o uso frívolo de alocadores polimórficos pode imitar a túa vida Guía do programador C++ para o comportamento indefinido Historia de C e C++. Parte dous: estandarización de C e C++, Qt, Clang e Unreal Engine std::array en C++ é máis rápido que array en C. Ás veces Safe array handling? Nunca oíron falar dela Nunca oíron falar dela Podes atopar a lista completa de artigos do noso blog na nosa web a través do enlace. Ligazón Senta, viaxeiro, a historia será unha longa N10 Once, we had a case about a missing horse. The mare was always in the stable, but whenever we wanted to ride to town, it seemed to vanish into thin air. O PVS-Studio advirte: The literal '0.5f' of 'float' type is being implicitly cast to 'unsigned char' type while calling the 'SetRenderColor' function. Inspect the second argument. 168 Páxina 674 granada_bugbait.cpp typedef unsigned char byte; inline void CBaseEntity::SetRenderColor( byte r, byte g, byte b, byte a ) { m_clrRender.Init( r, g, b, a ); } void CGrenadeBugBait::BugBaitTouch( CBaseEntity *pOther ) { .... if ( pSporeExplosion ) { .... pSporeExplosion->SetRenderColor( 0.0f, 0.5f, 0.25f, 0.15f ); // <= .... } .... } A súa function sets the valores de cor, onde cada parámetro é do tipo con un posible rango de valores de Cando se propoñen os argumentos da por exemplo, a parte fractal será truncada. polo tanto, , , , Os parámetros da función terán valores iguais . SetRenderColor RGBA unsigned char [0 .. 255] float r g b a 0 Desafortunadamente, o repositorio carece de información de culpa, polo que teño dous escenarios sobre como este erro apareceu no código. A función algunha vez procesou cores nunha representación de puntos flotantes.O procesamento foi posteriormente cambiado a inteiros, pero non todos os sitios de chamada foron actualizados. O desenvolvedor equivocadamente creu que SetRenderColor manexou os números de puntos flotantes e os estableceu de acordo. Velaquí algunhas advertencias similares: V674 O literal '0.5f' do tipo 'float' está a ser implicitamente lanzado ao tipo 'unsigned char' ao chamar a función 'SetRenderColor'. V674 O literal '25.6' do tipo 'doble' está a ser implicitamente lanzado ao tipo 'int' ao chamar a función 'SetScrollRate'. Detectamos este bug no proxecto Source SDK. Podes atopar o artigo completo no enlace. Ligazón N9 Unha vez tivemos que montar cen camiños iguais a través da pradería. Sucedeu que nos viramos a un que xa íamos montando. O PVS-Studio advirte: O uso de 'se (A) {...} outro se (A) {...}' patrón foi detectado. Hai unha probabilidade de presenza de erro lóxico. liñas de comprobación: 2903, 3053. Xestión 517 erl_bif_info.c 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 .... } } O analizador detectou varias ramas con controis idénticos nunha función que contén un gran número de Declaracións - Pero cada un deles ten unha lóxica diferente: e Dado o número de ramas e a diferenza de 150 liñas entre os duplicados, non é sorprendente que isto puidese ocorrer. if-else if Máis de 800 liñas A primeira comprobación Segunda comprobación We detected this bug in the Erlang project; you can find the full article at the . link Ligazón N8 Coñecía un xerife que só tiña un veredicto para todos os crimes: "Non culpable". The PVS-Studio warning: A declaración "entón" é equivalente ao fragmento de código posterior. V523 reproducións cmComputeLinkInformación.cxx 1748 bool cmComputeLinkInformation::CheckImplicitDirItem(LinkEntry const& entry) { BT const& item = entry.Item; // We only switch to a pathless item if the link type may be // enforced. Fortunately only platforms that support link types // seem to have magic per-architecture implicit link directories. if (!this->LinkTypeEnabled) { return false; } // Check if this item is in an implicit link directory. std::string dir = cmSystemTools::GetFilenamePath(item.Value); if (!cm::contains(this->ImplicitLinkDirs, dir)) { // Only libraries in implicit link directories are converted to // pathless items. return false; } // Only apply the policy below if the library file is one that can // be found by the linker. std::string file = cmSystemTools::GetFilenameName(item.Value); if (!this->ExtractAnyLibraryName.find(file)) { return false; } return false; } O analista suxire que hai definitivamente algo errado co function: CheckImplicitDirItem a rama da última se a declaración duplica o código de abaixo (devolve falso); cada rama da execución da función remata con falsa devolución; cando se chama desde AddFullItem, nunca desencadeará un retorno precoz; the full function body can be replaced with , as this won't change the program behavior. return false; Ten en conta que a función está escrita usando o " Un patrón que axuda a reducir o nicho de código: o resultado máis positivo colócase ao final da función, e o resto do código -en caso de diverxencia co propósito da función- debe terminar a función o antes posible. early return No noso exemplo, podemos supor que o resultado máis "positivo" da función é que un obxecto da función pasou todas as comprobacións necesarias cunha Devolución do valor. LinkEntry true Aquí está unha opción de como corrixir o código: .... std::string file = cmSystemTools::GetFilenameName(item.Value); if (!this->ExtractAnyLibraryName.find(file)) { return false; } return true; Detectamos este bug no proxecto CMake; podes atopar o artigo completo no enlace. Ligazón N7 Unha vez nunha aldea, vin un xogador desesperado que apostou todo o seu ouro na tarxeta que non estaba nin sequera no paquete. O PVS-Studio advirte: Dereferencing of the invalid iterator 'shades.end()' might take place. Páxina 783 ColorHelper.cpp 194 Páxina winrt::Windows::UI::Color ColorHelper::GetAccentColor( const winrt::Windows::UI::Color& color ) { .... auto shades = std::map (); .... // 3f is quite nice if the whole non-client area is painted constexpr auto readability = 1.75f; for (auto shade : shades) { if (shade.first >= readability) { return HslToRgb(shade.second); } } return HslToRgb(shades.end()->second); // <= } É posible que ningunha das tonalidades cumpra os criterios de lexibilidade? Non podemos dicir con certeza, pero é bastante probable. of Non hai necesidade de descargar ningún papel psíquico para demostralo, xa que causa exactamente iso, xa que este iterador apunta ao último elemento nun . Texto do caso Comportamento indefinido std::map::end() std::map Detectamos este bug no proxecto Windows Terminal; podes atopar o artigo completo na ligazón. Ligazón N6 Unha vez fixen un acordo con un compañeiro de viaxe para dividir un tesouro que atopamos.El tocou, virou e desapareceu como un miradoiro.Ninguén o viu desde entón. The PVS-Studio warning: A referencia "grafa" vólvese inválida cando se destrúe o indicador intelixente devolto por unha función. Páxina 758 Páxina oficial: cpp 391 template struct Ptr : public std::shared_ptr ; // .... Ptr FlannNeighborhoodGraph::create( const Mat &points, int points_size, int k_nearest_neighbors_, bool get_distances, int flann_search_params_, int num_kd_trees) { return makePtr (points, points_size, k_nearest_neighbors_, get_distances, flann_search_params_, num_kd_trees); } void Utils::densitySort (const Mat &points, int knn, Mat &sorted_points, std::vector &sorted_mask) { // .... // get neighbors FlannNeighborhoodGraph &graph = // sum_knn_distances (points_size, 0); for (int p = 0; p &dists = graph.getNeighborsDistances(p); for (int k = 0; k struct Ptr : public std::shared_ptr { inline Ptr(const std::shared_ptr & o) CV_NOEXCEPT : std::shared_ptr (o) {} inline Ptr(std::shared_ptr && o) CV_NOEXCEPT : std::shared_ptr (std::move(o)) {} typename std::add_lvalue_reference ::type operator*() const CV_NOEXCEPT { return *std::shared_ptr ::get(); } // .... } template static inline Ptr makePtr(const A1&... a1) { static_assert( !has_custom_delete ::value, "Can't use this makePtr with custom DefaultDeleter"); return (Ptr )std::make_shared (a1...); } Usando apontadores intelixentes non resolve os problemas de referencias e acceso á memoria aquí. A función crear crea e devolve un ponteiro intelixente ao tipo FlannNeighborhoodGraphImpl, e o seu número de referencia de obxecto é un. A referencia gráfica créase para o valor deste indicador intelixente, mentres que o número de referencia de obxecto permanece inalterado. Dado que o indicador é un obxecto temporal, o contador de referencia alcanzará o nulo despois de que se realice a inicialización, liberando o obxecto xestionado. As referencias para loop son unha referencia inválida. Como resultado, o código que parecía correcto leva a un comportamento indefinido.Ademais, PVS-Studio non é a única ferramenta que detecta este problema; o sanitizador tamén o fai. . Proba To fix this, we need to save the smart pointer so that the O obxecto permanece ata o final do bloque. por exemplo, podemos facer : FlannNeighborhoodGraph como esta std::vector sum_knn_distances (points_size, 0); { // get neighbors auto graph = FlannNeighborhoodGraph::create(points, points_size, knn, true /*get distances */, 6, 1); for (int p = 0; p &dists = graph->getNeighborsDistances(p); for (int k = 0; k < knn; k++) sum_knn_distances[p] += dists[k]; } } Tamén limitamos a Liberar o recurso despois da execución do ciclo. graph Detectamos este bug no proxecto OpenCV; podes atopar o artigo completo no . Ligazón N5 Unha vez, un experto local debuxou un mapa dun cruceiro de río, pero escapou do carbón.Entón, a sección máis perigosa, debuxada cos últimos anacos de carbón, lavada coa primeira chuvia. O PVS-Studio advirte: Considere inspeccionar a expresión '1 type + 1)'. bit desplazamento do valor de 32 bits cunha subsequente expansión ao tipo de 64 bits. O 629 phpdbg_bp.c 1209 O tamaño da máscara de bits é menor que o tamaño do primeiro operando. Páxina 784 phpdbg_bp.c 1209 uint64_t flags .... PHPDBG_API void phpdbg_delete_breakpoint(zend_ulong num) { .... if ((brake = phpdbg_find_breakbase_ex(num, &table, &numkey, &strkey))) { int type = brake->type; char *name = NULL; size_t name_len = 0L; switch (type) { .... default: { if (zend_hash_num_elements(table) == 1) { PHPDBG_G(flags) &= ~(1 type+1)); // type int flags A constante 1 do tipo int é desprazada deixada por un certo número de bits. Na maioría das veces, o tipo int é de 32 bits. Esperamos que o desprazamento non sexa por 32 ou máis bits, doutro xeito obtemos comportamento indefinido. O resultado da inversión aínda ten o tipo int. O resultado da inversión esténdese a un tipo non asinado de 64 bits debido ao operando esquerdo. Xa que o tipo orixinal está asinado, ocorrerá a extensión de signo. Isto significa que para números positivos, os 32 bits máis significativos conterán bits cero, e para números negativos, conterán aqueles. O bitwise "AND" aplica o resultado de conversión ás bandeiras. A perda de bits significativos nas bandeiras ocorrerá cando o operando dereito é positivo. Só será así cando hai un desprazamento de 31 bits cara á esquerda - cando o 31o bit nas bandeiras debe ser eliminado. Observe canto temos que ter en conta para unha expresión tan inofensiva? O problema reside nos diferentes tamaños de operand e signos dalgunhas subexpresións. Para corrixilo, os desenvolvedores só necesitan cambiar o tipo de constante de Dúas , e o código executarase como se pretendía: 1 int unsigned long long PHPDBG_G(flags) &= ~( 1uLL type+1)); Descubrimos este bug no proxecto PHP; podes atopar o artigo completo a través do . Ligazón N4 Unha vez vin un mozo vaqueiro perseguindo a un ilexítimo, que o afundiu nun punto morto nun dos bares locais, pero non disparou ao delincuente, senón ao seu propio reflexo nun espello poeirento, rompéndoo en anacos. The PVS-Studio warning: O operador de asignación debe estar protexido do caso de "este == e outros". Páxina 794 fs_path.cpp 36 Páxina FsPath& FsPath::operator=(FsPath&& other) { m_path = std::move(other.m_path); other.m_path.clear(); return *this; } Neste fragmento, temos o operador de asignación de movemento para o class, which transfers data from the other object to the current instance. However, there's no check for self-assignment , which could lead to unintended consequences. FsPath (this == &other) If an attempt is made to assign the object to itself, the A operación move os contidos de en O seguinte chamamento a Describe os datos, polo tanto, ends up in an unexpected state, and one can only wish developers happy debugging :) m_path = std::move(other.m_path); other.m_path m_path other.m_path.clear(); m_path Para eliminar o risco, recomendamos engadir a seguinte comprobación ao comezo do operador: if (this == std::addressof(other)) { return *this; } Using No canto de que o operator ensures correct address comparison even when the operator Están sobrecargados na clase. std::addressof & & We detected this bug in the Nau Engine project; you can find the full article at the . link Ligazón N3 Unha vez vin un xamán tentando chamar un espírito sen chegar aos terreos sagrados.Un espírito veu, pero era un completamente diferente: un coyote do barranco máis próximo. The PVS-Studio warning: sing the 'window_id' function of uninitialized derived class while initializing the 'modal_dialog' base class will lead to undefined behavior. 29 V1099 Páxina install_dependencies.hpp class install_dependencies : public modal_dialog { public: explicit install_dependencies(const addons_list& addons) : modal_dialog(window_id()), addons_(addons) // <= {} .... private: virtual const std::string& window_id() const override; .... } Grazas a este fragmento de código, podo dicirche máis sobre o comportamento indefinido. Como podedes ver máis arriba, o A clase xurdiu da class. In the constructor, the base class is initialized with the value returned by (wait for it...) the non-static Funcións: Isto é o que vai pasar: install_dependencies modal_dialog install_dependencies window_id Execution of the initialization list: a call to the method; install_dependencies::window_id a constructor call to the class; modal_dialog an initialization of the data member; addons_ Execución do corpo construtor da clase install_dependencies. Isto dá lugar a unha chamada de función dun obxecto de clase que aínda non foi inicializado! : Regra do estándar As funcións de membro (incluídas as funcións de membro virtual, [class.virtual]) poden ser chamadas para un obxecto en construción Do mesmo xeito, un obxecto en construción pode ser o operando do operador de tipo ([ex.typeid]) ou dun dinámico_cast ([ex.dynamic.cast]). However, if these operations are performed in a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the program has undefined behavior. But wait, there's more! As you may have noticed, the A función de membro é virtual e sobrecargada na class. Issues may arise later when a programmer writes a derived class where É unha exageración. window_id install_dependencies window_id Cando se crea un obxecto desta clase derivada e constructor is executed, there's no information about the existence of the new override yet. So, the A función sempre será chamada na lista de inicialización. Isto pode diferir da intención orixinal dos desenvolvedores. . installed_dependencies installed_dependencies::window_id aquí We detected this bug in the Wesnoth project; you can find the full article at the . Ligazón Ligazón N2 Coñecín a un cowboy que disparou a unha sombra na parede, confundíndoo cun inimigo escondido.O disparo explotou, o goma rompeu, deixando só un buraco na parede. The PVS-Studio warning: The null pointer is passed into 'fseek' function. Inspect the first argument. Xestión 575 vid_ati_eeprom.c 61 void ati_eeprom_load_mach8(ati_eeprom_t *eeprom, char *fn, int mca) { FILE *fp; .... fp = nvr_fopen(eeprom->fn, "rb"); size = 128; if (!fp) { if (mca) { (void) fseek(fp, 2L, SEEK_SET); // data + 2, 0xff, size - 2); fp = nvr_fopen(eeprom->fn, "wb"); fwrite(eeprom->data, 1, size, fp); .... } Necesitamos cargar os datos almacenados no NVRAM do adaptador de vídeo, que mantemos nun ficheiro binario. Se o ficheiro non existe, necesitamos crealo con datos "default". Nul pointer dereferencia. fp Let's take a closer look at . The A norma non define requisitos para o primeiro parámetro da función e non garante unha verificación de Isto significa que depende dos desenvolvedores de bibliotecas estándar para manexalo correctamente. fseek X11 NULL GNU glibc; BSD libc de FreeBSD 14.3 Microsoft Universal CRT from Windows SDK 10.0.26100; Páxina v1.2.5. As dúas últimas implementacións estándar da biblioteca C están aquí como convidados: 86Box non está deseñado para traballar con eles, ou a súa compatibilidade non foi verificada. don't mention alternative implementations either. So, let's start with the expected standard libraries and ask them to repeat the same actions with a null file pointer. Construír instrucións Flicking the power switch Tomamos un IBM PS/2 modelo 55SX da estante imaxinaria e "plug-in" o IBM 8514 / A 2D acelerador feito por ATI. The first test subject is a Windows instance built using MinGW. We ensure the NVRAM file is absent before starting—we check the directory for the . file. If it is there, we delete it. %userprofile%\86Box VMs\ \nvr ati8514_mca.nvr que O acceso á subministración de enerxía e... que Nada explotou! Todo está ben: o ficheiro NVRAM está escrito, o ordenador está en execución e a proba de fume en glibc está completa. A biblioteca libc implementa a biblioteca C estándar neste OS. Isto é xeralmente certo para todos os sistemas operativos da familia BSD. Usamos a mesma configuración. Verificamos a ausencia do Ficheiro NVRAM na Tres, dous, un, o poder está en... ati8514_mca.nvr ~/.local/share/86Box/Virtual Machines/ /nvr que Aínda que só un evento de O pasado pasado podería describir mellor esta situación :) Ben Grubbs » Despois de abrir os ollos, espreitados pechados despois da explosión, miramos ao console: confirmamos unha saída anormal! void VMManagerSystem::launchMainProcess() Full Command: "/root/86Box/build_freebsd/src/86Box" ("--vmpath", "/root/.local/share/86Box/Virtual Machines/somevm", "--vmname", "somevm") Connection received on 86Box.socket.5876c5 Connection disconnected Abnormal program termination while launching main process: exit code 11, exit status QProcess::CrashExit A core dump file appeared next to the emulator executable. Let's welcome LLDB: root@freebsd:~/86Box/build_freebsd/src # lldb 86Box -c 86Box.core (lldb) target create "86Box" --core "86Box.core" Core file '/root/86Box/build_freebsd/src/86Box.core' (x86_64) was loaded. (lldb) bt * thread #1, name = '86Box', stop reason = signal SIGSEGV * frame #0: 0x0000000832f880bf libc.so.7`_flockfile(fp=0x0000000000000000) at _flock_stub.c:65:20 frame #1: 0x0000000832f8b675 libc.so.7`fseek(fp=0x0000000000000000, offset=2, whence=0) at fseek.c:62:2 frame #2: 0x00000000018cd964 86Box`ati_eeprom_load_mach8(eeprom=...., fn= , mca=1) at vid_ati_eeprom.c:61:20 The null pointer fai un espectáculo de lume espectacular - non había xeito de bloquear o arquivo xa que o seu descriptor é inválido. or with a loud boom and special effects. Therefore, I can't show you how the code is executed like in Windows. fp lost connection Detectamos este bug no proxecto 86Box; podes atopar o artigo completo no enlace. Ligazón N1 Un xerife que coñezo dunha cidade veciña escribiu unha vez nunha transcrición de interrogatorio que unha testemuña confirmara o seu propio testemuño. O PVS-Studio advirte: Hai subexpresións idénticas á esquerda e á dereita do operador '==': PeekArg.getValNo() == PeekArg.getValNo() V501 PPCISelLowering.cpp 7865 SDValue PPCTargetLowering::LowerCall_AIX(....) const { .... for (unsigned I = 0, E = ArgLocs.size(); I != E;) { .... CCValAssign &GPR1 = VA; .... if (I != E) { // If only 1 GPR was available, there will only be one custom GPR and // the argument will also pass in memory. CCValAssign &PeekArg = ArgLocs[I]; if (PeekArg.isRegLoc() && PeekArg.getValNo() == PeekArg.getValNo()) // <= { assert(PeekArg.needsCustom() && "A second custom GPR is expected."); CCValAssign &GPR2 = ArgLocs[I++]; RegsToPass.push_back(std::make_pair(GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); } } .... } We're assuming for now that it's yet another victim of copy paste. Let's check whether Teñen efectos secundarios: getValNo class CCValAssign{ .... unsigned ValNo; unsigned getValNo() const { return ValNo; } } Non hai nada de estraño aquí, pero mira o último : Compromiso CCValAssign &GPR1 = VA; .... assert(I != E && "A second custom GPR is expected!"); CCValAssign &GPR2 = ArgLocs[I++]; assert(GPR2.isRegLoc() && GPR2.getValNo() == GPR1.getValNo() && GPR2.needsCustom() && "A second custom GPR is expected!"); RegsToPass.push_back( std::make_pair(GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); A idea é clara: un caso excepcional que anteriormente estaba gardado por un argumento foi redeseñado nunha rama regular. Este parche implementa o lado do chamador de argumentos de chamada de función de colocación Isto elimina a limitación actual onde LLVM en AIX Informará de erro fatal cando os argumentos non se poidan conter nos rexistros. Note that, in addition to the error found, there's another strange assignment: CCValAssign &PeekArg = ArgLocs[I]; .... CCValAssign &GPR2 = ArgLocs[I++]; // here PeekArg == GPR2 O desenvolvedor pode ter intención de escribir algo así: if (I != E) { CCValAssign &GPR2 = ArgLocs[I]; if (GPR2.isRegLoc() && PeekArg.getValNo() == GPR1.getValNo()) { assert(PeekArg.needsCustom() && "A second custom GPR is expected."); I++; RegsToPass.push_back(std::make_pair( GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); } } Pero para a claridade, os desenvolvedores romperon de para demostrar que, a diferenza do código incondicional anterior, o argumento agora ten que ser "peeked" primeiro. De súpeto caeu da súa condición. PeekArg GPR2 GPR1 The corrected Probablemente debería ser: if if (PeekArg.isRegLoc() && PeekArg.getValNo() == GPR1.getValNo()) Curiosamente, antes de migrar a GitHub, LLVM tiña unha plataforma de revisión de código, e o compromiso incluíu unha to this website. There, we can see that manual review can't always save the situation: link que Atopamos este bug no proxecto LLVM, o artigo completo está dispoñible no enlace. Ligazón Conclusion O silencio caeu sobre o salón, rompido só polo craque da porta de entrada e o craqueo dos rexistros na lareira. Dez bugs máis atrevidos de 2025 son agora só historias transmitidas de xeración en xeración. Neste oeste salvaxe, non pode chegar lonxe sen un compañeiro fiable, polo que o meu axudante de confianza en todos os casos foi está listo para axudarche a atopar fragmentos de código perigosos: PvP Estudo for ; open-source projects con fins educativos; Use unha versión de proba de 30 días para un comezo glorioso. And if your path leads you to other territories, I suggest listening to stories about bugs from projects written in Java and C#. Os 10 mellores erros de Java en 2025 Top 10 erros atopados en proxectos de C# en 2025.