I'm using Microsoft Visual C++ 6.0 and trying to debug someone else's program. I tried to use printf statements but for some reason, these statements are not shown on the screen as the program runs. I am able to use fprintf to print these statements to file, but this is useless when the program crashes in the middle of execution, as the file would be empty then.
How can I force some output to screen?
To force output to the screen, please see the first section below. The second and third options below are also good for debugging program crashes like these.
Using printf with fflush (refinement of Vishal Kumar's answer)
Vishal Kumar's answer worked for me, but I had to do a little research to find out how to use fflush. I had a problem where my program was crashing "in the middle" of a printf statement which did not make sense. Here is my refinement of his answer. In cases where a debugger is difficult to use (e.g. multithreading), you can use fflush after every printf (or fprintf) statement. For example, "pepper your code" with:
... // code
printf("Part 1 executed successfully");
fflush(stdout); // flushes the stdout buffer
... // further code
printf("Part 2 executed successfully");
fflush(stdout);
... // repeat as necessary
Run, observe the output, and put more print statements between the last statement that prints, and the first statement that doesn't print, until you isolate the problem.
Debugger
If you are able to use a debugger, it is a more efficient choice than peppering your code with output statements as described above, but there are cases where you have to resort to that.
Valgrind
If you are using Linux (which I gather you are not because it is in MS Visual C++), valgrind is another option to see where your code is crashing (and for detecting memory leaks). If your code is compiled for debug, if your program is called "myProgram", you can just call from the terminal window as follows:
valgrind myProgram
Related
I am working on a Tcl project where a certain procedure will run continuously. user can abort that procedure anytime using some Key-Combination. So basically, I need to trap the signal within Tcl code. So far, everything is done except one problem.
I am using Ctrl+Z i.e. SIGSUSP signal (SIGTSTP in case of Tcl) which technically does the job.
signal trap sigtstp onAbort
But, pressing Ctrl+Z immediately returns the Shell prompt, rest of the output from the program comes after that and when output comes to an end, no shell prompt returned (as it is already returned before). I need to press Enter again to get the prompt.
Following is the case I am refering to. You can see the prompt (polaris#ubuntu:~$) is returned in between output of the main program.
Also as output of pressing Ctrl+Z, it returned [40]+ Stopped, which is bit annoying. Can I avoid this ?
Can I avoid this whole problem using some other key-combination i.e. signal ? Or can I avoid this with Ctrl+Z also by tweking something ?
NOTE: I have tried using Ctrl+C. I got the exactly expected behavior with that. Unfortunately I can't use Ctrl+C as it is used for some other functionality.
Cz causes the shell to send the current foreground process a SIGSTOP(19). This signal cannot be caught or ignored and so your program will receive it and run the default handler. This is not killing the process as your question suggests you're trying to do. This only suspends it and you can bring it back into the foreground using fg on most modern shells.
Looks like you're out of luck. However, you might be able to rebind the keychord at the level of the shell. This is outside your program though and your end users don't have control over it. (Cf. https://superuser.com/questions/378018/how-can-i-do-ctrl-z-and-bg-in-one-keypress-to-make-process-continue-in-backgroun)
Also, if your program relies on user inputs for various actions (since you suggest that C-c does something else), perhaps you should make it a full fledged CUI application using curses or something?
I have been stuck for a while on a statement that causes a segmentation fault when commented out, from some of the information about this that I gathered people were saying that my stack was getting corrupted somewhere or somehow.
http://pastebin.com/NT8PGPi0
the code that cause the segmentation fault line number 511 (sorry for all the newlines linux didn't like when I copied it out of the editor)
basically with this project it should be able to print a .txt to the screen with different options chosen by the user for instance
./a.out --delete=c // deletes all the c's in the file and spots it to the console
./a.out --line-numbers // posts all the line numbers in the console
so on and so forth with the long options, same with the short options.
As was mentioned, the best option in such situation is always debug code by gdb or another debuger. But as a small hint. Look at this in Opt_Args function:
*c = getc(fp);
And then look at manual for getc:
int getc(FILE *stream);
I'm debugging my linux kernel module. It causes deadlock and i'm trying to figure out how. I'm using vmware + gdb. The idea is to hook the function and log backtrace into the file. I'm trying the following:
(gdb) br _raw_spin_lock
Breakpoint 5 at 0xffffffff815eb700: file kernel/spinlock.c, line 136.
(gdb) commands 5
Type commands for breakpoint(s) 5, one per line.
End with a line saying just "end".
>silent
>bt
>continue
>end
but continue doesn't work here. If i replace bt with echo 1 it works. Is there way to log information every time the function is called?
Thank you.
Most likely you are hitting gdb pagination prompt.
https://sourceware.org/gdb/onlinedocs/gdb/Screen-Size.html
Run this before setting the breakpoint
set height 0
You don't say why it doesn't work. What exactly goes wrong?
Normally this kind of thing works fine. Putting "continue" into a breakpoint's commands is something I've done routinely for years. It isn't without problems (it interferes with "next") but if you are just doing logging or the like, it works great.
One guess would be that the "bt" is failing with an error. This would cause the commands to abort and, I believe, the inferior to stop at the breakpoint. Then the question is, what exact error message is emitted? Or perhaps you're hitting pagination. Or maybe some other thing I haven't thought of :-)
If it's an error, one possible option might be to limit the backtrace.
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.
While debugging a program in Xcode I have several CFStringRef variables that point to strings with lengths around the 200 character mark.
In the debugger, it only shows the value of these strings up to a certain length and then just ellipses them away. I'd really like to see the full value of the strings.
Is there some option I can configure so it doesn't terminate them at arbitrary length?
In the debugging console you can get the string value by doing something like:
(gdb) print (void)CFShow(myCFString)
or:
(gdb) po (NSString*)myCFString
Either of those will display the entire string's contents to the debugging console. It's probably the easiest way to deal with large, variable-length strings or data structures of any kind.
For more information, the print command in the debugger basically dumps some data structure to the console. You can also call any functions or whatever, but since print doesn't have access to the function declarations, you have to make sure you provide them implicitly (as shown in the example above), or the print command will complain.
po is a shortcut for print-object and is the same as print except for Objective-C objects. It basically functions like this:
(gdb) print (const char *)[[theObject debugDescription] UTF8String]
This is really useful for examining things like NSData object and NSArray/NSDictionary objects.
For a lot more information on debugging topics, see Technical Note TN2124 - Mac OS X Debugging Magic and (from the debugger console) you can issue the help command as well.
To display really long string use method from print long string in xcode 6 debugging console
In lldb console increase max-string-summary-length
setting set target.max-string-summary-length 10000
Print your string with print or po commands
print my_string
If you are compiling c++ project in xcode just use this command
po string_name