What happens is that the .c files are not printing well to Eclipse's console.
printfs() print to console like they should but errors are not being showed.
I've tried:
-Go to Window->Preferences->Run/Debug->Console the option "Show when program writes to standard error" is toggled on.
My OP is Linux Cinnamon 32-bit.
Note: If I use the terminal it shows the errors of the program in question.
Related
I am working on this piece of code, trying to learn basic C programming.
I managed to compile and run a basic program.
Then, when I try to run a code on which the compiler raises an error, the problem starts -- from then on I get:
c:/mingw/bin/../lib/gcc/mingw32/4.9.3/../../../../mingw32/bin/ld.exe: cannot open output file tests.exe: Permission denied
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[3]: *** [tests.exe] Error 1
mingw32-make.exe[2]: *** [CMakeFiles/tests.dir/all] Error 2
No matter what I change to code to, even to just a basic int main() {return 0;} code, I keep getting that problem.
Edit (integrated from comment):
Found the solution, I had the program still running and I had to manually stop it. I am used to python/java, where once you get an error the program stops. Should it not be like that in C as well?
I assume the error that triggers the linker failure later on is actually a runtime error, not a compiler one.
As you have found out, Windows cannot overwrite a file which is opened in a running program (or is the running program itself), hence the error when ld.exe (the linker) tries to create a new executable.
The most probable cause is that you are starting your program in debug mode (the green beetle icon) instead of a normal run (the green "play" arrow). This attaches a debugger (probably gdb) to your program. When your program crashes, the debugger stops it in its tracks and waits for you to investigate, thus keeping the process alive.
Make sure the debug tools are not hidden in some way, or just launch your program without a debugger when you want it to fail fast.
I am trying to run a simple linked list program in code blocks, but I am not able to run the program and i getting the below error :
Active debugger config: GDB/CDB debugger:
Default Building to ensure sources are up-to-date Selecting target:
Debug ERROR: You need to specify a debugger program in the debuggers's settings.
(For MinGW compilers, it's 'gdb.exe' (without the quotes))
(For MSVC compilers, it's 'cdb.exe' (without the quotes))
I tried some of the posts given here on Stack Overflow, but that setting is already there in the code blocks.
Find out where gdb.exe is located in whatever GCC toolchain you
are using with Code::Blocks, e.g:-
For MinGW: C:\MingGW\bin\gdb.exe,
For mingw-w64: C:\mingw-w64\x86_64-5.2.0-posix-seh-rt_v4-rev0\mingw64\bin\gdb.exe
For TDM-GCC: C:\TDM-GCC-64\bin\gdb.exe
If you can't find it then the root of the problem is that the debugger is (no longer)
installed.
If you find it, then enter its full pathname in Settings -> Debugger settings -> GDB/CDB debugger -> Default -> Executable path.
Code::Blocks will check the pathname you enter and if it can't find it then the edit-field will turn red. Otherwise, OK out
and the debugger will then work.
If the directory containing gdb.exe is in your PATH then you can simply enter gdb.exe in the field.
So I wrote a POSIX Threads application in C (linux) in which you get as command line args the number of threads , and the filename which the threads will work on.It works.
Now I also need to make it work in windows.
I've changed all the necessary names and headers , but since I'm trying to do it in VS2012 , I don't know how to get the Debugger output.
printf does not work , obviously , so what can I use instead ?
The code is included in a C++ WinConsoleApp project.
You can use OutputDebugString function, but the VS output window should work only for debugger output. For console output, you should create Windows 32 Console Application project.
Other way is to allocate console yourself:
AllocConsole();
freopen("CONIN$", "r",stdin);
freopen("CONOUT$", "w",stdout);
freopen("CONOUT$", "w",stderr);
I'm having some problems with a program causing a segmentation fault when run on a Mac. I'm putting together an entry for the IOCCC, which means the following things are true about my program:
It's a very small C program in a single file called prog.c
I won't post it here, because it won't help (and would probably render the contest entry invalid)
It compiles cleanly under gcc using "cc -o prog prog.c -Wall"
Despite (or, more accurately, because of) the fact it contains a bunch of really bizarre uses of C, it has been constructed extremely carefully. I don't know of any part of it which is careless with memory (which is not to say that there can't possibly be bugs, just that if there are they're not likely to be obvious ones)
I'm primarily a Windows user, but several years ago I successfully compiled and ran it on several windows machines, a couple of Macs and a Linux box, with no problems. The code hasn't changed since then, but I no longer have access to those machines.
I don't have a Linux machine to re-test on, but as one final test, I tried compiling and running it on a MacBook Pro - Mac OSX 10.6.7, Xcode 4.2 (i.e. GCC 4.2.1). Again, it compiles cleanly from the command line. It seems that on a Mac typing "prog" won't make the compiled program run, but "open prog" seems to. Nothing happens for about 10 seconds (my program takes about a minute to run when it's successful), but then it just says "Segmentation fault", and ends.
Here is what I've tried, to track down the problem, using answers mostly gleaned from this useful StackOverflow thread:
On Windows, peppered the code with _ASSERTE(_CrtCheckMemory()); - The code ran dog-slow, but ran successfully. None of the asserts fired (they do when I deliberately add horrible code to ensure that _CrtCheckMemory and _ASSERTE are working as expected, but not otherwise)
On the Mac, I tried Mudflap. I tried to build the code using variations of "g++ -fmudflap -fstack-protector-all -lmudflap -Wall -o prog prog.c", which just produces the error "cc1plus: error: mf-runtime.h: No such file or directory". Googling the matter didn't bring up anything conclusive, but there does seem to be a feeling that Mudflap just doesn't work on Macs.
Also on the Mac, I tried Valgrind. I installed and built it, and built my code using "cc -o prog -g -O0 prog.c". Running Valgrind with the command "valgrind --leak-check=yes prog" produces the error "valgrind: prog: command not found". Remembering you have you "open" an exectable on a Mac I tried "valgrind --leak-check=yes open prog", which appears to run the program, and also runs Valgrind, which finds no problems. However, Valgrind is failing to find problems for me even when I run it with programs which are designed specifically to make it trigger error messages. I this also broken on Macs?
I tried running the program in Xcode, with all the Diagnostics checkboxes ticked in the Product->Edit Scheme... menu, and with a symbolic breakpoint set in malloc_error_break. The breakpoint doesn't get hit, the code stops with a callstack containing one thing ("dlopen"), and the only thing of note that shows up in the output window is the following:
Warning: Unable to restore previously selected frame.
No memory available to program now: unsafe to call malloc
I'm out of ideas. I'm trying to get Cygwin set up (it's taking hours though) to see if any of the tools will work that way, but if that fails then I'm at a loss. Surely there must be SOME tools which are capable of tracking down the causes of Segmentation faults on a Mac?
For the more modern lldb flavor
$ lldb --file /path/to/program
...
(lldb) r
Process 89510 launched
...
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x726f00)
* frame #0: 0x00007fff73856e52 libsystem_platform.dylib`_platform_strlen + 18
...
Have you compiled with -g and run it inside gdb? Once the app crashes, you can get a backtrace with bt that should show you where the crash occurs
In many cases, macOS stores the recent program crash logs under ~/Library/Logs/DiagnosticReports/ folder.
Usually I will try the following steps when doing troubleshooting on macOS:
Clean the existing crash logs under the ~/Library/Logs/DiagnosticReports/
Run the program again to reproduce the issue
Wait for a few seconds, the crash log will appear under the folder. The crash log is named like {your_program}_{crashing_date}_{id}_{your_host}.crash
Open the crash log with your text editor, search for the keyword Crashed to locate the thread causing the crash. It will show you the stack trace during crash, and in many cases, the exact line of source code causing the crash will be recorded as well.
Some links:
[1] https://mac-optimization.bestreviews.net/analyze-mac-crash-reports/
I am running a C program in NetBeans (cygwin on windows). Generally for all C programs I have run in the past, while debugging, it stops and shows the line number of segmentation fault. But for this particular program, it does not show the line number and just stops and in the output tab, it shows prog stopped by SIGSEGV. I have tried conditional breakpoint, but it is not stopping. What could be the other conditions for error?
If u want have a look at my program, here it is.http://codepad.org/cujYTIeg
and the in.txt file from where it reads the input. http://codepad.org/vNySA6uh
Did you run the program in debug mode with debugging information enabled?
Try to set a normal breakpoint in your Appliocation. Does it stop there?