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.
Related
First of all I'm at the first year of computer science so I'm a beginner in programming yet, then forgive me for my lack of knowledge. Well, my problem basically is an error that is shown in the screen everytime when I try to run(by the way I'm using Sublime Text) a program in C. In this case was a simple code:
#include <stdio.h>
int main() {
//print the heading of the game
printf("*****************************************\n");
printf("* Wellcome to the our guessing game *\n");
printf("*****************************************\n");
int secretnumber = 42;
int guess;
printf("What is your guess?");
scanf("%d", &guess);
printf("Your guess was %d \n", guess);
}
OUTPUT:
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: cannot open output file Olamundo.exe: Permission denied
collect2.exe: error: ld returned 1 exit status
[Finished in 0.3s]
You know, i tried some solutions like move the folder where the executable lies and place it in the root(in my case Mateus(C:)), give all the permissions to the folder, turn off the antivirus(in my case i just using the Windows defender), finish the task using the the Task manager but nothing worked. Please, help me i really don't know what else i can do.
Overall, your problem is that you're trying to run a program that is interactive from within Sublime; it doesn't support that. Sublime captures output your program sends to stdout and stderr and displays it in the output panel, but it does't connect the panel to stdin.
So, the scenario you're encountering works like this:
You run your program, which is interactive (in your case it prompts for input via scanf(), and it launches and prompts you for input
You try to enter input, but nothing happens because stdin isn't connected.
You try to run your program again (or modify it and build it again thinking you might have an issue).
The version you previously tried to run is still running in the background waiting for input you can't provide, and windows locks executable files while the program is running. So, when the linker (collect2) tries to link the executable during the build, it can't because the file is locked, hence the permission error.
You can clear the error by killing the program running in the background, which you can do via the Tools > Cancel Build if you do it before this error occurs; if you've already seen the error this likely won't work because this only cancels the most recent build, which would be the one where the error occurred.
The other thing you can do is use something external to kill it; the task manager on windows, kill from a terminal on Linux/OSX, etc. You'll need to do it this way if you're already seeing the error.
Note however that this doesn't solve your underlying problem because you're still trying to run an interactive program. In order to do that from within Sublime you need to create a custom sublime-build that allows for this. Generally you'd either have it spawn an external terminal and run the program in there, or use a package like Terminus if you want to keep it internal.
In order to set this up, you need to be familiar with the sequence of commands that are needed to compile, link and run a program in one command, which you can get by checking what the build system you're currently using is (assuming you didn't create it yourself).
This video on buffering and interactive builds in Sublime (disclaimer, I'm the author) has information and examples of how Terminus can be used for something like this if you'd like more information.
If I create a new C11 application in Netbeans (with auto-generated makefile), add a dummy function to its main.c file that just returns 0, add a test to the function, and run the test via Netbeans from the test folder, I get the following error:
make: *** [nbproject/Makefile-impl.mk:73: .test-impl] Broken pipe
However, when I debug the test, it works properly. I get varying results when testing the whole project-- sometimes the output ends with the following message:
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
And sometimes I get the same error. Regardless the actual test results don't get output. Although if I close Netbeans and reopen, the first time I try to test the project the results are displayed correctly, although not any of the subsequent tries.
Any idea what this could be?
This is using CUnit 2.1.3-1, make 4.2.1-2, and gdb 7.12.1-2, all in cygwin 2.10.0 running on Windows 10.
Here's lines 71-73 of the makefile it's referring to, if that helps:
.test-impl: .build-tests-impl .test-pre
##echo "=> Running $#... Configuration=$(CONF)"
"${MAKE}" -f nbproject/Makefile-${CONF}.mk SUBPROJECTS=${SUBPROJECTS} .test-conf
Of course I can provide more of that file if needed, although you should get the same one if you reproduce the steps that led me to the error.
I wrote a code in C and it executed perfectly but at the end I got a line saying "Program ended with exit code: 0". What does this line signify and how do I get rid of this?
What it is?
an exit code of 0 indicates no error. If a program wants to
indicate there was something wrong when it exited it will exit with
a non-zero value.
How to get rid of it?
Do not use the IDE for program execution. – as BLUEPIXY said.
Basically what it means is that the program ran without any error. A 0 usually says that the program executed properly. Any nonzero number denotes some problem. Use text editors such as emacs or vim etc. and compile and execute your program.
The message doesn't come from your program itself, but from the IDE (e.g. Visual Studio) that launches the program. Try launching it from the command-line or by double-clicking the .exe file.
The meaning of "exit code 0" is usually: Everything went fine, the program exited successfully. Other exit codes usually stand for aborts because of errors and the actual number gives a hint about the type of error that occurred.
Greeting everyone on stackoverflow!
I am trying to add fpirntf() to XNU kernel tcp_xxx.c file, so when TCP moves it can print parameters to a file, for better understanding how TCP works, but fatal error occurs like follows:
$ sudo make ARCH_CONFIGS=X86_64 KERNEL_CONFIGS=DEBUG
CC tcp_output.o
/Users/wangweikai/Desktop/xnubuilder/xnu-2422.90.20/bsd/netinet/tcp_output.c:135:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
make[7]: *** [tcp_output.o] Error 1
make[6]: *** [build_all] Error 2
make[5]: *** [do_all] Error 2
make[4]: *** [build_all] Error 2
make[3]: *** [build_all_recurse_into_conf] Error 2
make[2]: *** [build_all_recurse_into_bsd] Error 2
make[1]: *** [build_all_bootstrap_DEBUG^X86_64^NONE] Error 2
make: *** [all] Error 2
It looks there is no stdio.h in xnu source code, to solve this I re-installed xcode 5.0.2(only this works with xnu-2422) and outputs mach_kernel able to boot; I tried install command line tools by "xcode-select --install" in terminal, but not working neither.
BTW if I add printf() without #include it gives no error, it looks print function is defined by file with name other than stdio.h.
Since my point is to log how TCP parameters(such as congestion window size and next sequence number and so on)changes in a file, so if there is any way can do this please also tell me, I am total new to xnu and C programming.
Best regards.
Standard I/O (i.e, stdio) is not available in the kernel. To output debugging information from the kernel, call printf(); its output will be visible in the kernel log. Writing data to files directly from the kernel is complicated, and is rarely advisable. (In this case, it may in fact lead to hard lockups, e.g, if the file being written to is on a network volume!)
If you are new to C programming, this is not a good first project. Kernel development is difficult, unforgiving stuff, particularly for the XNU kernel; errors will often cause your computer to crash, potentially losing data, and debugging services are often not available. If you have your heart set on examining an OS kernel, though, the Linux kernel is much easier to work with — it can be easily booted and debugged in a virtual machine, and is far better documented.
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/