bcc.exe crashes
BlitzMax Forums/BlitzMax Programming/bcc.exe crashes
| ||
| Hi today I did some bugfixes to my project. Linux compiles fine but windows compilation-process now crashes when compiling the "main" project file. All imported ones seem to compile fine, but this one just outputs Compiling:main.bmx Build Error: failed to compile Z:/[path truncated].../source/main.bmx Process complete I had such errors some times in the past, then I just added an empty line to a file (to force recompilation without recompiling everything) and after doing that I had a small chance of getting it compiled without trouble. I had also times with absolutely no compilation issues. My normal "build"-machine is a stripped virtual windows xp - so I just got that error. Building on a "normal XP" I got that Windows-message about an encountered problem with bcc.exe and if I whished to send information to microsoft. Sourcecode of the project is some MegaBytes so I cannot narrow it down to something specific. "Smaller" projects compile fine - even if they import/include some of the projects files (-> test-files for certain functionality tests). The changes since the last windows-build (3 days ago) there mostly cosmetic things (removing "self." if not really needed), changing some globals to fields. No magic involved, just basic "blitzmax language". Ideas how to narrow it down? bye Ron |
| ||
| I had a similar message a while back when compiling a module and after re-installing MINGW the problem went away (I think it was something to do with it being installed in C:\Program files instead of C:\MINGW but I cannot really remember the detail). The only other time I've seen it was when I had very deep path names, or files created in Linux with paths that contain characters invalid within Windows. Have you tried compiling from the command line with various switches to see if you get additional information? Try copying the file locally and see if it compiles there. Might be a permission issue or locked file on the file server, although I would have expected a different error! |
| ||
| I also copied everything to "local"... no success. MinGW - I thought "bcc" is the bmx2asm-compiler so this should not be an issue at all. bye Ron |
| ||
| Today I continued finding the erroneous part. I checked out a prior revision of the sourcecode (which compiled fine - else I would not have been able to provide a new download for early testers). It wasn't compileable too. Ok, so I run "bmk" from the commandline (with -v[erbose] option) so I got the run command: You see: it recognized the framework I use. leaving that "-f brl.glmax2d" (I removed the framework-directive in the code) out, it did way more: Why did the framework "work" for ages ... and now the bcc got some hickups ? Ok...something more odd: I uncommented my previously commented "frameworks brl.glmax2d" - pressed build and it compiled and linked. Now it complained about undefined references like: (code+0x74): undefined reference to `__bb_jpgloader_jpgloader' They are imported by the corresponding helperfiles (basefunctions_images.bmx) which are imported by my "main.bmx" which is imported by "projectname.bmx". Ok... opened the most current revision, commented the framework-command, unchecked "quick build", pressed compile. Now it fails compiling another file (basefunctions_guielements.bmx). The file "basefunctions_guilements.bmx" itself compiles fine (but does noting)... So ... any clues what to do now? I do not really like "bcc" not printing errors - so I do not know why it does not work. Edit: I used framework assistant again (listed some of my imported files 10 times :D, did not mention freetype-import albeit I had to import it to make it compile some months ago) ... did not help. I also tried to copy as much of my main file into a test-file, compiled without trouble. But - the main file wasn't changed during the last revisions so it wont be a newly introduced line but something the compiler gets hickups from. Edit2: I copied my main.bmx-file to another testfile, this does not compile too (like I awaited it). OK, I then took out an "included" file, copied the code of the included file back to my main file... voila ... it compiled. So experimented further: I switched places of 2 include-commands, so the "problematic" include took place before another included file (before it was vice versa) ... compiled too. I first thought bcc run into trouble because I "included" to much but this seems not to be the key to the solution. ... I splitted the "included" file up into different parts to see where it "hang". Seems I cannot do But must do Now it compiles - but only my testfile. "main.bmx" does still not compile. It contains the exact same code than "compile.bmx" - except of different references as "compile.bmx" is located in a testfolder and therfor does include "../source/basefunctions.bmx" etc. If I now copy the "compile.bmx" to my source-folder, replace all references back to 'include "basefunctions.bmx"' etc - it does not compile. If I copy everything to another folder, delete everything (.bmx-folder), checking ACL for the files ... I get that compilation error on "basefunctions_guielements.bmx" again. So what have I achieved? Nothing but some lost hours investigating in something "random". bye Ron bye Ron |
| ||
| I tried searching for "Generating interface" and found a thread about mkdir failing, apparently when trying to create a .bmx folder, that might be a clue. http://blitzbasic.com/Community/posts.php?topic=50082#556952 |
| ||
| Have you tried running it in gdb? Maybe the backtrace will help? Have you tried turning your computer off and on again? :-) |
| ||
| I edited my post while you answered ...so check the "edit" and "edit2". mkdir - the .bmx-directories are existing. And like said: It compiled hundreds of times before. I did not change much - exception of adding new code (so it got bigger again). @GDB how would I do that? I think something like running the bcc from GDB. EDIT: neither "bcc.exe" nor "bmk.exe" contain debugger symbols which are needed for GDB. (I run gdb --args C:\BlitzMax\bin\bmk.exe ... and --args C:\BlitzMax\bin\bcc.exe ... -each with the params used from bmk or bmk-calling-bcc). bye Ron |
| ||
| You might also try rebuilding all your modules. Do you use include rather than import? |
| ||
| For "basefunction_****"-files I use import. For some "gamefunction_****" files I had to use "include" because they eg. reference a global Game:TGame = TGame.Create(...) So that means: I have 2 dozens of files being "imported" (and they import each other - to gain access to an EventManager, AssetManager...). And 8-10 files being included (else I would end up with an huge main.bmx which is not that easy to enjoy :D). @rebuild modules: How should that help (I did not change MinGW-Version, I did not change modules) - like said, it worked for weeks/months without flaws - then some weeks ago I sometimes had to press "build" multiple times until it worked as it should. During a "quickbuild" all the imported files are included using their already compiled "caches". So changing parts within the "problematic file" just forces that file to be compiled again - and this is there the trouble is located. example of import/include within my main.bmx bye Ron EDIT: another computer, another fresh install of blitzmax + mingw tdw 7.1 ... compiled without flaws (ok the -ldsound thingy but this should be recoverable - redis mod for streamed audio needs some nice hands to feel comfortable). This computer has some gigs more RAM than my build-installments ... maybe that changes something? The small windows-machine is rebuilding modules now. If that is a module making bcc feeling not welcomed on my machine ... bcc should give me some clues (aka "output errors"). EDIT2: Meanwhile on my second virtual XP ... I recompiled (full) - error, recompiled (full) ... worked. My RAM was checked some weeks ago by the shop I bought my computer parts - they replaced it and checked the new one without errors. But somehow I think it might have to do something with RAM at all ... 3 XPs did not build correct (2 of them virtual), the 3rd worked (the libdsound error) now, after restarting the machine a 12th time ... it worked (my host was already restarted yesterday/today/5min ago). @brucey: If you find some minutes - please explain me by EMail how to setup the cross-compile thing for linux. Had some trouble last time I tried it . As I assume that most of the mods I use are from you, I would be able to use your versions of the crosscompile-tools. |
| ||
| @rebuild modules: How should that help I'm just saying. Sometimes you just need to give it a kick. I doubt RAM is a big issue - the "imports" do not take up an excessive amount of space. Unless there is a problem *with* your RAM. I know I can get BlitzMax to fail compilation on my work Linux box because one of the RAM is bugged. Mostly it builds fine, but sometimes it needs a few attempts. For something that *just works* which suddenly does not, you have to think of something else that changed on your system - whether be a hardware or software issue. Did you try turning it off and on again? ;-) |
| ||
| Yes I tried turning it off and on again... Now I tried to revert the current changes (aka use the most current revision of my code) and that virtual XP ... was not able to compile the game anymore :D Rebuilt the modules, did a full recompile... error. Will have a linux-memorycheck while the other computer does the module-build thing. EDIT: that computer - copied ld.exe, ar.exe and the libfiles, rebuilt modules, compiled "non quick" also has an error during compilation. So it is not the RAM of my normal dev-computer. BTW that exact same source code still compiles fine on linux.  bye Ron |
| ||
| I have sent my whole code to magic Brucey ... who had the same problem: it did not compile. He rearranged my code until he narrowed to a certain file. Ripped out code ... no changes. Emptied the whole file ... and it worked. Further investigations lead to the following result: a big comment at the start of the file has to get removed: deleting that comment (including REM...ENDREM) made the compilation work. As I had a compilation error in another file some time ago (multiple "recompilation" including adding/removing empty lines made it work again). I personally doubt that that comment is the real "source" of the compile-problem but somehow bcc runs into trouble - and next time it is another file being "problematic". edit: If I only delete the line failed/run OK"), we have to create individual "TAdvertisement"/spots. It compiled. Now I tried to find out if it is something like a "reserved word" being parsed. Deleting "failed/run" - compilation worked Deleting "we" - changed nothing Deleting "we have" - compilation worked Deleting "create" - compilation worked Deleting "individual" - compilation worked So It sounds like it needs a certain "character length" get deleted to make it work. I now tried something different. There is a quotationmark beginning in the first line As we have to know broadcast states (eg. "this spot It ends in the next line. If I add a " at the end of the line ("this spot") it dit not work. But if I now remove the quotation mark in the next line failed/run OK"), we have to create individual "TAdvertisement"/spots. so after ' run OK" ', it compiled again. Like a parser is searching for opening and closing marks - and somehow the "search buffer" is corrupted or to small to find the closer. I will now email Mark directly - as this must be a bug within BCC and I do not know whether he reads such topics here. bye Ron |
| ||
| Hello fellows, could you please try to compile this simple rem-blocks CouldCrashCompilation.bmx DoesNotCrashCompilation.bmx On Windows XP (I tested on Corporate and Home) the compilation of the first code fails (Brucey even made a video if you don't trust me). I myself now tested: - Mint 16 XFCE (Ubuntu 13.x based) -> OK - Ubuntu 12.04 -> OK - Microsoft XP Corp -> failed - Microsoft XP Home -> failed - Microsoft Vista Home Basic -> OK - Microsoft 7 (30days Testversion) -> OK I am also in contact with Mark Sibly about that Bug but he does not has access to "Windows XP", so maybe some one can reproduce this bug on another Windows incarnation. Any help accepted. bye Ron |
| ||
| Brucey even made a video if you don't trust me I have a nice video from builds on XP which crash when you have a line in a rem block with an odd number of double quotes. If you even up the double quotes, it builds okay. I guess the "workaround" is to accept that bcc is broken, and change comments to always have even numbers of quotes per line... haw. |
| ||
| Are you sure about this? I just had a simple test - which works with even or odd number of double quotes. (a short block having 2 times 2 lines with a quot on each of them ... adding another one / removing one - did still compile It is surely connected to something else (eg. I had problems with (eg. " while (longerwordwithDot. " worked And altogether it sums up to the bug. bye Ron |
| ||
| Another nice thing: Take the "couldCrashCompilation"-code, delete the two lines with =========================================================== code for advertisement-objects in programme planning =========================================================== replace it by: ======== (8 equal signs) It crashes. Reduce the signs to 7 or lower - and it compiles again. bye Ron |
| ||
| Maybe we shouldn't have rem blocks. Just use ' comment lines! :-D |
| ||
| Seems nobody knows "bcc" or is interested in a more crash free blitzmax compiler for Windowssystems. bye Ron |
| ||
| They probably know they will be no response! :D Dabz |
| ||
| Last reply I got from Mark Sibly was on monday morning (so I assume "sunday evening" for him) that he will have a look at it "tomorrow", maybe the look takes longer than needed (or he tries to find the old "windows xp sp1"-cd from the old dust catcher in the garage :D). But @Dabhand: Would be nice if you tried to compile the codebox above and write if it works for you (and the OS you use - if it does not work it is even of interest if you installed all OS updates/service packs). bye Ron |
| ||
| I do think that giving support for xp is during in ten months its gonna be a mute point unless it fails on vista or later, i do prefer xp over vista/7 though i also like 8 for its speed though :) |
| ||
| BlitzMax was sold with XP support - there wasn't an update (I think) which said "from here on we do not support XP". The way more important thing for me: The VirtualBox-Support of XP is way better than Vista/7. Why? My apps do not crash in there... also the graphics look like they have to do while under Vista and 7 I get crashes (as soon as I use rtAudio) or things like DrawSubImage do not work (you get all of the image squeezed). So for fast/rapid testing of things I could use my virtualBox (real deployment could be done using windows - but up to now it seemed not to be needed). And... I asked other for erroneous behaviour on other platforms. AS there certainly is a bug - it also may occour on other Windows incarnations. bye Ron |
| ||
| Sorry for the [very] late reply Derron matey... Windows 7, above code builds fine, even with the eight equals signs, I dont have XP I'm afraid, but tested it on virtual Vista installation and it built okay too! Dabz |
| ||
| Windows 8 built correctly too I assume ? Regarding responses from Mark ... he kept being silent since last monday, hope he just is busy trying to hunt the bug. bye Ron |
| ||
| Windows 8 built correctly too I assume ? Erm, nope... My old laptop is at my ex-wifes house... Must remove that bit from my sig... Sorry about that! :) Dabz |
| ||
| Oh noes, first the house, second the laptop. So ... someone here with windows 8? I am really to lazy to VPN to my university to access dreamspark, download a huge image just for building up another virtual windows. Also this "involves" others which may arouse interest in the topic at all. bye Ron |
| ||
| Hello Ron, just tested on Win 8 with no problems. -Henri |
| ||
| second the laptop. Desperate isnt it! :D lol Dabz |
| ||
| Hope you just kept the licence key ... reactivate a virtual machine to make her installation get questionized :D @Henri thanks for testing. Seems it is really something which changed with NT-Kernel 6.0 5.0 and 5.2 (xp home and pro) work and 6.0 comes straight after 6.0. The only crucial thing I found was the change within NTVDM (concerning 16 bit processes - which bcc should not be). As the short "rem block" is enough to make it break, I am really sure that there is a bug. I doubt that this bug is only happening on XP. It could be something in the lines of BCC or in the lines of 3rd party code. In both cases the bug should be cirvumentable with corresponding code changes in bcc. But hey... maybe Mark some day comes up with a solution to the problem (I do not talk about deleting "XP" from the supported list). bye Ron |
   |