|
Hi,
I am currently porting 64 bit application with C and Assembly code (x86-64) from Linux to windows.
I am using Microsoft C-Compiler 2005 and Yasm for compiling C and assembly code respectively.
I have modified the assembly files as per the 64-bit ABI specification for windows and i do get expected results when i use “RTCs” flag which is meant for stack pointer verification. This flag also requires optimization flags to be turned off.
The problem starts when i dont use the “RTCs” (which is the case in release version) it tries to access initial locations (0×04a0) of memory in C-code.
I suspect that it has something to do with calling convention mismatch when control gets transferred from assembly to C-function.
Any help in this regard would be highly appreciated.
With warm regards,
KEDAR
|
|
|
|
|
memory allocation/dealloc - across multiple dll's
Anything I need to be aware of?
<br />
DllA::SomeFunc(){<br />
char * pszBuffer = new char[100];<br />
...<br />
strcpy(pszBuffer, pszData);<br />
DllB::SomeOtherFunc(pszBuffer);<br />
...<br />
delete [] pszBuffer; << delete from dll where you allocated it originally.<br />
pszBuffer = NULL;<br />
...<br />
}
I'm tormented by:
_ASSERTE(_CrtIsValidHeapPointer(pUserData));
The assert statement blew on application exit, after invoking StartupManager's destructor:
_CrtIsValidHeapPointer(const void * 0x00443270) line 1697<br />
_free_dbg_lk(void * 0x00443270, int 1) line 1044 + 9 bytes<br />
_free_dbg(void * 0x00443270, int 1) line 1001 + 13 bytes<br />
free(void * 0x00443270) line 956 + 11 bytes<br />
operator delete(void * 0x00443270) line 7 + 9 bytes<br />
std::allocator<char>::deallocate(void * 0x00443270, unsigned int 33) line 64 + 38 bytes<br />
std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Tidy(unsigned char 1) line 592<br />
std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >() line 59 + 39 bytes<br />
CStartupManager::~CStartupManager() line 17 + 33 bytes<br />
InitApplication() line 18 + 18 bytes<br />
main(int 1, char * * 0x00441420) line 26
I tried WinDbg, but guess I'm not very good at it... and it told me no more information than Visual Studio.
I'd send you the stripped down version of the code (but error still reproducible) if you ask for it. THANKYOU!
Link:
1. http://msdn2.microsoft.com/en-us/library/ys6cfhhh(VS.80).aspx
|
|
|
|
|
In InitApplication(), the destructor of CStartupManager is called.
This in turn calls the destructor of a std::string.
And this std::string is unable to deallocate its memory, or its memory is already deallocated.
At the moment, I don't see the connection with the code you presented.
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
|
|
|
|
|
Can I email you the package plaese? I haven't been able to narrow this down and I don't think it happens in destructor - despite what stack trace presented...
Thanks!
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
