I wanted to show my students how to use regular expresions. As they are learn programming in C, I thought it would be the best to use regex.h from GnuWin32 (http://gnuwin32.sourceforge.net/packages/regex.htm). As an example I tried to run http://www.peope.net/old/regex.html programm, but it causes an exception on the variable holding the regular expression at runtime . The precise error message is:
Run-Time Check Failure #2 – Stack around the variable 'regex' was corrupted
The courius thing is that the example itself is running properly and the regex functions seems to work properly. The error happens after all the important things are over at the point where main() wants to return.
Has anybody an idea of why this error occurs? Could the 64-Bit System I'm using be part of the problem?
Thanks for any advice!
Related
I was solving cs50x pset6 Webserver problem and I would be very grateful if someone could help me.
Can anyone explain what is happenning below in gdb(also in source code itself) please?
Optimized out and Gone String Variable
The problem is that manipulation string variables is needed in this problem set, but somehow I lose them whenever new variable comes up(along).
I tried compiling differently as suggested by some sources e.g. https://cs50.stackexchange.com/questions/9033/variable-optimized-out-eventhough-it-will-be-used-later .
But nothing has changed even I tried other solutions.
So guys I will appreciate if you can help me to fix this issue.
Here is my source code(lines 151-391): http://codepaste.net/2uipag
Edit: This error is affecting not just debugging mode, but the program itself isn't giving intended result. Basically:
Line ="GET /cat.html HTTP/1.1"
absolute_path="/cat.html" (extracted using strncpy())
root="/home/jharvard/pset6/public"
path= root along with absolute_path (strcat())
Because absolute_path is optimized out instead of getting "home/jharvard/pset6/public/cat.html" for path variable, I am getting "home/jharvard/pset6/public"
I apologize for being unclear and thank you for assistance.
It is difficult to say what is happening with any specificity, but most likely, at some point after the last use of your line pointer by the function, the optimized version of the program re-uses its storage for something else. If the variable is still in scope at that point then in principle you should still be able to examine its value, but if your program in fact does not examine its value then it makes no difference in program behavior. Except as viewed via a debugger.
If you intend to run your code in a debugger then it is best to compile it (for that purpose) with optimization disabled (option -O0 for many C compilers, including gcc). After you have worked out the problems, compile your final program with whatever optimization level you deem appropriate.
I'm trying to create an Xtext parser for a scripting language that I use. The language is quite close to ANSI-C.
I started by converting this https://github.com/antlr/examples-v3/blob/master/C/C/C.g grammar to Xtext and removing the parts I don't need (structs, typedefs, etc.)
However, I run into problems and I don't know how to debug them properly and find my errors.
I receive
error(10): internal error: org.antlr.tool.Grammar.createLookaheadDFA(Grammar.java:1279): could not even do k=1 for decision 39; reason: timed out (>10000ms)
and also OutOfMemoryError exceptions.
EDIT: I have already tried increasing the memory & timeout. However, even with LARGE values, this does not work.
Can anyone suggest ways to "debug" the grammar? Where is decision 39? I would love to locate the problem, but I couldn't find anything.
PS: I've posted the grammar listing here, to not clutter the post up http://pastebin.com/8AYNUbSD
You can generate an Antlr grammar (.g) by activating debug mode in your workflow.mwe2, add the following fragment:
fragment = org.eclipse.xtext.generator.parser.antlr.DebugAntlrGeneratorFragment {}
Then, you can debug this debug grammar by using AntlrWorks IDE
Quick tutorial here
I'm getting an "invalid operation" error when trying to use glUseProgramObjectARB and I have no idea why.
The shader programs are loading correctly, I'm fairly sure. This is shown on glGetInfoLogARB:
Vertex shader was successfully compiled to run on hardware.
Fragment shader was successfully compiled to run on this hardware.
There are no previous openGL errors before this command. So something with this specific command definitely appears to be the issue.
I'm using glew with SDL. I was using GLee before, and getting the same problem.
Reading the documentation I assume it is this error:
GL_INVALID_OPERATION is generated if program could not be made part of current state.
but I'm not sure exactly what could cause such a thing. The command is issued in a working openGL context, as all the previous shader commands work fine. It is not between a "begin" and "end" block.
Really I am stumped as to what it could mean. Perhaps there is some more specific case when the command can't be issued. If anyone knows anything more that would be great.
EDIT:
Solved: oh jesus that was retarded, I was missing a return on one of my function calls elsewhere and so wasn't passing back the program I'd constructed.
Without seeing your code it's hard to know, but since you explicitly mention the results of glCompileShaderARB (times two) but not glLinkProgramARB I will guess that you forgot to glLinkProgramARB (after which, by the way, you can safely glDeleteObjectARB the two shader objects).
How can I find where the error occurs?
In C language, the return value means what error occurs,
such as failure to open file or memory allocation.
There is no information where the error occurs.
For example, function 'foo' calls A,B,C,D.
If foo returns an error value, it might be return value of A or B or C or D.
I cannot find what function returns error.
I have to run debugger or add some codes to find what function returns error.
Yes, you'll have to use a debugger or add extra code to display some output. Also, make sure you look at the pre-conditions for the function you call (if there are any) - make sure that you obey what it demands before calling it.
I think you've answered your question, you need to use a debugger to find out.
Maybe add some breakpoint, look if the error occurs always or only sometimes, and in the same place.
C library functions like fopen() set errno to give you a bit more diagnostic information. You could use a similar strategy. But if you don't program in some way of getting extra information out like that, you are stuck with the debugger.
Design an appropriate error handling that provides the informations you need. Then write your functions around this design. Using the return values is just one of many possibilities to do this, but obviously not enough for your specific requirements.
What error occurs is a clue for where it occurs: if A can return only error #5, B only #42, C only #3 and D only #56, whenever foo returns #5, you know that it comes from A.
If error codes overlap over different functions, you can get other clues from your inputs and your outputs: if D either displays a message or issues an error #5, whenever foo returns #5 and the message gets displayed, you know that error comes from A.
If error code, inputs and output are not enough to retrieve error location, you have to increase observability of your program. Some solutions are:
add debug info and use a debugger
add logs that you can activate or inhibit at will
select unique error codes so that what error occurs identifies where it occurs as well
I have been thinking about the difficulty incurred with C error handling.. like who actually does
if(printf("hello world")==-1){exit(1);}
But you break common standards by not doing such verbose, and usually useless coding. Well what if you had a wrapper around the libc? like so you could do something like..
//main...
error_catchall(my_errors);
printf("hello world"); //this will automatically call my_errors on an error of printf
ignore=1; //this makes it so the function will return like normal and we can check error values ourself
if(fopen.... //we want to know if the file opened or not and handle it ourself.
}
int my_errors(){
if(ignore==0){
_exit(1); //exit if we aren't handling this error by flagging ignore
}
return 0;
//this is called when there is an error anywhere in the libc
}
...
I am considering making such a wrapper as I am synthesizing my own BSD licensed libc(so I already have to touch the untouchable..), but I would like to know what people think about it..
would this actually work in real life and be more useful than returning -1?
during this years I've seen several attempts to mimics try/catch in ANSI C:
http://simgrid.gforge.inria.fr/doc/group__XBT__ex.html
http://llg.cubic.org/trycatch/
I think that try/catch approach is more simple than your.
But how would you be able to catch the error when it was expected? For example I might expect a file open to fail and want to deal with it in code instead of the generic error catcher.
To do this you would need two versions of every function. One that trapped errors and one the returns errors.
I did something like this long ago without modifying the library. I just created wrapper functions for common calls that did error checking. So my errchk_malloc call checked the return and raised an error if the allocation failed. Then I just used this version everywhere in place of the built in malloc.
if the goal is to exit cleanly as soon as you encounter an error that's ok... but if you want to do a minimum of error recovery, i can't see how your approach is useful...
To avoid this kind of problem, I sometimes use LD_PRELOAD_PATH to integrate my error management (only for my own projects since this is not a really good practice...)
Do you really want to change the standard behaviors of your LIBC ? You could add a few extensions around common functions.
For example, Gnome uses g_malloc and g_try_malloc. The former will abort on failure while the later will simply yield a null-pointer like malloc.