Re: DLL pass vector by value crash
How does it work in detail? The temporary vector object is created on the
stack of the exe and may allocate default member element on the exe heap. How
does the dll juggle with stack popping and heap deletion?
If this is a dangerous situation, the simple app I set up calling testFunc()
in a dll did not crash. Got lucky or is a special case?
The prototype for testfunc is a by-value copy, so it has to make a copy of the value. This
temporary object is allocated by the .exe and deleted by testFunc. This is already a bit
suspect.
Passing by reference does work. However I want to use pass by value as some
of these functions are callbacks.
Perhaps you meant to make the prototype
void testFunc(vector<string> & testVec);
or
void testFunc(const vector<string> & testVec);
?
If not, explain why not.
Under properties->configuration Properties->C/C++->Code Generation->runtime
library, I always use /MD for release, /MDd for debug if that's what you mean
when referring static linking.
Are you using static linking for either the .exe (if so, it probably won't work correctly,
and what you are seeing is expected under the typical failure conditions). You are
clearly using the shared CRT DLL for the DLL you are constructing.
Right, in release, works fine if testFunc() not called.
Given the simplicity of your example, that's the first thing I would suspect. Since
there's no opportunity for storage damage with the empty body shown, and presumably the
program works without the call to testFunc, that's the best I can tell with the poor
information here, such as no symbols on the traceback and no display of the source
information from the CRT.
Here is the debug traceback as the crash occurs at the closing braces of
testFunc(), where the vector is being destroyed:
ntdll.dll!_DbgBreakPoint@0()
ntdll.dll!_RtlpBreakPointHeap@4() + 0x28 bytes
ntdll.dll!_RtlpValidateHeapEntry@12() + 0x113 bytes
ntdll.dll!_RtlDebugFreeHeap@12() + 0x97 bytes
ntdll.dll!_RtlFreeHeapSlowly@12() + 0x246cf bytes
ntdll.dll!_RtlFreeHeap@12() + 0x17646 bytes
msvcr90.dll!free(void * pBlock=0x032a0248) Line 110 C
MantaRenderer.dll!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char>
,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Tidy() Line 1132 + 0x2b bytes C++
Go to the setup for your version of VS and indicate that you want the Microsoft Symbol
Server symbols loaded. Then the debug traceback will make more sense.
Note that you stopped the traceback too soon; there is no place that calls testFunc in the
backtrace. Until we have symbols present and you show the traceback to AT LEAST the call
on testFunc, there isn't a lot that can be done.
You mean the source code to the crt? Yes I can click on the callstack on
msvcr90.dll!free and access the source code of free.c. But it doesn't work on
ntdll.dll calls being not part of the crt. I assume no source code is
available for ntdll.dll
Note that you should have seen the crt runtime source displayed, unless you somehow
managed to not load it.
/MD should be multi-threaded dll in properties->configuration
Properties->C/C++->Code Generation->runtime library
/MDd is the debug version
I have trouble with concepts like /MD. Presumably lthis is a compiler switch you
activated by making a particular selection in the properties. Why not tell us what
properties you set? Otherwise, I have to go back and look up with /MD and /MDd mean. Why
should I have to decode it when you already know what options you selected?
As the stack trace shows, the app is crashing due to the _tidy() function in
vector trying to free mem at the end of testFunc(). The question is, calling
the same testFunc() in the same dll with the same parameters, why does the
simple test app work but my full app crashes.
There should be no mismatch between release and debug exe/dll calling
resulting in mismatch of crt.
I would start single-stepping through the code; put a breakpoint on the closing brace of
testFunc and then drop into assembly code and start single-stepping instructions. It
really looks to me like the allocation is happening out of one heap and the delete into
another.
Since I have no dea what ntdll.dll!77cf59c3 contains, there is little hope of figuring out
what is going on here..
On Tue, 25 Aug 2009 15:31:01 -0700, BoHuang <BoHuang@discussions.microsoft.com> wrote:
BOOL CApp::InitInstance()
{
testDllClass t;
vector<string> v;
t.testFunc( v );
...
...
}
When the above code is executed in my large MFC exe and when testFunc() is
about to return, I would either crash with access violation at the end of the
vector dtor of v's copy, or at the line
if (!ProcessShellCommand(cmdInfo))
This happens for 'release' but not 'debug'. Despite me turning off
optimization, enable program database, and turn on debugging in linker, the
callstack reveals little:
ntdll.dll!77cf59c3()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77cf5883()
kernel32.dll!768ac56f()
msvcr90.dll!6f3a38bb()
mfc90.dll!5ff49147()
mfc90.dll!5ff4867b()
...
...
When I set up a simple test MFC exe that executes the same code, still with
testDllClass in a dll, no crash occurs in either config.
If testDllClass were defined in the large MFC exe rather than a dll, no
crash in either config.
Or, if testFunc() passes the vector<string> by & or *, no crash occurs in
either config.
All dlls and exes use /MD or /MDd depending on config.
If /MT or /MTd were used, does the exe create the copy of v? And does the
dll destruct that copy? I am unclear on where is the precise dll boundary
when it comes to pass by value.
Am I just getting lucky in the small test app in regard to DLL calls?
#pragma once
#ifdef OPENGL_EXPORTS
#define DLL_EXPORT __declspec( dllexport )
#else
#define DLL_EXPORT __declspec( dllimport )
#endif
#include <vector>
#include <string>
using namespace std;
class DLL_EXPORT testDllClass
{
public:
testDllClass(void){}
virtual ~testDllClass(void){}
void testFunc( vector<string> testVec )
{
}
};
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm