Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: johny5 on July 17, 2005, 04:21:41 pm

Title: I found a bug, but i dont know where this bug comes from
Post by: johny5 on July 17, 2005, 04:21:41 pm

When i compile my program normally,  it works 100%. When i check "optimize fully" or "optimize even more" in the build options the program always freezes when i use a certain function in my program.  I cant debug it since debugging doesnt work with optimalisation.

How is this possible, and what can i do to fix this problem?

Title: I found a bug, but i dont know where this bug comes from
Post by: David Perfors on July 17, 2005, 06:23:15 pm

I don't know much of optimizing, but I think the program is getting overoptimized. Try to "optimize more". Perhaps that will help...

Title: I found a bug, but i dont know where this bug comes from
Post by: Anonymous on July 17, 2005, 06:46:39 pm

I have tired a couple of things now, and i noticed that when i turn off optimizing it works 100%, when i turn on the lower optimalisation, it freezes, and @ high optimalisation it crashes :(.

Has this something to do with importing functions from dll's

Code

.....
GETMODULEFILENAMEEX GetModuleFileNameExDLL = (GETMODULEFILENAMEEX) GetProcAddress(psapiLib, "GetModuleFileNameExA");
....
GetModuleFileNameExDLL(hMainProc,mod,fileName,sizeFileName); // <--- this is where somethings goes wrong.

I dont even know if this is a problem of c::b (not likely IMO), mingw, or my own code  :cry:. Any help on this is really appreciated.

Title: I found a bug, but i dont know where this bug comes from
Post by: David Perfors on July 17, 2005, 07:24:47 pm

I don't think C::B has something to do with this, so mingw and your own code are left... Perhaps you should try to search for such bugs at the mingw website, if it is not a problem there, it is your own code :(

Title: I found a bug, but i dont know where this bug comes from
Post by: thomas on July 17, 2005, 10:40:06 pm

I had a similar problem in conjunction with inline assembly once.
-O3 would make my application segfault while -O2 would not, and I did not have a clue why. That is surely a compiler-related issue, though, definitely has nothing to do with code::blocks.
This kind of bug is very annoying because you really get no useful hints. Without a starting point, no one will be able to help you either.

Try this:
go to http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html#Optimize-Options

There, you find what exactly is turned on by -O, -O2, and -O3.
Now, change to -O or -O2 (whichever still works for you) and add the other options by hand. So you get the very same thing, it still crashes.
Then, take away those extra switches one by one. At some point, it will work. Now you do not have solved the problem, but at least you have a starting point (or your can choose to just leave off one switch).

Title: I found a bug, but i dont know where this bug comes from
Post by: kagerato on July 18, 2005, 12:54:39 am

Of the three flags that -O3 includes which -O2 does not, fweb is the likely culprit for problems.  I've heard several developers on completely unrelated projects mention that it broke code which otherwise compiled and ran fine.

Try -fno-web to disable it.

There are some disputes as to whether -finline-functions actually improves execution speed in all the situations where it's applied, but I haven't heard any accounts of it generating broken instructions.

Note that this information is relevant only to GCC 3.  GCC 4 is a completely different ballgame; for example, multiple gentoo users have reported serious problems using -O3 even on projects which are widely regarded stable.

Title: I found a bug, but i dont know where this bug comes from
Post by: thomas on July 18, 2005, 01:47:51 pm

Funny you should say that, -fno-web and -finline-functions happen to be the exact things that I had to turn off.
(-finline-functions did not actually break code, but gave a link error).

Title: I found a bug, but i dont know where this bug comes from
Post by: Anonymous on July 21, 2005, 09:54:06 pm

Sorry for not posting for a while, but often i cant reach the site. Anyway i found the solution to my problem. It was related to the calling conventions of the dll. The correct code is :

Code

typedef DWORD (WINAPI *GETMODULEFILENAMEEX)(HANDLE, HMODULE, LPTSTR, DWORD);

i forgot the WINAPI so the stack was totaly screwed up after calling the function.

So there was no bug whatsoever. It was just me being stupid :). Am i the only one who has never ever heard of calling conventions ?!