Dear Prof. Dr. Ivan Krylov, I hope you are doing well.
Thanks for your prompt reply. I shall try to implement a fix and resumit based on this. It is a valuable suggestion. —— Mauricio "Pachá" Vargas Sepúlveda PhD Student, Political Science University of Toronto ________________________________________ From: Ivan Krylov <ikry...@disroot.org> Sent: November 11, 2024 4:48 AM To: Mauricio Vargas Sepulveda <m.sepulv...@mail.utoronto.ca> Cc: r-package-devel@r-project.org <r-package-devel@r-project.org> Subject: Re: [R-pkg-devel] Possible false negative for compiled C++ code in CRAN checks [You don't often get email from ikry...@disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Dear Mauricio Vargas Sepulveda, Welcome to R-package-devel! В Sat, 9 Nov 2024 17:34:07 +0000 Mauricio Vargas Sepulveda <m.sepulv...@mail.utoronto.ca> пишет: > CRAN reported memory leaks for: > > CLAN/ASAN: > https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/redatam/00check.log > CLANG/UBSAN: > https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/redatam/00check.log These include container-overflow at src/redatamlib/ByteArrayReader.cpp:170:23 and method calls with `this` being a null pointer at src/redatamlib/FuzzyVariableParser.cpp:47 and src/redatamlib/Entity.cpp:52. A container-overflow in ByteArrayReader::ReadByte is dangerous because the code is reading past the end of the vector populated with known data. While the code doesn't crash, the remainder of the vector could contain anything. This could invalidate the conclusions of a scientific work if they end up being based on random contents of uninitialised memory. You need to find out why m_currPos exceeds the number of bytes in the array and prevent it from happening. Calling methods on a null pointer is also an error in the code. This is quite confusing, but I have a guess for what might be causing this: for (size_t i = 0; i < entities.size() - 1; ++i) { ret.push_back( {entities[i].GetBounds().second, entities[i + 1].GetBounds().first}); } If entities.size() is 0, entities.size() - 1 will overflow to a large positive number, due to std::vector<T>::size_type being unsigned. The loop will proceed accessing out-of-bounds elements of 'entities' until something will cause it to crash. The guess could be completely wrong, unfortunately. Have you fixed these problems since v2.0.0? > After asking on Stack Overflow > (https://stackoverflow.com/q/79171799/3720258), it was suggested that > I set 'CXXFLAGS="-stdlib=libc++"' in 'configure'. The question is > very long and provides all the details that I skip here. I am not seeing alloc-dealloc-mismatch in the CRAN checks, neither in the links you provided, nor in the latest pretest results at <https://win-builder.r-project.org/incoming_pretest/redatam_2.0.3_20241107_154750/>. I think that these indicate a problem with the way your GitHub actions are set up. Have you received a CRAN check report with alloc-dealloc-mismatch in it? I've tried to compare the versions visible in the CRAN archive but couldn't get far because there was a lot of formatting changes. What exactly are the problems for which your latest submission of v2.0.3 has been archived? Do you need help reproducing the container-overflow and/or null object pointer errors? -- Best regards, Ivan ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
