I've been debugging this for 2 hours now, and it boils down to this. If I call QString::toStdString
QString s = "testtesttesttesttesttest";
const std::string &temp = s.toStdString();
the program later crashes on std::string destructor
__CLR_OR_THIS_CALL ~basic_string()
{ // destroy the string
_Tidy(true); // <---- It crashes on this line.
}
I thought it was memory corruption at first, but this happens even if main() contains only those 2 lines. Does anyone know why this happens, and also how can I fix it?
My Qt version is 4.8.1.
Your Qt DLLs need to be compiled with STL support and exactly the same C-Runtime Library as your code. It looks as though you are using two different CRTs at the same time, which would destroy the objects created on one heap by Qt into the heap used by your program.
Check the DLL Usage with the Dependency Walker!
Most probable reason could be that your Runtime Library is "Multi-threaded (/MT)" and you need to change it to "Multi-threaded DLL (/MD)" (if you are on the release version)
If you are on the debug version change from "Multi-threaded Debug (/MTd)" to "Multi-threaded Debug DLL (/MDd)"
If you have an odd compilation of Qt, the solution should be the opposite.
You will find that on "Configuration properties->C/C++->Code Generation->Runtime Library"
I tried tackling the problem a different way. I created a new project from Visual Studio, and the test code didn't crash there. Upon examining the differences between the *.vcproj files with WinMerge, I found that the crash is caused by some custom changes in the project concerning - you guessed it - the runtime libraries. This is the patch created by WinMerge with the minimum differences that cause the crash to be reproduced:
112c112
< RuntimeLibrary="3"
---
> RuntimeLibrary="1"
126a127,128
> LinkLibraryDependencies="true"
> UseLibraryDependencyInputs="false"
127a130,131
> IgnoreAllDefaultLibraries="false"
> IgnoreDefaultLibraryNames="msvcrtd.lib"
Related
I am using VS 2022 Community Edition (v17.3.3) to build wxWidgets application (v3.2.0) using C++ (v14.3 - Features from Latest C++). The windows SDK is using the latest installed (10.0.22621). The project is also using C++ modules.
The Debug build succeeds but when I run the project's exe file at random it throws the exception (Access violation reading 0xFFFFFF (ucrtbased.dll)) in exe_common.inl at the following line:
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
After a few more compilations (by just making minor changes to trigger a compilation) it succeeds and the exe runs correctly.
I wonder if there is any settings that might be causing this random error. Btw, I am using Win11 but same thing happens on Win10 as well.
Thanks in advance.
EDIT 1:
The project is using boost libraries and at startup boost/json (boost/json is used in other parts of the project as well). Debugger shows that after the following line the above error happens:
static allocator_arg_t allocator_arg = BOOST_CONTAINER_DOC1ST(unspecified, *std_allocator_arg_holder<>::dummy);
There were a few things needed attention:
Discontinued use of wxSQLite (the library was not maintained for over a decade),
The main frame was a singleton data structure, not anymore, and not deriving from wxMDIFrame anymore.
All unnecessary (a chain of them) #include removed.
Inclusion of <boost/json.hpp> in a few files were removed and now using #include <boost/json/src.hpp> only in one .cpp file. However, the project still uses inclusion of <boost/json/value.hpp> in multiple .h files.
All uninitialized pointer variables and others were initialized.
#1 and #4 were especially pointed by the debugger. It has now been more than a few days and haven't had the problem since then.
I am storing some variables inside custom section in my program. During debugging session I can check it is created and that it contains the necessary data. But in release mode, it disappears!
Note: I am also creating an executable section which strangely is created in both version. The CPU platform seems to make no difference.
Why doesn't the "data" segment appear in the release version?
This is a short snapshot:
// Defnitions used for better code segmentation
#define store_variable(x) __declspec(allocate(x)) //for data segment
#define store_code(seg) __declspec(code_seg(seg)) //for execution segment
#pragma section(".eqwrt", read) //weird name because I thought there would be collision
store_variable(".eqwrt") UCHAR USER_DATA[SIZE];
store_variable(".eqwrt") USHORT Version = 1;
store_code(".wsect") bool sendError();
The program (it's a dll) is compiled with a fixed base address and with /MT flag.
Release version x64. Only one segment appears-the executable one:
Debug version x64. Both segments show up:
Try to disable Link-time optimizatizon scheme from the project's settings.
To do that go to: Configuration Properties 🠂 General 🠂 Whole Program Optimisation and set to No Whole Program Optimisation.
Most likely it has something to do with the optimisations performed during linking.
More details you can get from here : What's C++ optimization & Whole program optimization in visual studio
I am programming a DirectShow Filter that detects objects with an OpenCV HaarcascadeClassifier. It is working fine in Debug mode but not in Release mode and I'm not sure whether there is an memory leak in the OpenCV function (VC 2010 binary of opencv_249 libs) or whether there is something wrong with my project (settings).
I am loading the filter in GraphStudio, a tool to build a DirectShow FilterGraph easily. I'm not sure whether there are assumptions about the filter DLL to be compiled in Debug mode or not.
I'm basically doing the following, after some preprocessing:
std::vector<cv::Rect> objects;
mClassifier.detectMultiScale(inputGray,objects, 1.3);
for(unsigned int i=0; i<objects.size(); ++i)
{
cv::rectangle(outputImage, objects[i], cv::Scalar(255,255,255));
}
So within the function block I am preprocessing, followed by the shown part of code and followed by writing the data to the DirectShow Buffer.
If I use the DLL in Release mode, I get the following error message AFTER the whole function terminated (so probably somewhere else inside the DirectShow Filtergraph):
Debug Assertion Failed!
Program: C:\Program Files (x86)\Graphstudio\graphstudio.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
Line: 52
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
For information [...]
followed by a
Debug Assertion Failed!
Program: C:\Program Files (x86)\Graphstudio\graphstudio.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
Line: 1322
Expression: _CrtlsValidHeapPointer(pUserData)
When I comment mClassifier.detectMultiScale(inputGray,objects, 1.3); out, the filter doesn't crash. Though some things might be optimized away, I replaced the detectMultiScale call with a loop that randomly (previously seeded with time(NULL)) inserts cv::Rect objects into the vector. The filter does not crash and displays the random rectangles in the way I would assume.
I've read that others have observed (valgrind) cv::CascadeClassifiert::detectMultiScale to produce memory leaks. And I've found a link where someone had a problem with detectSingleScale and some OpenCV committer marked it to be fixed ( http://code.opencv.org/issues/2628 ).
Questions:
Is there a chance that this exact problem (see previous link) is (still) within detectMultiScale?
Is there a chance that the problem is not within my project, but in the OpenCV library?
Why does this problem only occur in Release mode?
Why does this problem only occur in the DirectShow filter? (if I run the "same" code/functionality in Release mode in a stand-alone project, I don't get Debug Assert Failed errors - though there might be a unrecognized memory corruption?!?).
I hope someone has an idea and thx in advance!
EDIT:
ok... I had linked against msvcrtd.lib ... removed the whole lib from my project (seems I didnt even need it) and it "works" now... There is the question left, whether there is some kind of memory leak. Or was linking against that lib the only whole problem?
ok... I had linked against msvcrtd.lib ...
removed the whole lib from my project (so default libs are added?!?) and it "works" now...
There is the question left, whether there is some kind of memory leak.
Or was linking against that lib the only whole problem?
stupid me...
My code is like this:
void some_func(void *source)
{
...
double *casted = reinterpret_cast<double *>(source);
...
}
This causes std::__non_rtti_object exception. Acording to stack trace, it is raised from __RTDynamicCast, which is (as far as i know) MSVC implementation of dynamic_cast.
This exception should occur with dynamic_cast, as the pointer comes from external library (probably compiled without /GR) and points to struct with several doubles. But I would not expect this with reinterpret_cast. Shouldn't it just change the type of the pointer, without any checks at all?
Notes:
my compiler is msvc120 (MS Visual Studio 2013)
project is compiled with /GR (enable run-time type information)
pointer "source" comes from external library (probably compiled without /GR)
I also tried static_cast with the same result
Non-reproducible.
Ah, i tried to rebuild whole project with all additional libraries and
the problem disappeared. Seems strange, because I never had a code
using dynamic_cast, so don't know what caused this. Also I already
tried to rebuild that project only (without other dlls) before.
Anyway, thanks for all help.
-- OP
It seems as that you need to recheck dll's order of build in your makefile (if you use such). I guess that the source from the external library you mentioned, comes from external library that is "higher" in the build tree than the library which your code resides. Try to see if your makefile properly works (maybe misses some triggers).
I'm facing heap corruption error: I have a dll and TestAPP.
vector<Point> vInPts; // Test Application - dumping inputs like below
vInPts.push_back(Point(730,405));
vInPts.push_back(Point(319,680));
vInPts.push_back(Point(292,757));
vInPts.push_back(Point(318,756));
vInPts.push_back(Point(726,736));
vInPts.push_back(Point(344,731));
vector<Point> vOutPts;
Calling DLL -> copying same vInPts vector to vOutPts vector in DLL" -> When returning from this function to TestApp -> Heap Error arises. Now Facing Heap Error
How can I fix this Heap Error?
Thanks in advance !!!
It would be interesting to read the actual definition of your Point class. Is it properly copyable?
Moreover, since you are using a DLL and an EXE with STL classes, make sure that both the DLL and the EXE are built with dynamic linking to the same flavor of the CRT (e.g. both are built with the same version of the C++ compiler, and with the same settings, e.g. release build DLL with release build EXE, etc.)
In fact, STL classes's implementations differ in release builds and debug builds (e.g. in debug builds there is more overhead for checkings like iterator validation, etc.).
If a STL class is shared between the EXE and the DLL, it must be the same class, not classes with the same name but a different implementations.