User forums > Using Code::Blocks
HELP! Codeblocks went nuts ? Missing compiler
Elena:
HELP! IT HAPPENED AGAIN ! Please read carefully, perhaps this time I can be more accurate about the details involved.
I had CB opened with a project but when all happened it was idle, I was brainstorming on my physical notes.
When I touched my mouse to resume my works I realized that it did not move. Everything was frozen including the keyboard. No input. HD leds were off, everything silent. I checked to access the workstation involved from another PC in my network and it was still operational, I could browse a remote dir, copy files etc. But the input was frozen. And the red light of the optical mouse turned off.
Since the HD led was inactive I felt confortable enough to press the reset button to reboot - I really couldn't do anything else.
After reboot everything was apparently normal. No errors or crashes were recorded by Windows event logger. I checked all my partitions with Scan Disk and there were no errors.
I opened the codeblocks project which was opened during the crash and I realized that in the Build Options the default compiler was no longer my MinGW64 but the generic GNU GCC.
I didn't touch anything. I exited CB and tried loading ANOTHER PROJECT, one which was ok this morning and was NOT opened when CB crashed. Tada. I opened the Build Options window and I received that feared requester:
Compiler selection
The defined compiler cannot be locaed (ID:mingw_64) [note: its name was MinGW64, I never entered "mingw_64" anywhere]
Please choose the compiler you want to use instead and click OK
....
At this point I closed the project without touching or saving anything, I RESTORED the whole User/Elena/AppData/Roaming/CodeBlocks DIR which I had backed up, I reopened the project and STILL THE ERROR REQUESTER !
So it is DEFINITELY *NOT* ABOUT ANY CORRUPTION IN THE CODEBLOCKS/ Config folder, and *NOT* ABOUT THE PROJECT FILE, it is something elsewhere which got corrupted !!!! But what ? Where ? Perhaps something in the Registry ??
Where does CB store its settings otherwise ??
My Mingw64 installation dir on D: is pristine.
My setup has always been perfect, never gave me one problem before.
I appreciate any feedback, thanks.
LATER ADDITION - Please read carefully, maybe this contains some useful hints to help you track the bug ?
Referring to the second project I mentiond, the one which was not active during the crash and which I had been working on this morning, i.e many hours before the accident, and which now after the crash caused the error requester I reported, here is what I discovered...
I was smart enough and made a copy of it.
Then I opened it, opened the Build Options, the error requester about the missing compiler showed up, I seconded the request of picking a new compiler in place of mingw_64,and I effectively could choose my MinGW64 (was in the list).
After that everything was apparently fine again and I SAVED THE PROJECT, so I had now two copies of the same project to compare, the original one causing the error requester, and the fixed one.
I checked both .cbp xml files with wordpad.
Here is the ONLY DIFFERENCE:
Original .cbp, line 8 -> <Option compiler="mingw_64" />
Fixed .cbp, line 8 -> <Option compiler="mingw_x64 /> !!!!!
So... as a premise, I NEVER renamed my compiler after the initial setup. I always named it "MinGW64" in the compiler global settings, and nothing else than the toolchain dir was set there.
For some reason, BEFORE the crash all my project files referred to it as "mingw_64"; for some reason after the crash CB changed the way it is internally named and started referring to it as "mingw_x64", with the "x", so that after the crash all the previous projects referring to it as "mingw_64" could no longer recognize it !
But now I wonder, WHERE is this reference name stored (mingw_64 or mingw_x64) , if it is NOT in any file in Codeblocks config folder ? Is it in the registry ? A search with regedit gave no results...
Actually default.config seem to define the compilers and their names, and it always uses the "x". But why then all my project files BEFORE the crash referred to the compiler id WITHOUT the x, and now they need it instead ??
Almost getting insane.... :o
blauzahn:
Hello,
if the way the name of the default compiler is assembled on that configuration (win/mingw) is somehow inconsistent in CB, there is a workaround. In options|compiler please make a copy of your compiler settings and rename it eg. mymingw. I would avoid any special character in that name. Then, in your project(s), please select that newly created compiler settings so that it does not depend on the default compiler's name anymore. If you port your code to another computer with codeblocks, that also has to have a compiler setting with that name.
I hope this does help you to avoid your problem and stay sane.
Please note, that I use CB under Linux. Therefore, I cannot help you with issues specific to win/mingw.
Have a nice day.
Elena:
Blauzahn, actually when I created my compiler settings I had indeed cloned an existing one, the gnu gcc (there is no mingw default setting here), and I named it MinGW64. I really didn't change anything since, just after that strange crash CB started referencing the compiler setting with an "x" as I said when it didn't do that before... that's very puzzling!
BlueHazzard:
Thank you for your reports.
--- Quote --- [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!]
--- End quote ---
This is an automatic answer, entered by the forum software, because there was a time, when we had dozens of questions with exact this error message. And this was some automated way to answer this questions :)
--- Quote --- I had to remove by hand three xml
--- End quote ---
Where this tags added by codeblocks? If something like this happens again, please zip the file and add it here if possible
--- Quote --- The defined compiler cannot be locaed (ID:mingw_64) [note: its name was MinGW64, I never entered "mingw_64" anywhere]
--- End quote ---
Codeblocks generates an internal id and uses this id for project and config files. This is not in direct relation to the name you entered, but in relation to the compiler type you copied (in your case mingw).
--- Quote ---When I touched my mouse to resume my works I realized that it did not move
--- End quote ---
Do you think this crash was coming from codeblocks? I never had something like that...
--- Quote ---I opened the codeblocks project which was opened during the crash and I realized that in the Build Options the default compiler was no longer my MinGW64 but the generic GNU GCC.
--- End quote ---
If the config file is corrupt this seems to be expected... Compiler id of the project is not present in the config file so it falls back to some default compiler...
--- Quote ---Tada. I opened the Build Options window and I received that feared requester:
--- End quote ---
Again, expected on a corrupt config file
--- Quote --- I RESTORED the whole User/Elena/AppData/Roaming/CodeBlocks DIR which I had backed up,
--- End quote ---
This is unfortunate... It would have helped us a lot if we could have examined this config folder,
--- Quote --- it is something elsewhere which got corrupted !!!! But what ? Where ? Perhaps something in the Registry ??
Where does CB store its settings otherwise ??
--- End quote ---
As far as i know, codeblocks stores configuration settings only in the config file. This is found in the AppData/Roaming/Codeblocks folder or in the codeblocks installation folder
The configuration file has the name of your codeblocks profile. You can start codeblocks via command line with different profiles and codeblocks will use the configuration file with the profile name.
--- Quote ---Original .cbp, line 8 -> <Option compiler="mingw_64" />
Fixed .cbp, line 8 -> <Option compiler="mingw_x64 />
--- End quote ---
This is puzzeling... i am reading the config code right now... quite complex... i will try to find the reason behind this...
Ultimately i still think one config file is corrput (the file in the App data folder, or the file near the codeblocks.exe)
Elena:
Hi, thanks for your support,
well at the time of crash I had Synthedit idle in background so I can't be 100% sure on which one froze the system, as I said Windows logger did not record anything so I can't say for sure...
Next time I will store everything so you can examine the config files. The truth is, one is never prepared enough when such accidents happen...
In the meanwhile I have installed the last nightly build, so if that happens again we at least can be 100% sure it is not something which maybe has been fixed in the meanwhile...
Navigation
[0] Message Index
[*] Previous page
Go to full version