Printable View
Hello there I need some clue, got a compiled x64 image but it does crash if run.
Interesting that it finishes successfully if run under debugger (WinDbg).
It indicates similar problem I had in past with 32bit app but can't remember yet what was the solution. The compilee uses no compression.
Any hints?
Hmmm maybe you have some sort of problems with the way you are allocating memory. Possibly you are allocating memory and not deleting it. Perhaps you are attempting to access memory outside of the memory area you allocated. The debugger is alot more accepting of errors, bad coding practice and memory exceptions, than usual.
HTH,
I don't have too much experience with WinDbg thus I don't know how stronly it protects application environment but letting run the same application compiled as x86 target it runs fine even standalone. So I think the problem is due 64bit image.
The problem is that I can't debug anything since as I wrote it runs fine under debugger. Thus I even can't see where it crashes.
It's also possible that you are expecting something to be initialized somewhere that doesn't. The debugger might either initialize it for you, or catch and recover from the problem. It's also possible that you are overrunning the bounds of an array. A lot of debuggers pad either side of a chunk of memory for debugging purposes, you might be running into that buffer and not knowing it. This is why unit tests (run outside the debugger) are so important.
Could you please clarify that?Quote:
Originally Posted by Anakunda
Do you run debug or release build under debugger?
Are you saying that the SAME build runs OK under debugger and fails when run by itself?
I have tried to make both release and debug build. In both cases the image crashes outside debugger, in bothh cases it runs fine under it. The only difference is rls build invokes message about crash while debug build makes windows warning sound then stops without crash notify, thus optimizations as well as debug code are not on cause.Quote:
Originally Posted by VladimirF
Two more questions:
1. Is your environment set up OK? I mean - could you build and run 64-bit "Hello World!" app outside of your debugger?
2. Is there any chance that your app specifically checks for debugger and calls its services?
Yes, runs fine.Quote:
Originally Posted by VladimirF
I don't think so, it's an open source platform independent audio encoder.Quote:
Originally Posted by VladimirF
Moreover I was doing an debug build earlier turning off all optimizations and it ran well outside debugger, trying to reproduce this build with same settings today generated an crashing image, so it must be something that happens in random.
Does your program create a log file? That's always invaluable when debugging programs like that.
Hmm I don't think so, but it atleast prints the startup banner (console), the crash happens exactly when starting conversion.
Try putting more logging, you have given us very little to go on.q
Questions I have:
Is your program threaded? POSIX, boost, or MS?
Have you even pinpointed the method that is crashing?
Could you post the code that is problematic?
When you switched to 64-bit, did you remember to switch linking dependancies?
Are you loading any libraries using dlopen (or whatever the win equivalent is)?
Do you ever place a pointer in anything other than a pointer primitive?
Are you mixing 32-bit and 64-bit libraries? Do any of their interfaces use pointers?
If you're using Visual Studio, try creating a dummy project, but have the Debugging option point to the executable you're trying to debug. See if the app now crashes while debugging.Quote:
Originally Posted by Anakunda
If you are using Windows, better still if you actually created a crash dump for your program. There are ways to programatically create a crash dump by using the functions in DbgHelp.dll. There are articles here and elsewhere that discuss how to do this. Then all you need is to take the created dump file, load it as a project in Visual Studio, and run the dump file to identify where the crash occurs.
Regards,
Paul McKenzie
No, it's plain CQuote:
Originally Posted by ninja9578
No I only guess which library might concern.Quote:
Originally Posted by ninja9578
What dependencies do you mean? I have switched to 64bit versions of all libraries.Quote:
Originally Posted by ninja9578
That's not my project I leave the source as is.Quote:
Originally Posted by ninja9578
It doesnot use any 3rd party dlls except MSVC10 runtime and Intel Support DLL.
The source including binaries is uploaded here: http://www.mediafire.com/?b06qxs0uo1zlkn6
sure no, every lib I recompiled for x64Quote:
Originally Posted by ninja9578
Unfortunatelly I don't use Visual Studio IDE, only MSVC libraries. This project is compiled by IntelC++.
Are MSVC libraries compatible with IntelC++? VC++ mangles function names in weird ways, it's not regular GCC naming. I've always adhered to the policy of not mixing compilers. If compiling with MSVC, use MSVC compiled libraries, if using MinGW, only use MinGW compiled libraries. What if you use IntelC++ to compile your libraries?
Yes Intel and MS libraries are mutually compatible.