I get an exit error code 0xc0000417 (which translates to STATUS_INVALID_CRUNTIME_PARAMETER) in my executable (mixed Fortran/C) and try to find out what's causing it. It seems to occur when trying to write to a file which I infer because the file is created but there's nothing in it. Yet I have the suspicion that's not the /real/ cause. When I disable writing of that file, which is done from C code, it crashes when writing a different file, this time from Fortran code.
The unfortunate thing is: this only happens after the program (a CPU heavy calculation) has finished after having run for ~2-3 days. When I tried to shorten the calculation time by various means to facilitate debugging, the problem did not occur anymore. It almost seemed like the long runtime was crucial for triggering the problem.
I tried running it in Visual Studio 2015 but VS does not break/stop (like it would if e.g. a segfault had happened) despite having turned on breaking at all the C++ Exceptions, like was suggested in some other thread and all Common Language Runtime Exceptions.
What I would like VS to do is to either break whenever that error code is 'produced' and examine the values of variables or at least get a stack trace.
I searched intensively but I could not find a satisfactory solution to my problem. In essence, my question is similar to how to debug "Invalid parameter passed to C runtime function"? but the problem does not occur with the linux version of my program, so I'm looking for directions on how to debug it on Windows, either with Visual Studio or some other tool.
Edit:
Sadly, I was not able to find any convenient means of breaking automatically when the error occurs. So I went with the manual way of setting a breakpoint (in VS) near the supposed crash and step through the code.
It turned out that I got a NULL pointer from fopen:
myfile = fopen("somedir\\somefile.xml");
despite the file being created. But when trying to write to that file (via the NULL handle!), a segfault occurred. Strangely, it seems I only get a NULL pointer from fopen when the process has a long lifetime. But that's offtopic for that question.
Edit 2:
Checking the global errno variable gave error code 22 which again translates to an invalid argument. However, the argument to fopen is not invalid as I verified with the debugger and the fact that the file is actually created correctly (with 0 bytes length). Now I think that that that error code 22 is simply misleading because when I check (via a watch in VS) $err, hr I get:
0x000005aa ERROR_NO_SYSTEM_RESOURCES : Insufficient system resources exist to complete the requested service.
Just like mentioned here, I have plenty of HD space (1.4 GB), plenty of free RAM (3.2 GB), and I fear it is something not directly caused by my program but something due to broken Windows design of file handling (it does not happen under Linux).
Edit 3: OK, it seems it is not Windows itself that's the culprit but rather the Intel Fortran compiler I'm using. Every time I'm doing formatted write statements in my program, a Mutant (Windows speak for mutex) handle is leaked. Using WinDbg and !htrace -enable, then running a bit further, break and issue !htrace -diff gives loads of these backtraces:
0x00000000777ca25a: ntdll!NtCreateMutant+0x000000000000000a
0x000007fefd54a1b7: KERNELBASE!CreateMutexExW+0x0000000000000057
0x000007fefd551d60: KERNELBASE!CreateMutexExA+0x0000000000000050
0x000007fedfab24db: libifcoremd!for_lge_ssll+0x0000000000001dcb
0x000007fedfb03ed6: libifcoremd!for_write_int_fmt+0x0000000000000056
0x000000014085aa21: myprog!MY_ROUTINE+0x0000000000000121
During the program runtime these mutant handles seem to accumulate until they exhaust all handle resources (16711680 handles) so that there's nothing left for file handles.
Edit 4: It's a bug in the intel fortran runtime libraries that has been fixed with a later version (see here). Using the patched version of libifcoremd.dll fixes the problem, i.e. the handle count does not increase anymore during formatted writes.
It could be too many open files or leaked (not closed) handles. You can check that with e.g. Process Explorer (I think you could see the number of handles in the process with it).
Related
The title says it all. Since C doesn't have exceptions, I'm not exactly sure how to handle errors. I've thought of the advantages and disadvantages of both:
ABORTING:
Basically what I mean by this is to return an error code (which will be declared in a .h file, maybe with its own perror()-like function) and abort the function, and the obvious advantage is that it helps the user do error-handling, but the disadvantages are:
If the function is not checked every time after it is executed for an error, and an error does indeed occur, it could cause big problems as the program progresses and the user will have a hard time finding where the issue is coming from.
Looking through the header file for the error codes can be tough and annoying.
Error codes may conflict with error codes in other libraries or the builtin C error codes.
EXIT THE PROGRAM:
Pretty self-explanatory: as soon as an error is found, print the error to stderr and exit. The advantage of this is that if the error message is detailed enough, the user will easily know what is wrong with their code and fix it, but the main disadvantage is that the user will not be able to write any code that could handle a possible error and would instead have to change the code itself (and it becomes a bigger problem when you need to ask for input or something similar, in which there are millions of possible errors that could arise from incorrect input).
This largely depends on what your program is doing. Some programs such as simple command line utilities will just abort on invalid input for example, without affecting much neither the user experience, nor the system stability. The user will simply correct themselves and rerun. On the other hand, if it is a safety-critical system, such as military, medical or transportation equipment (read autopilot, pacemaker and such) aborting its program will cost human lives. Or as suggested in the comments - a simple word processor. The user might be very unsatisfied if they loose all their work after made some stupid mistake which caused some program error.
So the general approach to writing a robust software would be to classify your errors as fatal and non-fatal. Non-fatal are the ones you can anticipate during normal program run and can be gracefully handled in a way which allows the program to continue. Fatal ones are the ones which are caused by some abnormal conditions (hardware failure, missing components and such) which make the program not to be able to continue.
Depending on the system nature you might want to loosen or tighten the above classification.
Return a proper error code from that function. Otherwise it would be hard to use that function in a different context, like a unit test. Also it wouldn't be possible for the calling program to cleanup it's resources or, simply print an error message.
I am trying to code simple program in C which writes and reads something from Windows registry. What does the return value of 7 for RegOpenKeyEx mean?
I am having a hard time trying to guess it. Yes, MSDN says I can use FormatMessage to examine it, but it takes 7 arguments and I have no idea how to use it... (what an awful api design by the way).
The MSDN entry for RegOpenKeyEx also indicates that:
If the function fails, the return value is a nonzero error code defined in Winerror.h.
Those error codes are documented in MSDN - System Error Codes page. If you really are getting 7, then this error would correspond to:
ERROR_ARENA_TRASHED
7 (0x7)
The storage control blocks were destroyed.
What it means could range from your registry being corrupted, to a slew of program errors resulting in seemingly weird behavior, or to simply that you are getting something else as a return value and are lead to believe you are getting a result of 7. Without a more complete code example, it is hard to venture anything more specific.
P.S.: FormatMessage is mostly handy if you are trying to obtain a string representation of the error at run time. If that's the case, you can refer to this answer for an example on how to use it.
I am trying to use MATLAB Coder to convert code from Matlab to a MEX file. If I have a code snippet of the following form:
x = zeros(a,1)
x(a+1) = 1
then in Matlab this will resize the array to accommodate the new element, while in the MEX file this will give an "Index exceeds matrix dimensions" error. I expect there are lots of places in the code where this is happening.
What I want to do is run the MATLAB version of the code (without using the coder) but have MATLAB generate an error or warning whenever it resizes an array because I assign to something outside the bounds. (I could just use the MEX file and see where the errors pop up, but this requires rebuilding the whole MEX file using MATLAB Coder every time I change the code at all, which takes a while.)
Is there a way to do this? Is there any kind of setting in MATLAB that will turn off the "automatically resize if you assign to an out-of-bounds index", or give a warning if this happens?
EDIT: As of Matlab 2015b, Coder now has runtime error checking as an option (from the Matlab release notes):
In R2015b, generated standalone libraries and executables can detect and report run-time errors such as out-of-bounds array indexing. In
previous releases, only generated MEX detected and reported run-time
errors.
By default, run-time error detection is enabled for MEX. By
default, run-time error detection is disabled for standalone libraries
and executables.
To enable run-time error detection for standalone
libraries and executables:
At the command line, use the code
configuration property RuntimeChecks.
cfg = coder.config('lib'); % or
'dll' or 'exe'
cfg.RuntimeChecks = true;
codegen -config cfg myfunction
Using the MATLAB Coder app, in the project build settings,
on the Debugging tab, select the Generate run-time error checks check
box.
The generated libraries and executables use fprintf to write
error messages to stderr and abort to terminate the application. If
fprintf and abort are not available, you must provide them. Error
messages are in English.
See Run-Time Error Detection and Reporting in Standalone C/C++ Code and Generate Standalone Code That Detects and Reports Run-Time Errors.
Original answer:
The answer in the comments regarding declaring a class subclassed from double wherein the subsref method is overloaded to disallow growing would be one good way to do it.
Another easy way to do it is to sprinkle assert commands throughout the code (in each loop iteration or at the bottom of a function) to assert that the size has not increased over the allocated size.
For instance, if you had the code in a format of:
x = zeros(a,1)
x(a+1) = 1
... lots of other operations
if coder.target('MATLAB')
assert(isequal(size(x), [a,1]), 'x has been indexed out of bounds')
end
this would let you have the assertion fail if any value were assigned that extended the array.
To make this a bit tidier, you might even make a function that bounds checked all the variables you care about, again wrapping the coder.target if statement around it. Then you could sprinkle this throughout your code.
It's not as elegant as overloading the double class, but on the other hand it doesn't add any overhead to the compiled code at all. It also won't give you errors exactly when the overrun happens, but it will give you confidence that the code is working well in a variety of situations.
Another way that you can be more confident of assignments is to do your own bounds checking on the assignment in situations where this may be appropriate. A common problem I've seen in assignment goes something like this. We have an allocated array and are copying in data from another array with a vector assignment. For instance, consider the following situation:
t = char(zeros(5,7)); % Allocate a 5 by 7 char array
tempstring = 'hello to anyone'; % Here's a string we want to put into it.
t(1, 1:numel(tempstring)) = tempstring; % A valid assignment in MATLAB
>> size(t)
ans =
5 15
Uh oh, exactly what you're concerned about in the question has happened: the t array has been automatically resized during the assignment, which works in MATLAB, but in Coder created code will cause a segfault or MEX error. An alternative is to use the power of the end function to keep the assignment tidy (but truncated.) If we change the assignment to:
t(1,1:min(end,numel(tempstring))) = tempstring(1:size(t, 2));
The size of t will remain unchanged, but the assignment will be truncated. The use of end allows bounds checking during the assignment. For some situations, this can be a nice way of handling the issue and will give you confidence that the bounds will never be exceeded, but obviously in some situations this is very undesirable (and won't give you error messages in MATLAB.)
Another helpful tool MATLAB provides is in the editor itself. If you use the %#codegen tag in your code, it will signal the editor's syntax checker to highlight various code generation problems, including places where you are obviously increasing the size of an array by indexing. This can't catch every situation, but it's a good help.
One last note. As mentioned in the question, a MEX file generated by Coder will give you an "Index exceeds matrix dimensions" error right at the time of the assignment, and will gracefully exit and even tell you the original line of code where the error occurred. A C library generated out of Coder has no such nice behavior or bounds checking and will segfault out completely with no diagnostics. The intermediate answer is to do exactly what you're doing, which is to run the code as a MEX. That's not very helpful to your question (as you say, rebuilding the MEX can take time), but for those of us who code for the cold, cruel world of external C code, the intermediate test of being able to run the MEX to find these errors is a lifesaver.
The bottom line is this is a divergence in behavior between MATLAB and Coder generated C code, and it can be a source of significant problems. In my own code, I am very careful with array access and growth for exactly this reason. It's an area where I'd like to see improvement in the Coder tool itself, but there are ways to be very careful when writing MATLAB code targeted for Coder.
When I try to debug my C program, and even before the compiler starts executing any line I get:
"Unhandled exception at 0x00468867 in HistsToFields.exe: 0xC00000FD: Stack overflow."
I have no clue on how to spot the problem since the program hasn't even started executing any line (or at least this is what I can see from the compiler debugging window). How can I tell what is causing the overflow if there isn't yet any line of my program executed?
"The when the debugger breaks it points to a line in chkstk.asm"
I'm using Microsoft Visual Studio 2008 on a win7.
I set the Stack Reserve Size to 300000000
PS: the program used to execute fine before but on another machine.
I have a database (120000 x 60)in csv format, I need to change it to space delimited. The program (which I didn't write myself) defines a structure of the output file:
`struct OutputFileContents {
char Filename[LINE_LEN];
char Title[LINE_LEN];
int NVar;
char VarName[MAX_NVAR][LINE_LEN];
char ZoneTitle[LINE_LEN];
int NI;
int NJ;
int NK;
double Datums[MAX_NVAR];
double Data[MAX_NVAR][MAX_NPOINT];`
This last array "Data[][]" is what contains all the output. hence is the huge size.
This array size "MAX_NPOINT" is set in a header source file in the project, and this header is used by several programs in the projects.
Thank you very much in advance.
Ahmad.
First, IDE != compiler != debugger.
Second, and no matter why the debugger fails debugging the application - a dataset that huge, on the stack, is a serious design error. Fix that design error, and your debugger problem will go away.
As for why the debugger fails... no idea. Too little RAM installed? 32bit vs 64bit platform? Infinite recursion in constructing static variables? Can't really say without looking at things you haven't showed us, like source, specs of environment, etc.
Edit: In case the hint is missed: Global / static data objects are constructed before main() starts executing. An infinite (or just much-too-deep) recursion in those constructors can trigger a stack overflow. (I am assuming C++ instead of C as the error message you gave says "unhandled exception".)
Edit 2: You added that you have a "database" that you need to convert to space-delimited. Without seeing the rest of your code: Trying to do the whole conversion in one go in memory isn't a good idea. Read a record, convert it, write it. Repeat. If you need stuff like "longest record" to determine the output format, iterate over the input once read-only for finding the output sizes, then iterate again doing the actual conversion.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I had my code working earlier in the day on the unix machine, but when compiled under windows it gave me completely strange and incorrect output.
Since our code is going to be marked based on compilation on unix I thought hey that's good enough. But now I just finished refactoring my code (basically just adding comments, getting rid of variables which were never used in the program and getting rid of some functions which I wrote to test the program) and now suddenly my code seems to be giving me the proper output on windows and wrong output on unix.
Note that I have done nothing to modify the functionality of the code.
After spending so many hours working on this banging my head against Seg Fault errors through the week, this last minute bug is going to put it all to waste. What am I supposed to do when the bug is seemingly appearing at random?
Edit: The program is supposed to read a file similar to an html file and print out the tables. I'm loading the data of each individual cell onto a node in a Linked List and then printing out the info based on an algorithm. The output is working fine on windows now but not on unix. I don't even know what part of the code I need to look since I have no idea what's causing this.
Based on the amount of information you supplied (next to none), the best guess is to look for uninitialized variables. That will produce different output on different platforms, and is a common beginner mistake in C.
I suggest you use gdb to debug your code and check where the segmentation fault is arising. That will give you a good hint of were to start looking, even though you don't remember to have done any modification.
There is plenty documentation on the web.
These are the basics:
shell> gdb myprogram
gdb> backtrace #lists the steps until the segmentation fault arises
gdb> select 2 #You can select any step you want (e.g. 2)
gdb> print number #print variables to hack around
There are a lot of features for gdb. I think this will give you a hint quickly.
Don't forget to use a version control system the next time. It's a safe and nice way of having your code organized and clean, and off course!, to avoid these terrible accidents.
(SVN or GIT are cool enough)
Step 1, make a copy of everything.
Copy the entire project somewhere. Make a note of what state the project was in when you made that copy and the date:time. DO NOT edit that copy. You may even make the files unwritable if you want. You need to be able to see what you have changed as well as go back to it. Even though the program does not currently work on Unix, it does work under Windows, so you know that it does have some merit and is close to being useful to turn in. When I get upset at a program I am writing or at the compiler for not understanding it (this happens a lot less now then it did 10 years ago) I tend to lose track of what all I am changing, so changing it back becomes difficult. Using some type of version control (even just keeping extra copies around) will help you to keep track of what you have changes so when you make a mistake you can unmake that mistake pretty easily. Differencing tools, like diff are very helpful when you know how to use them. For right now you might want to try:
diff --minimal --side-by-side --ignore-all-space old_file.c new_file.c | less
Hopefully you are using a diff that supports those options because I think that they may be the most helpful for you in the short time that you have. If you find that you need to fit more on the screen and your terminal window is large you can also add in the --width= command and give it a number of characters in a line on your terminal.
Anyway, make and keep lots of copies of your code until you know that you won't need them anymore (and maybe even then).
If you have graphical access see if kdiff3 is available. It may be easier for you to use quickly. The 3 in its name refers to the ability to compare 3 versions of a file at one time (a common starting point and two edited versions of that file) and is useful, but you can learn about that later. It is perfectly able to compare just two versions of a file and produce decent output.
Step 2 Don't ignore warnings
I suggest that you compile it with the highest warning level possible with your compiler and DO NOT ignore any warnings. If you already have warnings without telling the compiler to issue more warnings then examine those first. Warnings are there for a reason, and only occasionally should you ever encounter code the produces warnings that should just be ignored (and even then I usually add a comment about the expected type of warning and why it is not an error). With gcc you can add the -Wall option to the compile command to issue all warnings.
gcc -Wall my_program.c -o my_program
Some may not make sense to you, but you can at least look at the code and see what might be unclear about it in the vicinity of the warning line.
step 3 Use simple lines of code
Something that will make warnings easier to understand is using very simple to understand lines of code. Trying to fit too much functionality into one line of code makes it so that any warning or error message about that line of code is much more difficult to understand.
step 4 Use temporary variables
Temporary variables don't necessarily mean "my program uses more memory" but they do often mean the compiler gives more meaningful warnings because the data-types of variables in expressions are much clearer.
step 5 Use functions
This is just a continuation of the philosophy from 3 and 4. Functions make things easier to understand. They also make it so that often when you find an error and fix it you don't have to worry about having copies of the erroneous code elsewhere in the program that also needs to be fixed (though you should still search for similar code just to be sure).
step 6 assert
There is a macro (like a function, but not quite) called assert that lives in #include <assert.h> and can help you find all kinds of errors by making your program fail earlier than it otherwise would. This sounds bad, but very often (especially with memory related problems like segmentation faults (SIGSEGV) ) programs are in a fatal state well before they die. Using assert helps you to move their death to an earlier place so that you can see what their fatal mistake was, rather than just seeing the result of it.
assert takes as its parameter a boolean expression -- any comparison, integer, floating point number, or pointer will do. Anything that you could use as a condition in an if or while will do. If this expression is false (0 or NULL) then your program will die right there and on many systems it will give you a helpful error message about where the assertion that killed the program was located and maybe even what the assertion was. There is another helpful thing that this causes which I'll talk about in a little bit, but for now, to use assert you just do:
assert(x < y);
and if x is not less than y the program will abort (actually call the abort function).
This is helpful for things like:
int clear_buffer(char * buffer, unsigned len)
{ /* len should be size_t but I don't want to explain that right now */
assert(buffer);
memset(buffer, 0, len);
}
Step 7, Use a debugger
If you have gdb on your Unix system then GREAT. If not, you probably have some other debugger than you can learn how to use. Many Unix C compilers take the -g option to mean "include debugging symbols", so add that to the other options you are passing to the compiler and recompile your program, and then do:
gdb ./myprogram
Which will print some stuff and then prompt you with:
(gdb)
Then you can set break points and all kinds of good stuff, but since you are in a hurry and getting crashes just do:
(gdb) r
Include any arguments after the r that you would be passing to your program when you normally ran it. gdb will then run your program until something odd happens. The something odd, in this case, should be a SIGSEGV (what UNIXes do to your program when it tries to access memory addresses that it shouldn't). gdb will then prompt you with (gdb) again. You can then do:
(gdb) bt
bt stands for back trace and gdb will print out the call stack, meaning all functions that were called to get to the current function. You should see main near the bottom. Look for the first function near the top that is a function you wrote. This is where you need to start trying to find errors. If the top function on the list is not one of yours then try issuing:
(gdb) up
Which will make it examine the previous function on the call stack. Once in one of your functions say:
(gdb) list
And it will show you some code around the area where things are wrong.
To exit gdb you do:
(gdb) quit
And answer Y if it ask you if you really want to quit.
If you were to use assert and that killed your program then you would not end up with quite as much library stuff on top of the call stack to confuse you.
Sadly 3, 4, and 5 mess up the ability to get good info from diff so I suggest trying to limit your adding of this programming style into places where you are having errors or warnings already (at least for now).
I hope that this helps
First of all, we will need your code to see what's going on. But if what you described is true then it is most likely that your code contains what's called undefined behavior. Undefined behavior can occur due to too many reasons, such as crossing array boundaries, incorrectly deleting pointers etc.etc. So, without code nothing can be said
Run it through valgrind.
I can guarantee you will find your error with valgrind.
If you've got access to a unix or linux machine, you should never release code that you haven't run through valgrind, even if the code works.
With the data you've provided, here is my solution.
Take a break and zone out of the problem domain for a while.
Use a debugger, step through the program, identify where it is segfaulting.
Print data at the point of the segfault and validate it.
That should solve the problem.
Compile your code with all warnings on.
Don't hide warnings with bogus casts, but take them seriously and resolve the real problems.
Use different compilers. On linux clang is a good alternative and gives way more indications than gcc.