Thread: Difficult to catch bug

Try compiling with the options "-Wall -Wextra -pedantic". That may increase the chances of the compiler picking up something suspicious.

I wouldn't dismiss a pointer molestation. Many ways of achieving that.

It is also possible your code has a memory leak. That can cause an intermittent failure, depending on the order in which memory is allocated and deallocated.

Microsoft does (or at least, used to - I'm not sure if they still do) provide a free utility called Userdump.exe which creates a dump file for a program that terminates abnormally. The (now Microsoft) SysInternals suite includes a utility named ProcDump that may be useful in some circumstances.

Given that you are referring to "runs", I assume your program has a loop that performs multiple "runs". It would be a good idea to check that ALL variables are being initialised correctly on the first "run", and reinitialised correctly on subsequent runs. A common cause of intermittent failures is a one or two variables that are not being initialised correctly - and could explain your observation that re-running the program after a crash with the same input file does not cause a crash. Look for code that assumes a auto variable is initialised to zero (which is a programming error, but is likely to go undetected as program memory is more likely to be initialised to zero on program startup than in subsequent "runs", for various reasons).

MIGW has valgrind, I believe. If you run it under valgrind, that reports most of the problems to do with illegal memory accesses, uninitialised variables, unfreed allocations, and the like. The only thing it can't warn you about is when you tell the program to do the wrong thing, in a perfectly well-define, legal manner.

Originally Posted by Malcolm McLean

MIGW has valgrind, I believe. If you run it under valgrind, that reports most of the problems to do with illegal memory accesses, uninitialised variables, unfreed allocations, and the like. The only thing it can't warn you about is when you tell the program to do the wrong thing, in a perfectly well-define, legal manner.

Where can you get valgrind that works under windows?

Edit: You might try using DrMingw DrMingw - jrfonseca - Dr. Mingw - José Fonseca's utilitities - Google Project Hosting
The Code::Blocks project uses a variation of EXCHNDL.DLL to help trace bugs like this.

Tim S.

But my program crash without calling GestionSenales function. Is that normal?

You will need to show some code to answer that

following nice answer from ZuK here is a good link as regards GNU

Hello,

I think I have detected where the problem is and ........ is it not in my code, but the way my application work. I explain looking for help: I have four .bat files (in windows 7) that copy four different file to the path where my app is. This copy process is doing around 1 time each minute, more or less. The problem lies in that my app run at specifics intervals, open the four files and process certain matematical operations. What I see is that sometimes my app open one of the files while the OS is still copying files, so two process (my app and my .bat file) are accessing at the same time to the file.
Is there any way to lock file in order to access it, knowing no other process can write the file? I have noted and it is my main suspiction I am processing the file while os is finishing copy, so I dont get the data I want. This is the reason is happening from time to time, where the scheduled task match.
or any way to tell my program to wait until copy file has finished????
Any help will be wellcome?
thanks

fopen, _wfopen
You could try opening the files in "r+" mode, which should fail if another process already has the file open for writing.

Originally Posted by ZuK

You cannot use printf() in a signal handler.
Google for a list of allowed functions in signal handlers
Kurt

On Windows you can. This just looks like POSIX. It isn't actually POSIX. This is Windows World.

EDIT: Double-checked, and it turns out printf() is unsafe on Windows as well. Point still stands that the rules are not the same as POSIX, however.