fprintf causes seg fault??
Author
Sorry to ask such a silly question, but really, google searching does not help, the terms are too general, i need a human's advice
Im using msvc, but really dont know enough about how to set projects up properly,so i suspect this might be the root of the problem
fprintf causes a segmentation fault (at least thats what SDL says)(im using SDL)
even when i try printing fprintf(stdout,"hi");
i really have no idea why this coudl be
i did tests and im almost entirely certan it is not something else in my program thats causing the seg fault
i even setup one of my keys to trigger fprintf
program runs just fine, then to test i press the key
then it seg faults
im pretty sure that lowers it down to the fprintf causing it....
so, if anyone has any ideas on obvious 'newbie-ish' things i might be doing to cause this (im hopign youve heard this problem before).... please give your suggestions
Haven't seen it before specifically, but does it also happen when you simply printf ("hi");?
Is stdout a valid file (or pipe) handle? Perhaps something has altered it from the standard setting.
To kill two birds with one stone, try the following to find out:
If the write to the file succeeds, you can be certain fprintf is not borked. If the value it writes is 0, stdout has been set to NULL for some strange reason.
Is stdout a valid file (or pipe) handle? Perhaps something has altered it from the standard setting.
To kill two birds with one stone, try the following to find out:
FILE *f = fopen ("test.log", "wt");fprintf (f, "%d\n", stdout);fclose (f);If the write to the file succeeds, you can be certain fprintf is not borked. If the value it writes is 0, stdout has been set to NULL for some strange reason.
Author
i dont know the right terminiology
but stdout is what i print to if i want my text to appear on the debug/command line window in the background
i think stdout is defined someplce in stdio.h
i guess it might be windows specific.... dunno im just used to always using it....
fprintf(stderr,"hi") also seg faults btw..
OK i just followed your suggestion more or less
and did
FILE *f = fopen ("test.log", "wt");
fprintf (f, "hi");
fclose (f);
to print to a file instead of the stdout output stream
no seg fault
and afterwards the file had the output
this would seem to indicate that somehow the values for stdout and stderr are pointing at the wrong places
i 'think' that theyre defined in stdio.h or stdlib.h
but am no sure
so it seems your advice has been partially helpful
it provides another clue
does anyone know more?
but stdout is what i print to if i want my text to appear on the debug/command line window in the background
i think stdout is defined someplce in stdio.h
i guess it might be windows specific.... dunno im just used to always using it....
fprintf(stderr,"hi") also seg faults btw..
OK i just followed your suggestion more or less
and did
FILE *f = fopen ("test.log", "wt");
fprintf (f, "hi");
fclose (f);
to print to a file instead of the stdout output stream
no seg fault
and afterwards the file had the output
this would seem to indicate that somehow the values for stdout and stderr are pointing at the wrong places
i 'think' that theyre defined in stdio.h or stdlib.h
but am no sure
so it seems your advice has been partially helpful
it provides another clue
does anyone know more?
my documentation on stdout says that it can be redirected
ensure that you are not assigning stdout anywhere?
ensure that you are not assigning stdout anywhere?
Quote:Original post by NorthWoodsman
fprintf prints to a FILE, not a stream like stdout or stderr. I could be wrong though
stdout and stderr *are* FILEs
you're thinking of std::cout and std::cerr.
Did you also try my other recommendation?
printf ("hi"); should basically do the same as fprintf (stdout, "hi");. If that crashes too, then something is redirecting stdout (and stderr) and doing a poor job of it.
Oh, that reminds me, SDL does redirect stdout to a file called stdout.txt. Make sure there is no file by that name in use or otherwise read-only. You can prevent this by #defining KEEP_STD_STDIO (preferably in the project settings).
You can always restore the original stdout by using freopen ("CON", "w", stdout);
printf ("hi"); should basically do the same as fprintf (stdout, "hi");. If that crashes too, then something is redirecting stdout (and stderr) and doing a poor job of it.
Oh, that reminds me, SDL does redirect stdout to a file called stdout.txt. Make sure there is no file by that name in use or otherwise read-only. You can prevent this by #defining KEEP_STD_STDIO (preferably in the project settings).
You can always restore the original stdout by using freopen ("CON", "w", stdout);
Do you have a Win32 Console project or a Windows Application project? The former will properly set up and redirect stdin, stdout, stderr to your console window; the latter doesn't initialize them at all, even when you call AllocConsole. Obviously, the latter would be a good candidate for a segfault when you try to use Standard C Library I/O functions.
[Edit: Nevermind. Obviously, a Windows Application project requires a different entry point. Leaving this here for the odd person who might actually need this information.]
[Edit: Nevermind. Obviously, a Windows Application project requires a different entry point. Leaving this here for the odd person who might actually need this information.]
Quote:Original post by Oluseyi
Do you have a Win32 Console project or a Windows Application project? The former will properly set up and redirect stdin, stdout, stderr to your console window; the latter doesn't initialize them at all, even when you call AllocConsole. Obviously, the latter would be a good candidate for a segfault when you try to use Standard C Library I/O functions.
A Win32App won't segfault if you try to write to stdout/stderr. Things'll just go into the bitbucket. When you AllocConsole, you must redirect them manually. (That makes sense: what if you've already redirected either or both of the output streams. You wouldn't want AllocConsole to redirect them implicitly.)
Author
printf("hi")
seems to work as expected
what could have gone wrong with stdout?
I belive i set this up to be a win32 console project
but i could be wrong.... maybe i messed it up
seems to work as expected
what could have gone wrong with stdout?
I belive i set this up to be a win32 console project
but i could be wrong.... maybe i messed it up
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
