debugging C with eclipse and cygwin - c

I am trying to debug the following C code with eclipse-Juno-CDT, and cygwin-gcc (cygwin version=1.7.16, gcc version=3.4.4, gdb version=7.5.50), on 64bit windows. The code works fine in normal mode. Initially debugger was not running, because the source file was not found. Then I searched around and added the path mapping information (from /cygdrive/c to C:\). Now it is running but with the following problems:
I have put a breakpoint before the "hello c 1" line, and then single stepping. But nothing gets printed on the console.
after single stepping on the last line ("exit"), I get the error: "No source available for _cygwin_exit_return() at ..."
// stdio.h and stdlib.h are included, but when I put a #include the code
// they dont show up, so I deleted those lines in this code fragment.
int main(void) {
int a=10;
int b=5; // breakpoint on this line, single step after this
printf("hello c 1\n"); // these outputs are not printed in console
// fflush(stdout);
printf("A=%d, B=%d\n", a, b); // but debugger shows the correct values in data window
// fflush(stdout);
return EXIT_SUCCESS; // error on this line
}
Added later: After some more debugging, I figured that even after the exit-error, if I do a "continue", then I am getting the lines on the console after the program terminates. So I added extra "fflush(stdout)" lines, and now I can see the outputs when they are being printed.
But how to fix the exit-error problem? Also, editing the file to add fflush to see debug outputs is a pain - is there a way to avoid this? Can somebody help me with this very basic problem, or point me to a place where the solution is given? Thanks in advance.

While logically a C program begins at int main() and ends when that function returns, environments (like Windows or Cygwin) frequently add pre- and post-code, for initializing / breaking down memory management, opening / closing standard streams, and other such bookkeeping. An executable compiled with Cygwin, after returning from int main(), switches to a cleanup function _cygwin_exit_return(), provided by the Cygwin runtime - for which you don't have sources, so your debugger complains.
As for getting the output immediately, you could use an unbuffered output stream.
Option one, use fprintf( stderr, ... ) (since stderr is by definition unbuffered). This, however, also affects the non-debugging behaviour of your program.
Option two:
int main()
{
// Using NDEBUG as also used by <assert.h>; feel free to use a different define
#ifndef NDEBUG
// For debugging, set stdout to unbuffered
setbuf( stdout, NULL );
#endif
....

Back when I was learning multithreading I was curious if threads were any faster than processes, and iirc I had to fflush even stderr/stdout on windows.
Memories aside, you can wrap those printf() in a function that calls fflush, or call setvbuf() to disable buffering.
About the exit: "no source available" only means that a part of your program lacks the info for debugging, so it's not a real error -- unless you build cygwin yourself, I guess the cygwin dll is stripped of debug symbols. Or maybe you want to debug cygwin's exit()?
EDIT: crap, concurrent answers :)

Related

The console window of VScode(visual studio code) closes immediately

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int a;
scanf("%d", &a);
printf("%d", a);
system("pause");
return 0;
}
Using the 'scanf', the console does not open properly. The visual studio code is too difficult. This is the first code. Please help me set the environment.
Does it answer your question?
system("pause"); - Why is it wrong?
Using system("pause"); is Ungood Practiceâ„¢ because
It's completely unnecessary. To keep the program's console window open
at the end when you run it from Visual Studio, use Ctrl+F5 to run it
without debugging, or else place a breakpoint at the last right brace
} of main. So, no problem in Visual Studio. And of course no problem
at all when you run it from the command line.
It's problematic & annoying when you run the program from the command
line. For interactive execution you have to press a key at the end to
no purpose whatsoever. And for use in automation of some task that
pause is very much undesired!
It's not portable. Unix-land has no standard pause command.
The pause command is an internal cmd.exe command and can't be
overridden, as is erroneously claimed in at least one other answer.
I.e. it's not a security risk, and the claim that AV programs diagnose
it as such is as dubious as the claim of overriding the command (after
all, a C++ program invoking system is in position to do itself all
that the command interpreter can do, and more). Also, while this way
of pausing is extremely inefficient by the usual standards of C++
programming, that doesn't matter at all at the end of a novice's
program.
So, the claims in the horde of answers before this are not correct,
and the main reason you shouldn't use system("pause") or any other
wait command at the end of your main, is the first point above: it's
completely unnecessary, it serves absolutely no purpose, it's just
very silly.

