Sign in to follow this  

fprintf causes seg fault??

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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:


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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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);

Share this post


Link to post
Share on other sites
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.]

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
odds are it's not the fprintf that's causing the error.

can you reduce this to some example code that causes the error?

Does an fprintf at the beginning of main() cause the error? how about the very end?

Share this post


Link to post
Share on other sites
yes
putting fprintf at the start of main still causes the problem

rather than seg faulting tho, i get 'this program has cause a problem and needs to close' message from microsoft

mainly because at the begginging of main SDL hasnt been started up, so windows catches it instead

still a seg fault tho

Share this post


Link to post
Share on other sites
OK

my SDL expert friend found it

i dont completly understand it
but it seems that i needed to setup my project to do something about 'multithreaded dll' since SDL is multithreaded



thanks for everyone offering suggestions



pointy clicky gui goodness
i really hate not knowing whats really going on when i mess with these msvc menus and buttons......

Share this post


Link to post
Share on other sites

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this