Sign in to follow this  

Mingw32 compiler compiles differently after adding a no-purpose printf

This topic is 406 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

Hello everybody, I have interesting problem with compiler Mingw32 ( :D ).

I make a FPS game, and recently I added doors that open based on player position. There appeared a problem, that the door were always closing and they were opening only when I moved the mouse. First interesting thing about that is that the closing/opening worked allright when I added a printf after the trigger bit determination function. After I commented printf - fucked up. I tried this repeatedly and it was giving me the steady output. With printf - works. Without printf - doesnt work. I replaced printf with Sleep(1). Helped too.

Every random change causes this to work. Commenting thread of server - works. Commenting on some fprintf in the mouse movement function - works. They are all totally random things, which has nothing to do with trigger bits. There is no limit exceed in arrays. There is no %s in fprintf I was commenting, so no, thats not the problem.

Also, the problem is hardware specific. On Asus X751L (RAM extended to 12GB, SSD 120GB, otherwise no changes) it does the problem. On different comp (Asus too but better, dont know specs now) the same compilation works OK.

I use DevCpp 5.11, which comes with Mingw32 4.9.2. I looked a bit on Internet, but this seems to be the most recent version. I think this is a compiler problem, cause printf definitely shouldnt have affect in the form its used in (no operations inside printf, just displaying stuff), the bug doesnt vary, and also - when I change compiler options for optimalization, the bug changes. I use no mutlithreading except server threads, but I checked them and they have no conflict and all variables separated.

It is the most complicated bug I ever had, cause I cannot use any logging of variables - cause every little change changes the bug itself. All I can do is to shoot the dark. The main file has 20k+ lines, can Mingw handle that or I should divide in into headers for example? Or are there any other limitations of compiler that cause unexpected behavior?

I am in arse from that. Out of ideas. Has somebody encountered similar problem? At least where can I report an error to Mingw devs, if its still being developed?

 

PS: Please, dont suggest me using Visual Studio. With its C99 syntax it doesnt allow me to have variable in array length initialization, which would mean painful complication with conversion of already complicated code and make next stagnation of process with all the setup and stuff.

Share this post


Link to post
Share on other sites

Most likely you are trashing memory or accidentally relying on some sort of undefined behaviour. Even just adding extra code can cause problems like this if it means the layout of functions in memory has changed, and it wouldn't be due to a compiler bug.

 

If I was in your situation, I would enable absolutely all warnings and see if there's anything that needs fixing. I'd be looking especially for anything with function pointers or which passes pointers (or references, if you're using C++) to other functions.

 

I might also consider how the optimisation options are affecting things. If some optimisation settings make it work correctly and some don't, then it's likely that those optimisations are the problem. If necessary, use a #pragma to switch off or change optimisation only around your door code. Certain optimisations hint at certain code problems. You could output the assembly for the relevant functions, see what is different, and work out what is wrong that way.

 

Another thing is to stop debugging with printf and use an actual debugger. Check the values in memory and see what they say. You can set a watch on the specific memory you're interested in and see what changes it.

Share this post


Link to post
Share on other sites

Thank you for replies, but I had undefined state in brush geometry, so it was no bug of compiler. Problém is solved. Anyway I have question for you. Lets say I would want to use debugger (I tried it), but I dont want it to BREAK program on breakpoints and wait for me, but just pass through breakpoints and log data somewhere and continue, is it possible? Imagine that I must have pass through the door in game,  and to do it with debugger I must prepare some constant initial position and rotation of player and forced movement vector, and then click like fucker on debugger to step through frames :D And imagine that debugged bug sometimes happen, sometimes not. So I would think this option must be somewhere. I debugged this one with printfs and fprintfs, there was no other way.

Share this post


Link to post
Share on other sites
Nearly all the modern tools have advanced breakpoints. It can break when a value is equal, or when an expression you provide is true. Memory breakpoints stop when something modifies a spot in memory or when the spot in memory has a particular value.

What you describe can be done with a logger, and you can add the condition in the code with an empty line where you drop the breakpoint. Less elegant, but functional.

Share this post


Link to post
Share on other sites

I use DevCpp 5.11, which comes with Mingw32 4.9.2. I looked a bit on Internet, but this seems to be the most recent version.

You do not need to use the MingW version that is bundled with DevCPP.

Simply get a newer version of MingW (I think gcc-5.3 is current on the official builds) or get MingW-w64 which has at least gcc-6.1 (possibly 6.2 in the mean time, I've not looked for some months).
EDIT: Yep, they're at 6.2 now. https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.2.0/

Share this post


Link to post
Share on other sites

This topic is 406 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