Program Execution not Occuring in Expected Sequence

I am using Eclipse (the latest version) along with Cygwin GCC (I have also observed the same issue while using MinGW GCC, and hence changed the GCC).
Consider a simple code snippet:
#include<stdio.h>
int main(){
char a[5];
printf("prompt1\n");
scanf("%s",a);
printf("\Hi\t%s",a);
}
The image shows the entire output of the program, which, as you can see, should be in a completely different order.
This issue was also on my old laptop (same version of Eclipse, with MinGW). However, I have (obviously) never come across this issue on an older version of Eclipse.
(The snippet has a different prompt text..but you get the jist of it)
EDIT: also occurs with the gets() function (but gets, and scanf are obviously displayed in the correct sequence)
printf uses stdout, it's a buffered file stream. It means, it sends data to the output after its internal buffer is full (the buffer size is 512 bytes or some another value). To dump data to the console immediately, use the function fflush before scanf.
#include<stdio.h>
int main(){
char a[5];
printf("prompt1\n");
fflush(stdout);
scanf("%s",a);
printf("Hi\t%s",a);
}
I saw another SO post where Cygwin didn't flush stdio when needed. Adding the following line before the scanf call should fix it.
fflush(stdout);

Debug Assertion Failed in C, Not Sure What's Causing It

I'm working on an assignment and I'm pretty much done, but I've run into a roadblock. I'm trying to print out all the "emirp" numbers my program generates, but if I try to print after running my EMIRP finding loop, it causes a Debug Assertion Failed error with this message.
Here's the program source.
http://pastebin.com/f81rE4hb
I'm a C++ guy in transition to using C, so maybe it's a C-specific problem causing it. If you need an explanation of anything, just ask. I'm compiling this with Microsoft Visual Studio 2012 Professional.
In my case it had to do with mixing unicode main program with non unicode external library written in C. This is what helped to me. Before calling first printf in external library I had to change console mode to ansi. After external library call I had to set mode back to unicode:
#include <io.h>
#include <fcntl.h>
_setmode(_fileno(stdout), _O_TEXT);
....
_setmode(_fileno(stdout), _O_U16TEXT);
Your problem is that you do emirps++:
You won't be able to free the memory that you've initially allocated, since emirps no longer points to the beginning of that memory.
You most certainly can't go about passing emirps[i] to printf (or any other function for that matter) at that point.
BTW, just noticed that there's a "whole bunch of mallocs" in your code not being freed anywhere...

Calling C from COBOL: trouble with stderr

