|
why don't you figure out instead why a destructor is called in an Init() method ?
|
|
|
|
|
The simple application consists of ... - this is stripped down test app with nothing more than "InitApplication":
void InitApplication()<br />
{<br />
CStartupManager oStartupManager;<br />
<br />
oStartupManager.StartUp(STARTUPCONFIGFILE);<br />
<br />
return;<br />
}<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
<br />
InitApplication();<br />
<br />
return 0;<br />
}<br />
At the end of the Init method StartupManager being a local variable goes out of scope.
-- modified at 4:47 Friday 24th August, 2007
|
|
|
|
|
So, show us what is happening in
oStartupManager.StartUp(STARTUPCONFIGFILE);
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
Are any string objects (or raw memory pointers) passed between functions in the DLL and in the executable?
You may be looking at something like a debug/release problem. For example, if the DLL is built is a debug build and the app is a release build, and you allocate memory in the app and free it in the DLL, you will be allocating from the non-debug heap and trying to free it back to the debug heap (or the reverse may be true).
This is commonly seen in COM implementations done by inexperienced MFC developers that like to pass CString objects as parameters to COM methods.
Moral - avoid handoff memory whenever possible, even if it is wrapped by an object (like a string object), and especially when dealing with lots of DLLs and/or COM objects.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
I think I made an effort trying to ensure if I alloc in DLL-A, I deallocate also from DLL-A, despite I do pass buffer on possibly different heaps around and across DLL boundary...
BUT I have not thought of the possibility of Release-Debug mode being different! Thanks!!!!
sigh...
with COM, SysAllocString and SysFreeString takes care of this problem. That's my pet project.
At work i have another problem, suspecting deadlocks... bad day... lucky it's Friday. I will just sleep till monday before I get back to these again...
Okay now I must sleep sleep sleep gosh
|
|
|
|
|
The most common cause is spelled out in the link you provided:
"The local heap refers to the heap created and managed by a particular instance of the C run-time library. If a dynamic-link library (DLL) contains a static link to the run-time library, it has its own instance of the run-time heap, and therefore its own heap, independent of the application's local heap."
malloc, free, new, delete are applied to the CRT heap of the module (exe, dll) the call resides in.
If all the modules of an app are dynamically linked to the CRT then they all share one set of CRT state (heap, FILE list, ...). Any module that was statically linked to the CRT will have it's own copy of CRT state that it modifies.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Yes probably it... problem went away after I changed a couple of methods to use "const string &" instead of just "string".
Anyway thanks.
devy
|
|
|
|
|
Hi,
I am working with multiple document-view architecture . The problem is when myview class's OnUpdate() is about to get called , I am getting a crash.what functions gets called once this function is called . Can anyone tell me the sequence of the functions that gets called or any other approach so that I can trace out the cause of the crash.
Taruni
|
|
|
|
|
Set a breakpoint right at the top of myview::OnUpdate()
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
When it crashes, go into the debugger, and look at the call stack. This will show the sequence of functions (and how far into them you were).
In VC++6, you can get this from the View | Debug Windows | Call Stack menu, or alt-7.
Good luck,
Iain.
|
|
|
|
|
devvvy wrote: I do know call stack and such.
Its one of the debug-windows. While debugging (e.g. when your program execution stopped on a breakpoint) activate it in the VC++ - "Debug"-menu.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
Im sorry - I read your mail above to state "I don't know call stack...".
My fault. Please excuse me.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
|
I did reply to you by mail (using the mail-button below the text). You did not receive my Mail?
As an alternative, could you put the code on some of the free webspace providers and post the adress here?
I am reluctant to post my mail adress here in the open.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
devvvy wrote: do you think I can send you the stripped down package?
As a professional, you should not have a need to do this. Simply do as previously suggested and you'll find the exact cause of the problem. The debugger is your friend. It exists for a reason.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
My MFC experience told me sometimes some MFC supplied member/attributes no valid until some sequence completed... using it before hand would crash it...
can't remember the detail now that's just an impression from a difficult bug i had long ago. But yes step thru the code with a debugger will allow you to zoom in on the problem
|
|
|
|
|
You mean like, oh, I don't know, maybe creating the resource (HWND, HFONT, HBITMAP, etc) first by calling one of the CreateXXX methods on MFC? Is that what you're referring to?
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
Hello everyone,
I am wondering how C or C++ manages static variable internally. Since each time when we again a function again, if in this function, a static variable is defined, the value will be the value last time when we entered this function (i.e. will not be initialized again, and only initialized at the 1st time).
I suspect it is stored in some global structure to reserve the value?
thanks in advance,
George
|
|
|
|
|
My understanding is that static vars are initialised before main() is called. You could check this by creating a class with a constructor, init a static variable of this type, put a breakpoint in the constructor and see what happens
|
|
|
|
|
Thanks Josh,
Do you mean static variable inside a function? If yes, how do you think such *local* static variable will be stored, since normal local variable (value) will vanish after function returns. But for static *local* variable, the value will not vanish -- and will be recorded next time when we entered the same function.
Any ideas or comments?
regards,
George
|
|
|
|
|
I dont know to be honest but I would imagine that all static variables are pushed onto the stack before main() is called and therefore "local" statics dont really go out of scope when a function ends. I suspect the actual details may vary between compilers.
|
|
|
|
|
Thanks Josh,
Good answer! I have a further question about programming best practice. Do you think it is safe to let the address of the *local* static variable as the return value of a function? Then other part of code (out of this function) will access or even modify the variable by the returned address of the *local* static variable?
Any disadvantages of this approach?
Example,
<br />
<br />
int* func()<br />
{<br />
static int i;<br />
<br />
return &i;<br />
}<br />
<br />
regards,
George
|
|
|
|
|
when you mark some variable static, compiler wil decide how to treat that variable.. so there no scope of local and global variable concept here!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I
IV
Support CRY- Child Relief and You
|
|
|
|
|
Thanks Alok!
If you think static variable is different from local or global variables, how do you think static variable is stored and managed so that the value is reserved each time we enters the function in which the static variable is defined?
regards,
George
|
|
|
|
|
George_George wrote: Good answer! I have a further question about programming best practice. Do you think it is safe to let the address of the *local* static variable as the return value of a function? Then other part of code (out of this function) will access or even modify the variable by the returned address of the *local* static variable?
Any disadvantages of this approach?
I'd say it smells like bad design, the only reason to return a pointer rather than a copy of the int is to allow some other code to modify it. I'd rather provide a method to allow other code to modify the static.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
