I've created a program (vs2010,c++,win7), it's a multithreaded and has modules.
The program that communicates with some hardware.
I run this program in a clean computer that has only win7 and the drivers of the hardware.
After using my program for a while, one of the modules crashes.
I tried to debug the program in the development computer and the call stack show me only calls to "ntdll.dll", i also tried to create a dump file from the program in the testing computer
and I've got the same results.
Usually the module crash when there is a lot of load on all the modules.
I've no idea from where to start to debug this program, so I'm open to ideas.
EDIT:
also i got the exception "0xc0000374 a heap has been been corrupted"
tnx.
Related
Using Boost and OpenSSL Integration I am creating an application similar to a browser.
Somehow the program crashes before even it enters main() method.
Certainly, If the program utilizes DLLs they can be loaded before main() starts. The DllMain functions of those DLLs will be executed before main(). If they encounter an error they could cause the entire process to halt or crash.
How can one debug this scenario ?
I'm writing a piece of code in Windows which uses both winapi messagebox and some dynamic memory for RS232 application
I saw a strange situation when the same application creates different error when I run it in debugging mode (using VS2010 and step-in debugging) and running it as an executable in command-line
in first case, the error is popped up properly with a winapi messagebox and the program returns/ends properly. Second case, it creates run-time error and also the memory leak
Is there such difference between these two run modes? and how to catch winapi run-time error?
Thanks in advance!
Yes! Running a program directly form the debugger the debug heap is in use. Assuming it isn't compiled in debug mode.
And the memory layout changes when the debugger is loaded into the process address space. So some weird things may happen.
If you have such strange effects it is sometimes better to attach the debugger to the running process.
I'm having a problem on my embedded linux board. My program runs, then somewhere in a particular function throws a segmentation fault. So i'm trying to track down why this is happening so I can fix it.
The problem is that my target board runs a filesystem image which does not include gdb or gdbserver. Is there any way I can debug this application as it runs on the embedded target without rebuilding the kernel or my application?
c++ program terminated with no exceptions or stacktrace
I have a multi threaded application
If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.
If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.
I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.
I am running Fedora Core 14
I am compiling with gcc 4.5.1
gdb is fedora 7.2-16.fc14
My IDE is eclipse Juno I am using the CDT builder
my toolchain is the cross GCC and my builder is the CDT Internal Builder
Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?
That's what's supposed to happen. Under Unix, you get a full
core dump (which you can examine in the debugger), provided
you've authorized them. (ulimits -c—traditionally, they
were authorized by default, but Linux seems to have changed
this.)
Of course, to get any useful information from the core dump,
you'll need to have compiled the code with symbol information,
and not stripped it later. (On the other hand, you can copy the
core dump from your users machine onto your development machine,
and see what happened there.)
You're definitely looking for core dumps, as James Kanze wrote.
I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.
You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
I'm building an application for Windows XP using the MinGW tool chain and it sometimes crashes unexpectedly. So, I'm trying to use a debugger (Gdb) but the program exits with code 03 before anything happens. In fact, all I see from GDB is:
[New thread 3184.0x7b8][New thread
3184.0xef8]
Program exited with code 03.
My suspicion is that there is some failed dynamic linking of a dependency (which are Qt, VTK, and ITK, all built with MinGW). However, this does not happen when I just run the program normally. Or if it happens, it appears to be intermittent and well after the program is launched and running. NOTE: I'm also using Cmake for cross compiling.
What should I do? What can I try?
Add a callback via signal(SIGABRT, <callback>) to catch the call to abort before it shuts down the process. If this happens before you hit main() you might have to resort to a static global and compiler trickery to catch it.
Code 3 is usually returned on a segfault.
Try switching to Linux and debugging the program with electric fence. It might give you some extra insight.