From my COBOL program, I'm calling my C module which itself makes calls to a proprietary library. This library insists on writing to stderr, although there's no stderr available since the main program is written in COBOL. Consequently, the program aborts with this message:
cannnot open stderr
The support guys at HP advised me to issue
PARAM SAVE-ENVIRONMENT ON
in TACL before running the program. This indeed solved my problem. However, my program will be used by several people in a number of scripts and I don't want to force them to issue PARAM SAVE-ENVIRONMENT ON prior to running the program.
Is there some COBOL85 directive which allows me to properly run the program without changing any parameters manually? Something like
?PARAM SAVE-ENVIRONMENT ON
would be great...
EDIT:
Since I'm able to modify the C module (not the library), I'd be completely satisfied with a C-based solution. However, simply opening stderr before calling the library didn't solve my problem.
If you can execute TACL commands from Cobol, that could do it.
Can you open a file in Cobol assinged to stderr? Perhaps discovering exactly what PARAM SAVE-ENVIRONMENT ON does might help as well.
Most of the C contributors are not going to know the operating system on the HP/Tandem, which is going to impact the worth of answers. I have no idea if you can "shell out" from your C program to issue a TACL command or run a TACL script.
A bit of research with your Cobol, TACL, and C manuals for the HP/Tandem might lead you to answers, perhaps a google or two as well.
What is the problem with including the statement in their scripts anyway? If they want the program to work?
Not being an HP NonStop developer, I have some questions. stderr is a special symbol in C. File channel 2 (0 standard in, 1 standard out, 2 standard error), but those are low level channel numbers. stderr is a default pointer to a FILE structure. Falling back to GNU/Linux, /usr/include/stdio.h defines them as
/* Standard streams. */
extern struct _IO_FILE *stdin; /* Standard input stream. */
extern struct _IO_FILE *stdout; /* Standard output stream. */
extern struct _IO_FILE *stderr; /* Standard error output stream. */
/* C89/C99 say they're macros. Make them happy. */
#define stdin stdin
#define stdout stdout
#define stderr stderr
Opening a file named "stderr" isn't the same thing. Any process that is created should have 0, 1, and 2 already open. Should not matter what programming language is used for main. Is HP NonStop that much different than other POSIX-ey systems? stderr (the FILE pointer) is usually global to any code that includes stdio.h
As an aside, coming from an OpenCOBOL and GNU/Linux fanboy:
Regarding your other comment on lessons learned,
DO mix COBOL and C (and Fortran, and Ada, and Vala, and Python, and Java and ...)
DO use COBOL
PARAM SAVE-ENVIRONMENT ON makes HP COBOL-programs save environment variables (which they receive as messages at startup from Guardian) for future calls to getenv() from C modules.
Actually, the library I'm using tries to open stderr because it can't read environment variables. One solution is to set the PARAM SAVE-ENVIRONMENT to ON, so getenv() will properly function again. This has to be done in each TACL session.
Unless: you use the ?SAVE STARTUP- or ?SAVE ALL-directive in your COBOL program to achieve the same effect.
Lessons learned:
Don't mix COBOL and C.
Don't use COBOL at all.

Equivalent to Windows getch() for Mac/Linux crashes

I am using getch() and my app crashes instantly. Including when doing:
int main()
{
getch();
}
I can't find the link but supposedly the problem is that it needs to turn off buffering or something strange along those lines, and I still want cout to work along with cross platform code.
I was told to use std::cin.get(), but I'd like the app to quit when a key is pressed, not when the user typed in a letter or number then press enter to quit.
Is there any function for this? The code must work under Mac (my os) and Windows.
Linking/compiling is not an issue; I include <curses.h> and link with -lcurses in XCode, while Windows uses <conio.h>.
Have you looked in <curses.h> to see what the getch() function does?
Hint: OSX and Linux are not the same as Windows.
Specifically, as a macro in <curses.h>, we find:
#define getch() wgetch(stdscr)
Now, there appears, on your system, to be an actual function getch() in the curses library, but it expects stdscr to be set up, and that is done by the curses initialization functions (initscr() and relatives), and that is signally not done by your code. So, your code is invoking undefined behaviour by calling curses routines before the correct initialization is done, leading to the crash.
(Good hint from dmckee - it helped get the link line out of acidzombie24, which was important.)
To get to a point where a single key-stroke can be read and the program terminated cleanly, you have to do a good deal of work on Unix (OSX, Linux). You would have to trap the initial state of the terminal, arrange for an atexit() function - or some similar mechanism - to restore the state of the terminal, change the terminal from cooked mode into raw mode, then invoke a function to read a character (possibly just read(0, &c, 1)), and do your exit. There might be other ways to do it - but it certainly will involve some setup and teardown operations.
One book that might help is Advanced Unix Programming, 2nd Edn by Mark Rochkind; it covers terminal handling at the level needed. Alternatively, you can use <curses.h> properly - that will be simpler than a roll-your-own solution, and probably more reliable.
You have not exhibited a
#include <stdio.h>
or
#include <curses.h>
or similar line. Are you sure that you are linking against a library that includes getch()?
Use the cin.get() function for example:
#include <iostream>
using namespace std;
int main()
{
char input = cin.get();
cout << "You Pressed: " << input;
}
The program would then wait for you to press a key.
Once you have, the key you pressed would be printed to the screen.
The getch function is not available on Unix-like systems, but you can replace it with console commands through your compiler with the system function.
Usage:
In Windows you can use system("pause");
In Unix-like systems (such as OSX) you can use system("read -n1 -p ' ' key");
Note: system is declared in <stdlib.h>.

Resources