When running gcc adventure.c -o adventure followed by adventure in a linux (Ubuntu) terminal will compile it for me, and execute it. When an error occurs (e.g. segmentation fault) during runtime it will report it in the terminal output.
In windows however a runtime error will only pop up a "adventure.c" has stopped working dialog box, and nothing is written to the output of the cmd.exe screen.
Is there some way that I can also get a reported error on Windows when one occurs?
Under Windows, you define the subsystem for which you build an executable (ref : /SUBSYSTEM (Specify Subsystem). The two more commons subsystems are CONSOLE for command line applications and WINDOWS for GUI ones.
As explained in referenced page, the subsystem is normally automatically set to CONSOLEby the presence of a standard C main function. Normally, the errors related to a CONSOLE application are displayed in the console attached to the application, and the errors related to a WINDOWS application open a message box.
But I do not know exactly what exists in your adventure version (many exists around ...) - Sniff, I was younger when I played adventure :-) . You should try to generate a minimal console program that SIGSGV (easy in C ..) and verify where the error is displayed.
Edit per comment :
Well after Andrew Medico comment (thanks to him), I did the test and ... he is right :-( ... even a console progam opens the message box by default and does not write anything. Sad ...
So you will have to use Microsoft structured exception handling to achieve what you want, but you need to slightly modify source code that way :
original source :
#include ...
...
int main(...) {
...
}
modified source
#include ...
#include <excpt.h>
#include <windows.h>
...
int real_main(...) {
...
}
int filter(DWORD code, LPEXCEPTION_POINTERS info) {
fprintf(stderr, "Fatal error %x at %x\n", code,
info->ExceptionRecord->ExceptionAddress);
return EXCEPTION_EXECUTE_HANDLER;
}
int main(int argc, char *argv[]){
int cr;
__try {
cr = real_main(...);
}
__except(filter(exception_code(), exception_info())) {
cr = 1;
}
return cr;
}
All that wraps the original code with a structured exception handler, that catches any fatal error and simply writes the code of the error and the address where the error occurs. As the error has been caught, Windows no longer opens the message box (except under debugger). Normally it would be better to use FormatMessage do display the error text, but I could not use it whatever I tried.
A cleaner way would be to use a modified crt0, but I do not like to touch to such a thing ...
Related
I'm trying to run a simple C Program - Hello World on VSC on my mac.
It throws up this error everytime on the output screen, please understand that I'm new to coding and well uh that's that.
Here's the screenshot :
The error
#include <stdio.h>
int main()
{
printf("%s", "Hello World");
return 0;
}
Output : zsh: parse error near `&&'
Your source code itself is correct. Assuming that is the only source code in your current project, The problem either lies with your non-portable filename, or with a misconfigured or corrupted compiler. Change your filename to something that describes the contained source code. A filename like #include <stdio.h> doesn't just make debugging difficult, but is not even allowed in some operating systems. While it does appear to be technically supported in your implementation, it could still be causing zsh to behave improperly.
Upon deciding to write a simple "Hello World!" program in EDK2,
I stumbled upon the following problem:
As I am using a serial connection for debugging, the output of the debug functions like DebugPrint successfully get redirected to my serial terminal (PuTTY in this case), well sort of.
After compiling an executing the following program inside an UEFI shell, I simply get
an empty line as a result.
But after executing the same binary again, the line gets successfully printed in all it's beauty.
This is the source code of the program i ran:
#include <Uefi.h>
#include <Library/DebugLib.h>
EFI_STATUS
efi_main(EFI_HANDLE ImageHandle,
EFI_SYSTEM_TABLE* SystemTable
)
{
DebugPrint(DEBUG_INFO, "Hello World!\n");
return EFI_SUCCESS;
}
Serial output:
Note: I linked my program against IoLib, SerialPortLib and DebugLib
What could be causing this issue?
After a lot of fiddling around I realised, that I manually specified the entry point to my main-function (efi_main), which should instead point to _ModuleEntryPoint when using the UefiDriverEntryPoint library from EDK2.
This solved my problem instantly :)
I maintain a command line utility that generates binary data. Data can be redirected towards stdout when requested.
This is valid when stdout is redirected to a pipe or a file,
but less so when stdout is a console, as it would garbage the console.
In order to protect users against such mistake, the program must detect if stdout is a console or not, and bail out when it is.
Now, this is nothing new, and a quick look over Internet will find multiple solutions. The main drawback is that there is no "universal" method, and Visual Studio requires its own flavor.
The console detector I'm using for Visual has a flaw : it doesn't detect that stdout is a console when the console is provided by mingw, which I believe means that it is mintty.
Here is the relevant code section :
#if defined(WIN32) || defined(_WIN32)
# include <io.h> /* _isatty */
# include <windows.h> /* DeviceIoControl, HANDLE, FSCTL_SET_SPARSE */
# include <stdio.h> /* FILE */
static __inline int IS_CONSOLE(FILE* stdStream) {
DWORD dummy;
return _isatty(_fileno(stdStream)) &&
GetConsoleMode((HANDLE)_get_osfhandle(_fileno(stdStream)), &dummy);
}
#endif
Note that the console detector works fine with the built-in Windows console (conhost.exe). It also works fine when the binary is compiled by mingw64. So the issue is mostly "compiled with Visual + console is mintty".
I've been looking around for some potential backup solutions, and found multiple variants of console detector for Visual, using different logics. But none of them would identify mintty as a console, they all fail.
I'm wondering if it is a problem with mintty, though I would anticipate that if it is, more applications would be impacted. Yet, searching for such issue over Internet yields relatively little complaints, and no solution.
Is it a known issue ?
Is there a known solution ?
mintty is a terminal emulator and does not present a console to a running application. When I need to run a true console program I've got to use winpty. For example winpty powershell will allow powershell to run correctly within mintty.
It is a known issue that several applications like git works around. This is what I also found.
https://github.com/fusesource/jansi-native/issues/11.
https://github.com/fusesource/jansi-native/commit/461068c67a38647d2890e96250636fc0117074f5
So apparently you should also check if you are connected to a pipe with the following name:
/*
* Check if this could be a MSYS2 pty pipe ('msys-XXXX-ptyN-XX')
* or a cygwin pty pipe ('cygwin-XXXX-ptyN-XX')
*/
I followed the instructions in this video:(See Docs)
What happened is that I created a very basic program in C, here is the code:
#include <stdio.h>
int main()
{
printf("Hey Buddy!\n");
return 0;
}
I compiled it using Mingw and an .exe file was created. Here the problem begins...
When simply opening the file in windows, a cmd window that says "Hey Buddy!" opens and closes immediately.
When trying to run the .exe file using the command line, the same thing happens, but the command line window then becomes stuck and it is impossible to close it - only shutting off the computer can do it.
Your help would be very appreciated, and I am sorry if I am doing something dumb and not realizing it:)
Your program is fine. The main declaration is wrong. It should be
int main(void)
but the declaration in your question won't cause any problems. I'm just telling you this to set you off on the right path.
Of course when you double click on the executable, then a new console window appears and immediately disappears. The program prints a single line of text and returns immediately. That behaviour is as expected.
The problem with the console window that cannot be closed is not down to an error in your code, at least the code that is shown in the question cannot explain that. That is presumably an environmental problem with your machine and/or compiler installation. Or perhaps you just have not yet worked out how to close a console window.
I am packaging a program on Windows that expects to be able to externally call OpenSSH. So, I need to package ssh.exe with it and I need to force ssh.exe to always be called with a custom command line parameter (specifically -F to specify a config file it should use). There is no way to force the calling program to do this, and there are no simple ways to do this otherwise in Windows (that I can think of anyway - symlinks or cmd scripts won't work) so I was just going to write a simple wrapper in C to do it.
This is the code I put together:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int ret;
char **newv = malloc((argc + 2) * sizeof(*newv));
memmove(newv, argv, sizeof(*newv) * argc);
newv[argc] = "-F ssh.conf";
newv[argc+1] = 0;
ret = execv("ssh.orig.exe", newv);
printf("execv failed with return value of %i", ret);
return ret;
}
I then compile this code using GCC 4.6.3 in Cygwin and it runs without error; however, there is a strange behavior with regards to input and output. When you go to type at the console (confirming the authenticity of the host and entering in a password, etc) only part of the input appears on the console. For example, if I type in the word 'yes' and press enter, only the 'e' will appear on the console and SSH will display an error about needing to type 'yes' or 'no'. Doing this from the Windows command prompt will result in your input going back to the command propmt, so when you type 'yes' and press enter, you get the ''yes' is not recognized as an internal or external command...' message as if the input were being typed at the command prompt. Eventually SSH will time out after that.
So, I'm obviously missing something here, and I'm assuming it has something to do with the way execv works (at least the POSIX Cygwin version of it).
Is there something I'm missing here or are there any alternatives? I was wondering if maybe I need to fork it and redirect the I/O to the fork (although fork() doesn't seem to work - but there are other issues there on Windows). I tried using _execv from process.h but I was having issues getting the code right for that (also could have been related to trying to use gcc).
It's also possible that there may be a non-programming way to do this that I haven't thought of, but all of the possibilities I've tried don't seem to work.
Thoughts?
I ended up finding a solution to this problem. I'm sure there were other ways to do this, but this seems to fix the issue and works well. I've replaced the execv line with the following code:
ret = spawnv(P_WAIT, "ssh.orig.exe", newv);
You have to use 'P_WAIT' otherwise the parent process completes and exits and you still have the same problem as before. This causes the parent process to wait, but still transfers input and output to the child process.