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
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.
TL;DR: Debuigging into MFC (CString) header code does not work on both my machines and as far as I can tell this is due to the peculiar way these headers are compiled.
Stepping through MFC header code when entered via disassembly works, but setting brealpoints does not work.
I'm looking for a workaround or at least acknowledgement of my analysis.
System:
Visual Studio 2019 Professional 16.9.6
Windows 10 / 1809 Enterprise LTSC
Setup: (I do apologize for this being rather long.)
Create a Visual Studio 2019 Example MFC Application Project (SDI App)
Make sure Enable Just My Codeis off under Options -> Debugging -> General.
Set the build configuration to Debug/x64 (does not make a difference, but let's all stay on the same page)
Navigate to MFCApplication1.cpp -> CMFCApplication1App::InitInstance()
Insert a CString init like this:
...
InitCommonControlsEx(&InitCtrls);
CWinAppEx::InitInstance(); // please put breakpoint 1 here
// Add this line and set breakpoints
CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
Now, you can start the program under the debugger, and you should stop at the first breakpoint:
Now, make sure all symbols are loaded, easiest done via the Call Stack:
Just select all lines in the call stack window and hit Load Symbols in the context menu. Afterwards the call stack should look roughly like this:
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C++
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C++
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C++
MFCApplication1.exe!invoke_main() Line 123 C++
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C++
MFCApplication1.exe!__scrt_common_main() Line 331 C++
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Now, you can try stepping-into (possibly F11) the CWinAppEx::InitInstance() function, which should work without a problem, landing you in mfc140ud.dll!CWinApp::InitInstance() Line 394 - this is OK.
Step out again, and then then try to step-into the CString ctor:
This DOES NOT work on my machine(s)!
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line.
Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
Maybe fixed in a newer VS version?
Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
The most interesting answer here would actually be as to WHY this breaks - where does the debugger get confused? Is this a general problem with re-define-ing code when debugging library code?
The source shipped with MSVC does not match.
I think this happen, as DLLs got updated with Windows Update or a new vcredist, but Visual Studio includes are not updated. If you build with /MT or /MTd and link MFC statically, the problem does not persist.
Probably this can be reported to http://developercommunity.visualstudio.com if you care.
Workaround 1
Do steps described by #selbie:
Set a breakpoint on the line of code I want to step into.
When
the breakpoint is reached, right click in the editor window and select
"Go To Disassemly".
In disassembly mode, step over until you get to
a call statement. [...] You
can flip out of disassembly mode by right-clicking again and selecting
"go to source code".
(skipped the part not relevant to this issue)
Then pick up the location of the header manually, the debugger will tell that it does not match. The difference seem to be insignificant though, so the header is usable.
Workaround 2
Link MFC statically, compile with /MT or /MTd
Workaround 3
ATL has a similar CString that does not suffer from the issue:
#include <atlbase.h>
#include <atlstr.h>
int main() {
ATL::CString this_is_text("Debugging into CString header works");
}
Analysis went sideways at some point, but we finally found one part of the problem here:
The Require source files to exactly match the original version option:
was the problem, but in a very peculiar way:
When you do NOT require source files to match (that is, disable this default option), then the erroneous behavior of the OP occurs: The debugger can no longer match the symbols to the cstringt.h file.
Unfortunately, I had this disabled on both machines. Pulling in a third machine showed that we could set breakpoints (though F11 still does not work) and by comparing the xml export of the VS settings we found that this was different.
So, long story short: For us, to be able to set breakpoints in the (unmodified!) MFC header, requires us to enable the Require source files to exactly match .. option.
If the option is disabled, which would imply a more lenient behavior by the debugger, it no longer works.
And, yes, we double checked it's always the same source file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
The mystery with step-into/F11 persists, but I guess this would better be taken to a separate question.
Uncheck the Enable Just My Code option in Tools->Options->Debugging
I know that works for c++ std:: library code debugging. The other technique I do, when I forget to uncheck this option, is similar to what you describe above.
Set a breakpoint on the line of code I want to step into.
When the breakpoint is reached, right click in the editor window and select "Go To Disassemly".
In disassembly mode, step over until you get to a call statement. That's typically the std library. Eventually, you'll navigate into a mix of assembly and system code sources. You can flip out of disassembly mode by right-clicking again and selecting "go to source code".
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...
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"
I'm debugging a running program with gdb 6.6 on solaris, and noticed that sometimes gdb steps into (inline) functions, even though I issued a next command.
My development host was recently reinstalled with a slightly newer build of solaris 10, and I know for sure the auto-stepping was not present before the host was reinstalled. The code is compiled with the same options since the makefiles and all the source code is unchanged since host reinstallation.
Is there any setting/new default option which influences gdb's debugging behaviour that I can check? Does anyone know why my gdb now auto-steps? Its a pain really ...
[edit] to clarify: I did not mean the inline keyword, but rather methods/functions which are implemented in the header file. Example:
header.hpp:
class MyClass
{
public:
void someFunc() { ... does something }
}
source.cc:
{
MyClass instance;
instance.someFunc(); // doing NEXT in gdb will actually STEP into header.hpp
}
Your new version of Solaris may have included a new version of the C or C++ compiler. The new compiler may be optimizing more aggressively than it did before. Check your optimization flags. If you are using GCC, you can disable inlining with -fno-inline (note that methods that are implemented in the class in header files are inlined by default which can be disabled with -fno-default-inline). If you are using the native Solaris compiler, you will need to check its documentation.
A similar problem was reported here. In the comment, the poster mentioned changing the debug symbol to use STABS resolved the issue.
You mentioned in a comment to my answer that STABS works, but is not acceptable. Also, you mentioned that you are unable to reproduce the issue with a simple example. It will be difficult to trouble shoot this issue if you have to recompile your entire project each time to perform a test. Try to isolate the problem to a few source files in your project. See what they have in common (do they include a common header file, do they use a pragma, are the compilation options a little different from the other source fies, etc.), and try to create a small example with the same problem. This will make it easier to identify the root cause of your issue and determine how to resolve it. Without this data, we are just the blind leading the blind.