Re: DLL pass vector by value crash
- From: BoHuang <BoHuang@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 26 Aug 2009 07:01:01 -0700
Yes, that's why your widsom is always appreciated, and let's try to get more
info from the program first.
My VS2008 versions 9.0.21022.8 RTM, when I click on,
Tools->Options->Debuggin->Symbols, I do not have "Load symbols from Microsoft
symbol servers" as described by
http://msdn.microsoft.com/en-us/library/b8ttk8zy.aspx
The only thing similar are check boxes for
"Search the above locations only when symbols are loaded manually"
"Load symbols using the updated settings when this dialog is closed" (Checked)
I also tried to manually load in the callstack, i.e., for mfc90.dll. But I
can't find mfc90.pdb on my machine. Using mfc90.i386.pdb, mfc90u.pdb or
mfc90ud.pdb I get "PDB does not match image".
"Joseph M. Newcomer" wrote:
You have missed saying several absolutely critical things, essential for the understanding.
of this problem.
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. Perhaps you meant to make the prototype
void testFunc(vector<string> & testVec);
or
void testFunc(const vector<string> & testVec);
?
If not, explain why not.
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.
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.
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.
Note that you should have seen the crt runtime source displayed, unless you somehow
managed to not load it.
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?
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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
BOOL CApp::InitInstance()Joseph M. Newcomer [MVP]
{
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 )
{
}
};
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- References:
- DLL pass vector by value crash
- From: BoHuang
- Re: DLL pass vector by value crash
- From: Joseph M . Newcomer
- DLL pass vector by value crash
- Prev by Date: Re: including a MFC program into a non mfc application
- Next by Date: Re: DLL pass vector by value crash
- Previous by thread: Re: DLL pass vector by value crash
- Next by thread: Re: DLL pass vector by value crash
- Index(es):
Relevant Pages
|
Loading
