QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Ryster on December 16, 2018, 01:43:07 pm
-
.../internal/temp/compilelog
In file included from qbx.cpp:2161:0:
..\\temp\\main.txt: In function 'void QBMAIN(void*)':
..\\temp\\main.txt:692623:1: internal compiler error: Segmentation fault
}
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Please, comment on this entry.
-
Judging by the line number where it failed I assume you have a massive program being compiled there which exceeded memory limits. Could that be the case?
-
Exceeded memory limit - I think so too. The .bas file has 3.98 MB. I installed Mingw-w64 downloaded from https://sourceforge.net/projects/mingw-w64/.
-
Not much that can be done. If this is a program that's been processed by vWATCH, then probably vWATCH is not your solution right now, as it more than triples the original file size for the debug session to occur.
Now if this is solely your code, then you might consider reducing parts of it. We can help take a look if you're willing to share it.
-
No, I did not use vWatch. I wrote about it a few days ago, but no one answered so I deleted the post. The Mingw-w64 compiler simply can not do it. Maybe you know a more efficient version of Mingw.
-
I only use the one version we ship with QB64, sorry. Someone else may be able to help you.
-
First of all, welcome to all QB64 Members. My program is: about 65,000 lines of code weighing 3.98 MB (20 MB exe), but I do not want to discuss this. My program can not always be compiled. If after using the computer, I use browsers etc. probably the compilation will fail. However, I will run the compilation directly after turning on the computer, then the compilation will run correctly on 99%. I do not suspect a small amount of RAM, because it is 16GB, and should be enough for most processes. But - I use mingw-w64-bin-x86_64-20170820 and that's what I suspect about making trouble with the compilation. Maybe someone has a similar (or had) situation and remedied the problem. Greetings.
Ah, I remember this post. Are you Chris from Poland?
-
Let's talk about particulars.
Once on the QB64 replacement forum, a guest advised me to install Mingw from the manufacturer. I downloaded the file, installed it and everything was ok, until the program expanded. At the moment I have two programs: old x64, which usually (not always) compiles correctly. And the second new one given by Pete from the dropbox. And this new version does not compile the code.
-
Last time we talked about your program it was a top secret thing that mainly crashed due to the way it handled string concatenation and exceeded memory limits.
Considering we have many different massive projects that compile just fine even with the dated compiler that comes with QB64, I still assume there's some terribly inefficient code in your project that could be greatly optimized.
I hope you can find a good solution (Steve usually tries to improve the hacks to get your code compiling, let's see if he comes to the rescue).
Other than that, I'm afraid it's beyond any of us to assist you with your mysterious code, especially since it's hard to imagine what is being done there.
-
That it is not effective may be true, but it is also true that the code's syntax is correct.
As if it were Otherwise, I would never compile the code. I will not improve efficiency again. Anyway, if the code does not contain syntax errors, then it should be compileable. Otherwise, the fault lies on the compiler side. Nevertheless, thank you for your comment. Greetings.
-
Anyway, if the code does not contain syntax errors, then it should be compileable. Otherwise, the fault lies on the compiler side.
As you point out if your code doesn't contain any errors than it should compile, if its the compilers fault then most of us here would not be able to compile either. What I suggest is to comment out sections of your code and use the MAKE EXE ONLY option till you find when it will start to compile, then go through that area of the code trying each line until you narrow it down, then you could maybe post that line and say "hey, this line kills the compiler" and maybe then a solution will present itself. Doesn't matter how big your program is you just have to methodically try throughout the whole thing.
Without the actual code for people around here to help with there is nothing more to be done.
-
To Cobalt
Thank you for this advice. I will find one, second, third ... then several hundred or several thousand.
-
That it is not effective may be true, but it is also true that the code's syntax is correct.
As if it were Otherwise, I would never compile the code. I will not improve efficiency again. Anyway, if the code does not contain syntax errors, then it should be compileable. Otherwise, the fault lies on the compiler side. Nevertheless, thank you for your comment. Greetings.
I respect you. Just one final remark on the subject:
No syntax errors. Compilable. Highly inefficient.
-
Chris,
Just curious: how long have you been developing this program?
I could see how changing the methods could be difficult given the amount of time and effort you put into it.
An alternative maybe to split it in separate executables that call each other, having tried in QB64 though old Qb used the CHAIN command for that.
https://www.qbasic.net/en/reference/qb11/Statement/CHAIN.htm
That way you can transfer execution to another part of your program, splitting it anyway as it seems your program execution is mostly linear?
Just curious about the secret nature; is this a program to benefit humanity or is it mostly propitiatory information you created, or something else?
Thanks
-
Chris,
Did you try FreeBasic (fdc.exe) Might work if you give it enough time to compile.
I just hope that you compiling the program successfully doesn't result in an ending like the Tribe of the "12 Monkeys"
-
To FellippeHeitor.
Fellipe wrote:
DOWN
LOOP
Is this supposed to be a joke?
You write about efficiency. In DOS times, every byte was worth its weight in gold. Today in the Windows era, who pays attention to such a small thing: kilobyte or megabyte. He does not care about anyone anymore. The frequency of processors calculated in gigahertz, RAM in gigabytes. Even if the program was not effective, it will not be important for the potential user. Anyway, nobody cares how it works - it's important that it works properly. In summary, each program can be improved, changed - just why mix as something works properly in the final sense.
Thanks with help.
To pagetelegram
Chris? Ryster!
I am afraid, saying, I was afraid to raise this topic in the Forum. The program has been developing for about 13 years. When writing a program, I did not write only for myself, but also for other users in the global sense. Users from different parts of the world use my program, and somehow nobody complains.
https: //www.qbasic.net ... I do not really understand what you mean.
Thanks for showing interest. I think that you should finish this topic - Administrator probably lost patience. Greetings.
-
Ryster,
Use FreeBasic! With that compiler every byte does counts! Instead of a 1.5mb+ QB64 compile you get your old DOS sized 40kb+ compiled executable.
Just put
at the top of your code and compile away!
https://www.freebasic.net/
-
Maybe that'll be the final solution. Freebasic for the win.
-
OP, you kind of sound a bit like me on one point I think we can relate: with your expression that "every byte was worth it's weight in gold." I could concur with that, that Moore's law has led to bloat in my opinion.
However I also concur to William Strunk's philosophy to "omit needless words," in the Elements of Style even though I maybe better at that as a writer than as a programmer.
With programming, I'm a tad bit lazy to think about organization and making code easily understandable by others with well put remarks and variable names that make sense.
-
To Cobalt
Thank you for this advice. I will find one, second, third ... then several hundred or several thousand.
That is quite possible, there has been times I have found a great many lines myself. But the only way to get started is with that first step(or in this case 'line').
and remember with out code for us to look at and try to compile on our side all we can do is advise, not fix. just FYI.
Don't think that Fellippe is being rude or mean he is just doing what he can while being blind, as without something to see(the code in this case) we are all just blind. If you are hell bent against letting others see the code that is fine, just don't expect a miracle fix to suddenly spring up here. As you are the only one that is having a problem compiling at this time.
Just curious how long does it take the IDE to parse your BAS file or are you not loading it into the QB64 IDE? I am just wondering cause I once tried to include a 400k (391k to be more precise) data file into a programs source and the IDE wouldn't parse the program anymore. That was back before there was an option to turn off the syntax checking though.
-
That it is not effective may be true, but it is also true that the code's syntax is correct.
As if it were Otherwise, I would never compile the code. I will not improve efficiency again. Anyway, if the code does not contain syntax errors, then it should be compileable. Otherwise, the fault lies on the compiler side. Nevertheless, thank you for your comment. Greetings.
Here's a quick little program -- only 4000 lines of code:
https://www.dropbox.com/s/1dqiyvgpcw33w4f/AplhaPrint4000.bas?dl=1
Download a copy of it. Paste it into QB64. It's syntax is just peachy fine. Not a single glitch in it.
BUT....
It won't compile.
WHY??
(For those who might not want to download the file, it's basically just a copy/paste of this one line 4000 times:
PRINT "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z" )
Go take a look at the C-output which we generate in temp/main.txt and see what it looks like...
444,023 lines of code!!
QB64 translates BAS to C, and PRINT is a monster to translate. Each one of those lines translate into a hundred lines of c-code, and the compiler simply craps out eventually while trying to build it.
cc1plus.exe: out of memory allocating 16008 bytes
Now, the way around it is to fix the code so it doesn't have 4000 repititions of copy/pasted PRINT Statements. The below works just fine:
PRINT "A";
"B";
"C";
"D";
"E";
"F";
"G";
"H";
"I";
"J";
"K";
"L";
"M";
"N";
"O";
"P";
"Q";
"R";
"S";
"T";
"U";
"V";
"W";
"X";
"Y";
"Z"
Or change the code to PRINT "A" + "B" + "C" + "D" + "E" + "F" + ....
It translates to a whole lot fewer lines than print with semicolon as a delimiter, and prevents the issue...
And none of these limits is actually anything imposed by QB64 itself. It's all just the compiler hitting its internal limit on something, and there's nothing we can do for you about that.
It's a choice of either rework the code to reduce the burden on the compiler, or else find a completely different compiler and give it a shot to see if it has the same limits. Either way, there's not much we can actually do for you about the issue. It's not QB64 which is failing; it's the limits of the c-compiler itself which you're running into.
-
no kidding Steve, there are 104000 copies of these 4 lines for the 26 letter. hell does 'makefit' do?;
qbs_set(tqbs,qbs_new_txt_len("T",1));
if (new_error) GOTO skip8000;
makefit(tqbs);
qbs_print(tqbs,0);
even if you turn $CHECKING:OFF it still has the IF GOTO lines. kind of thought those would go away since they seem to be error checking lines.
though I got this error in the compile log:
cc1plus.exe: out of memory allocating 33558527 bytes
-
Got it to compile at 3000 lines.
and it runs.
might be able to squeak it up to about 3300 lines I think..
SURE THING, 3300 line compiled and run!
Gonna try for 3500.....
oooohhh... nope... BUT 3450 line worked!!!!
so somewhere between 3450 and 3500 lines is max printing that way.
-
no kidding Steve, there are 104000 copies of these 4 lines for the 26 letter. hell does 'makefit' do?;
qbs_set(tqbs,qbs_new_txt_len("T",1));
if (new_error) GOTO skip8000;
makefit(tqbs);
qbs_print(tqbs,0);
even if you turn $CHECKING:OFF it still has the IF GOTO lines. kind of thought those would go away since they seem to be error checking lines.
though I got this error in the compile log:
cc1plus.exe: out of memory allocating 33558527 bytes
makefit is the word wrap routine which comes when you print, IIRC.
the (new_error) handles user breaks during execution, such as clicking the little red X in the top right of the program. It’s not specifically for error detection, but user interruptions. (Does Ctrl-C still break loops/execution? I don’t remember what all it catches now, honestly.)
All the lines with “qbs” stand for Quick Basic Strings. We set a temp string type to hold the constant value with qbs_set, then print it to the screen later with qbs_print...
QB64 translates everything just fine. The c-compiler just runs out of memory before it can do its thing.
-
in the 32bit version I was able to compile 3450 lines of your test program, with an output exe size 7.38megs.
fails at 3500 lines so, there is probably a command line option like -bigobj (visual studio) that would allow larger file compiling, but I couldn't find anything on it. There has to be something out there cause I'm sure somebody has made a c or c++ program that consists of far more than 400000 lines out there.
-
in the 32bit version I was able to compile 3450 lines of your test program, with an output exe size 7.38megs.
fails at 3500 lines so, there is probably a command line option like -bigobj (visual studio) that would allow larger file compiling, but I couldn't find anything on it. There has to be something out there cause I'm sure somebody has made a c or c++ program that consists of far more than 400000 lines out there.
It’s however c tries to optimize the code. Run it and watch memory usage in Explorer. It goes up, up, up, and up, until it crashes. There may be -no-optimize flags you can set to bypass the issue, but if so, I have no clue what they are. At around 1.6GB memory usage, the c-compiler crashes.
-
For SMcNeill analysis.
There are 39730 in my PRINT program.
The whole has nearly 65,000 lines. Currently, the program compiles correctly. But how do I want to add about 3000 lines not necessarily all of PRINT - memory overflow error. So the PRINT function is not a problem in itself. The problem occurs when we connect PRINT in a chain with other elements.
-
As others have said, without the actual code, there’s nothing much we can do to help. My example above was to demostrate one possible issue where perfectly valid code translates but then fails to compile. PRINT is a monster behind the scenes, and you have almost 40,000 lines using it. I simply demonstrated where as little as 4,000 can cause the compiler to fail with the memory issue you’re experiencing.
Unless you can share the code, your only real options is to:
1) Rework to code to reduce the c-compiler memory usage, so it works.
2) Try a different compiler or optimization switches/settings to improve efficiency.
3) Try a different translator such as FREEBASIC, described above.
4) Get frustrated, scream “Screw it”, toss it in the recycle bin, and binge out on Ben’s & Jerry’s
-
Ha, Ha. You will have to wipe your eyes with astonishment. I downloaded your file and compiled correctly. I attach the scan as proof. I did not combine anything with the code. I just have a version of QB64 and I keep it on the disk like a relic.
-
It’ll compile with the QB64x64 version, as the memory ceiling is higher, but copy paste it a few times and you’ll quickly hit the same issue. Each compiler has its limits. Your code has caused the version you’re using to hit its. Your only real options, I listed above.
-
4) Get frustrated, scream “Screw it”, toss it in the recycle bin, and binge out on Ben’s & Jerry’s
OK, I will drink, and You will delete my account - and tea.
-
Did you ever bother to try compiling using fbc, the FreeBasic compiler?
It will get you just what you want....small binary executable and it does compile your stuff when QB64 does not.
Or are you just trolling qb64 in-capabilities with your alphabet soup?
Someone posting your alphabet soup on this forum did crash the MySQL entry rendering this thread inaccessible, yesterday. :P
Fellippe came to the rescue doing some under the engine MySQL to delete that "malicious" alphabet soup of yours lol in the post reply.
For tinfoil=1 to 4000
shell "echo ? "+chr$(34)+"hat's off to you for crashing MySQL database yesterday with your secret 'burn after reading' program"+chr$(34)+" >> hat.bas"
next tinfoil
-
Here is your compiled program:
http://hand.is/alpha4000lines.zip
Works! used fbc!
-
Here is your compiled program:
http://hand.is/alpha4000lines.zip
Works! used fbc!
That’s just an example I shared. Chris’s actual program is over 60,000 lines, and he can’t share it for propitary reasons.