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.
Related
I am using TinyEmbeddedTest and VisualGDB in Visual Studio 2015, and attempting to create a unit test project as part of my solution. My main project builds and runs fine, but the unit test project is getting linker errors and will not build.
The tests are in a source file, ADCTests.cpp, which has
#include “ADC.c”
Which I believe is appropriate for TinyEmbeddedTest.
The file ADC.c contains the following include lines:
#include “ADC.h”
#include “fault.h”
The errors are thrown in ADC.c, on the following statements:
if (status == SUCCESS)
{
Fault_Clear(FAULT_ADC_FAILURE);
rawADCValue = HAL_ADC_GetValue(hADC);
}
else
{
Fault_Set(FAULT_ADC_FAILURE);
rawADCValue = 0u;
}
The errors are:
undefined reference to ‘Fault_Clear’
undefined reference to ‘Fault_Set’
From this I can see that the header file, fault.h, where these functions are declared, is accessible to the toolchain, because otherwise there would be a compilation error, but the source file. fault.c, where these functions are defined, does not seem to be accessible. Both of these files are in the same project.
I do not get these errors when running my main project, only in the unit test project.
I thought that perhaps the answer might lie in the project linker settings, and so I added a line to the Linker->[Additional Inputs] as follows:
C:\Development\myProject\VisualGDB\Debug\Src
I assumed that this would give the linker access to the .o files, created by the compiler. Unfortunately this created a new problem. The build now fails without any error messages. The list of build messages simply says
Build failed: arm-none-eabi-g++.exe exited with code 1 Id returned 1
exit status
and when I look at the log, it says
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe:
cannot find C:/Development/myProject/VisualGDB/Debug/Src: Permission
denied
Interestingly, that last path is a hyperlink, and when I click on it, I get an error dialog box
Failed to open
‘C:\SysGCC\arm-eabi\Development\myProject\VisualGDB\Debug\Src’
This is especially odd, because I know that path does not exist, and that is definitely not the path that I entered in the Linker settings.
Any guidance would be much appreciated.
I'm trying to automatically label my application sign-on line with a build number. This application is a plain vanilla C one without graphic UI; it is intended for command line, therefore it is a "simple" one.
The sign-on id is located in a "template" source file which is customized by CMake with a configure_file() command. Recently, I fancied to include a build number in this sign-on id. Consequently, the customization can no longer be statically done at CMake time, but everytime make is invoked.
To achieve that, there are two possibilities in CMake:
add_custom_target(), but it is triggered even when nothing else changes in the source tree which does not reflect the state of the tree;
add_custom_command(), which can be triggered only when the application (target) needs to be linked again.
I opted for the second solution and did not succeed.
Here is an extract of my CMakeLists.txt, the sign-on id being in file ErrAux.c (template in PROJECT_SOURCE_DIR, configured in PROJECT_BINARY_DIR):
add_executable(anathem ... ${PROJECT_BINARY_DIR}/ErrAux.c ...)
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
This launches script BuildNumber.cmake just before the link step. It computes the next build number and customizes ErrAux.c with configure_file().
It works fine, except ...
It happens late in the make sequence and the update to ErrAux.c goes unnoticed. The sign-on id in the executable contains the previous build number.
Next time I run make, make notices the generated ErrAux.c is younger than its object module and causes it to be compiled again, which in turn causes a link which triggers a build number update. This happens even if no other file has changed and this loop can't be broken. This is clearly shown in the compiling log:
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-45
[ 36%] Built target anathem
The crux seems to be that add_custom_command(TARGET ...) can't specify an output file like add_custom_command(OUTPUT ...) does. But this latter form can't be triggered in PRE_LINK mode.
As a workaround, I forced a compilation to "refresh" the object module with:
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
COMMAND echo "Numbering"
COMMAND echo "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
COMMAND "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
An explicit compilation is forced after sign-on id customization. It mimics what is found in the various Makefile's and my not be safe for production. It's a cheat trick on both CMake and make.
UPDATE: Option -c is required to postpone link step until the final application liniking process.
This addition creates havoc in the link, as shown by the log, where you see a double compilation (the standard make one and the add_custom_command() one):
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-47
Numbering
/usr/bin/cc -DANA_DEBUG=1 -I/home/prog/projects/AnaLLysis/build/AnaThem -I/home/prog/projects/AnaLLysis/AnaThem -g /home/prog/projects/AnaLLysis/build/AnaThem/ErrAux.c
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
AnaThem/CMakeFiles/anathem.dir/build.make:798: recipe for target 'AnaThem/anathem' failed
make[2]: *** [AnaThem/anathem] Error 1
If I force a full recompilation, to make sure all sources are compiled, *main.c* included, I get the same error on `main`.
The only logical explanation is my manual C invocation is faulty and somehow destroys vital information. I checked with *readelf* that `main` is still in the symbol table for *main.c.o* and that it is still taken into account by the link step (from file *link.txt*).
UPDATE: Even with the correct link, I'm still experiencing the infinite loop syndrom. The generated application still has its sign-on id lagging behind the actual build counter.
Can someone give me a clue for the right direction?
FYI I'm quite new to CMake, so I may do things really wrong. Don't hesitate to criticize my mistakes.
The key to the solution is to put the generated module where make expects to find it. CMake organizes the build tree in a non-trivial way.
The shortcomming in my added compilation in add_custom_command() was to believe that by default the binary will be stored in the "usual" CMake locations. Since I forge manually my compiler command, this is not the case.
I found the module in the source directory, which is a consequence of the WORKING_DIRECTORY option, with name ErrAux.o and not ErrAux.c.o.
To obtain the correct behavior, I force an output location with:
-o "${PROJECT_BINARY_DIR}/CMakeFiles/anathem.dir/ErrAux.c.o"
Now, when I run make again, nothing happens since nothing changed.
Side question
To make the solution portable (if needed), are there CMake variables for CMakeFiles and anathem.dir directories? Or in the latter case, for the current target as "anathem" as the target name in add_custom_command()?
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 have a problem with compiling and running C codes in notepad++.
I am using the nppexec plugin and wrote the following in the script section after pressing F6:
C:\MinGW\bin\gcc.exe -g "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
$(CURRENT_DIRECTORY)\$(NAME_PART).exe
After pressing OK, I get the following on the console:
C:\MinGW\bin\gcc.exe -g "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.C" -o "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe"
Process started >>>
<<< Process finished. (Exit code 0)
D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe
Process started >>>
Here, substitution.c is my program to be run. The problem is that the gcc part is working fine but I am not able to execute the program from here as there is no response.
As you see, it just says process started and after that nothing. No response to a key being pressed, it just accepts everything like a text editor.
If I go to the working directory and execute the program from there (double clicking the exe file) then it seems to run perfectly fine. The problem seems to be in my script or the plugin.
Please, can anyone find out what is wrong with my compiling and running script?
In addition to #paxdiablo 's answer, you may also find useful the following NppExec script for single file projects:
npp_save
cd "$(CURRENT_DIRECTORY)"
cmd /c del "$(NAME_PART)".o "$(NAME_PART)".exe *.o
C:\MinGW\bin\gcc.exe -g3 -std=c89 -pedantic -Wall -Wextra -Wno-nonnull "$(NAME_PART)".c -o "$(NAME_PART)".exe
npp_run "$(NAME_PART)".exe
The 1st line saves the document that is currently active inside notepad++.
The 2nd line ensures your current directory is the one of the active document. This let you refraining from using the "$(CURRENT_DIRECTORY)" variable in the rest of the lines.
The 3rd line removes any executables and object-file leftovers from previous successful compilations. Removing the last executable is a nice idea, because if you don't then the last line will cause your .exe produced by the last compilation to be run anyway, even if your current compilation fails. A failed compilation does not produce an .exe, so normally you don't want NppExec to run the previous .exe. Removing the previously produced object-file is optional, but it does ensure that it will not affect fresh compilations (it makes more sense in multi-file projects, as an alternative to the touch command-line tool).
The 4th line compiles the active document. Feel free to modify gcc's options according to your needs. If you add C:\MinGW\bin into the Windows PATH environment variable, and assuming you are using only one gcc installation on your system, then you can skip the absolute path, and write just gcc instead.
The last line executes the produced executable. The npp_run command tells NppExec to launch a new command-prompt window, and run your program in it (unless it is a WIN32 GUI program). I personally find it more convenient compared to the NppExec console embed in notepad++. It looks more natural and it also avoids some I/O redirection problems of the NppExec console.
However, if your program is a console app that does not interact with the user say via a loop, then this approach will cause the launched command-prompt window to close immediately after your program terminates, not giving you the chance to inspect its output. In that case you should have you program waiting for a key to be pressed by the user just before its termination. A quick-and-dirty way is to put a system("pause"); right before your main() function's return and/or exit() statements (it is much better though to write a simple cross-platform function or macro for this).
You may experiment with the above script by typing it in F6's <temporary script> and save it permanently for general use when you are happy with its behavior.
On a side note, you may also find it useful to have a look at this post, where I'm trying to explain how to setup NppExec so it jumps to the appropriate line in the source code, by double-clicking on any error gcc spits in the NppExec console during compilation.
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/