FreeBASIC crashes when compiling very large programs

General FreeBASIC programming questions.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC crashes when compiling very large programs

Post by MrSwiss »

OK, fine, the only thing that's missing then:
Link to *LABEL* at the bottom of the page (missing, currently)
fxm
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC crashes when compiling very large programs

Post by fxm »

Okay, I will (and also for other concerned pages).
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC crashes when compiling very large programs

Post by MrSwiss »

Great to hear, thank you ..
dodicat
Posts: 7983
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC crashes when compiling very large programs

Post by dodicat »

I am confused here.
How can a label be a string literal?

I understand the compile time idea of setting the data elements.
If the literals are constant they can be accessed in the DATA by their name.

The wiki page on labels is fblite and qb.
Very confusing since lang qb operates differently with data elements, and labels (they can be a number)

Code: Select all



#macro strings(z)
 z a= "Free"
 z b= "BASIC"
 z c=" is"
 z d=" free."
 z e="end"
#endmacro

strings(const)



dim as integer n


dim as string  g=" "

while len(g)
read g
print g;
wend

print


g=" "

restore label 'how can this be string literal?


while len(g)
read g
print g;
wend
print
print e
sleep

'=============
data a,b
label:
data c,d

 
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeBASIC crashes when compiling very large programs

Post by marcov »

fatman2021 wrote:Summary
The process fbc (with pid 18253) is using approximately 492.7 MB of memory.
Sounds like you use a distribution that has an ulimit (-d) of about 512MB.
fxm
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC crashes when compiling very large programs

Post by fxm »

MrSwiss wrote:OK, fine, the only thing that's missing then:
Link to *LABEL* at the bottom of the page (missing, currently)
Done:
KeyPgReturn → fxm [Added (in §"See also") a link to the "Labels" page]
KeyPgRestore → fxm [Added (in §"See also") a link to the "Labels" page]
KeyPgOngoto → fxm [Added (in §"See also") a link to the "Labels" page]
KeyPgOngosub → fxm [Added (in §"See also") a link to the "Labels" page]
KeyPgOnerror → fxm [Added (in §"See also") a link to the "Labels" page]
KeyPgLocal → fxm [Added (in §"See also") a link to the "Labels" page]
dodicat wrote:I am confused here.
How can a label be a string literal?
Yes, "string literal" is inappropriate.
The best is to talk about "symbol name" (as on the "Labels" page).
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FreeBASIC crashes when compiling very large programs

Post by caseih »

May I ask what this program does? Seems like there has to be a better way to do this than BASIC data statements and a read loop. Is the idea that you're compiling in some static binary data, such as a picture? What about writing a program that reads your binary data from disk or some source and writes it to a new FB source code file that defines a static byte array, initialized with your binary data. That way you can access your data directly without any read loop.

If you've ever looked at an XPM image file, you'll find that's what it is, actually. It's compilable C code. Similar idea.
fatman2021
Posts: 215
Joined: Dec 14, 2013 0:43

Re: FreeBASIC crashes when compiling very large programs

Post by fatman2021 »

marcov wrote:
fatman2021 wrote:Summary
The process fbc (with pid 18253) is using approximately 492.7 MB of memory.
Sounds like you use a distribution that has an ulimit (-d) of about 512MB.
My ulimit is unlimited....In theory, baring hardware limitations, I should be able to use up to 16TiB of RAM.
Last edited by fatman2021 on Sep 29, 2017 21:06, edited 1 time in total.
fatman2021
Posts: 215
Joined: Dec 14, 2013 0:43

Re: FreeBASIC crashes when compiling very large programs

Post by fatman2021 »

caseih wrote:May I ask what this program does? Seems like there has to be a better way to do this than BASIC data statements and a read loop. Is the idea that you're compiling in some static binary data, such as a picture? What about writing a program that reads your binary data from disk or some source and writes it to a new FB source code file that defines a static byte array, initialized with your binary data. That way you can access your data directly without any read loop.

If you've ever looked at an XPM image file, you'll find that's what it is, actually. It's compilable C code. Similar idea.
It is a video of my cloth simulation. The source code was generated using my BMP2QB64 program:

Code: Select all

SCREEN _NEWIMAGE(640, 480, 32)
CLS: LOCATE 1, 1: INPUT "number of frames -> ", imageNo%
CLS: LOCATE 1, 1: INPUT "number of frames per second ->", fps%
CLS: LOCATE 1, 1: INPUT "frame width ->", fwidth%
CLS: LOCATE 1, 1: INPUT "frame height ->", fhight%
IF imageNo% = 0 THEN END ELSE BMP$ = "1"
IF imageNo% = 1 THEN BMP$ = OLDBMP$
CLS: LOCATE 1, 1: INPUT "enter alpha level -> ", ALPHA$
ALPHA$ = LTRIM$(RTRIM$("&H" + HEX$(VAL(ALPHA$))))
IF VAL(ALPHA$) < &H00 OR VAL(ALPHA$) > &HFF THEN END
FILE$ = BMP$ + ".bmp"
HANDLE = _LOADIMAGE(FILE$)
Pw% = fwidth%: Ph% = fhight%
Ps% = _PIXELSIZE(HANDLE) * 8
SCREEN _NEWIMAGE(Pw%, Ph%, Ps%)
IF Pw% < 320 THEN Ww% = 320 ELSE Ww% = Pw%
IF Ph% < 200 THEN Wh% = 200 ELSE Wh% = Ph%
OPEN "MAIN.BAS" FOR OUTPUT AS #1
FOR FileNo% = 1 TO imageNo%
    OPEN LTRIM$(RTRIM$((STR$(FileNo%)))) + ".BAS" FOR OUTPUT AS #2
    PRINT #1, LTRIM$(RTRIM$("'$INCLUDE:'")) + LTRIM$(RTRIM$((STR$(FileNo%)))) + LTRIM$(RTRIM$(".BAS" + "'"))
    BMP$ = OLDBMP$ + LTRIM$(RTRIM$(STR$(FileNo%)))
    IF imageNo% = 1 THEN BMP$ = OLDBMP$
    FILE$ = UCASE$(BMP$) + ".bmp"
    HANDLE = _LOADIMAGE(FILE$)
    _PUTIMAGE (0, 0), HANDLE, 0
    FOR y% = Ph% TO 0 STEP -1
        PRINT #2, "DATA ";
        FOR x% = 0 TO Pw%
            CLR$ = LTRIM$(RTRIM$(ALPHA$ + RIGHT$(HEX$(POINT(x%, y%)), 6)))
            IF CLR$ = "&H" THEN CLR$ = "&H00000000"
            IF CLR$ = "&HFF000000" THEN CLR$ = "&H00000000"
            IF SL% = 45 THEN
                PRINT #2, CLR$
                SL% = 1: PRINT #2, "DATA ";
            ELSE
                PRINT #2, CLR$;
                IF x% = Pw% THEN
                    PRINT #2, CHR$(32)
                    SL% = 1
                ELSE
                    PRINT #2, ", ";
                    SL% = SL% + 1
                END IF
            END IF
        NEXT
    NEXT
    IF imageNo% = 1 THEN EXIT FOR
    CLOSE #2
NEXT
PRINT #1, "DIM xcolor AS _UNSIGNED LONG, x AS _UNSIGNED _INTEGER64"
PRINT #1, "DIM y AS _UNSIGNED _INTEGER64"
PRINT #1, "SCREEN _NEWIMAGE("; LTRIM$(RTRIM$(STR$(Ww%))); ", ";
PRINT #1, LTRIM$(RTRIM$(STR$(Wh%))); ", 32)"
IF imageNo% > 1 THEN
    PRINT #1, "DO UNTIL INKEY$ <> ";
    PRINT #1, LTRIM$(RTRIM$(CHR$(34))); CHR$(34)
    PRINT #1, "FOR frame% = 1 TO"; STR$(imageNo%)
END IF
PRINT #1, "HANDLE = _NEWIMAGE("; LTRIM$(RTRIM$(STR$(Pw%))); ", ";
PRINT #1, LTRIM$(RTRIM$(STR$(Ph%))); ", 32)"
PRINT #1, "_DEST HANDLE"
PRINT #1, " FOR y ="; STR$(Ph%); " TO 0 STEP -1"
PRINT #1, "  FOR x = 0 TO"; STR$(Pw%)
PRINT #1, "   READ xcolor: PSET(x, y), xcolor"
PRINT #1, "  NEXT x"
PRINT #1, " NEXT y"
PRINT #1, "_DEST 0"
PRINT #1, "_PUTIMAGE(0, 0)-("; LTRIM$(RTRIM$(STR$(Ww%))); ", ";
PRINT #1, LTRIM$(RTRIM$(STR$(Wh%))); "),  HANDLE, 0"
PRINT #1, "_FREEIMAGE HANDLE"
IF imageNo% > 1 THEN
    PRINT #1, LTRIM$(RTRIM$("_LIMIT ")); STR$(fps%)
    PRINT #1, "NEXT frame%"
    PRINT #1, "RESTORE: LOOP"
END IF
PRINT #1, "SYSTEM"
CLOSE #1
SCREEN 0: WIDTH 80, 25
PRINT UCASE$(BAS$); " saved."
fatman2021
Posts: 215
Joined: Dec 14, 2013 0:43

Re: FreeBASIC crashes when compiling very large programs

Post by fatman2021 »

caseih wrote:May I ask what this program does? Seems like there has to be a better way to do this than BASIC data statements and a read loop. Is the idea that you're compiling in some static binary data, such as a picture? What about writing a program that reads your binary data from disk or some source and writes it to a new FB source code file that defines a static byte array, initialized with your binary data. That way you can access your data directly without any read loop.

If you've ever looked at an XPM image file, you'll find that's what it is, actually. It's compilable C code. Similar idea.
I have already tried using static binary arrays:

Code: Select all

dim shared 48_data(0 to 1228800-1) as ubyte = { _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _ 
etc.....
FreeBASIC gives me the following error message:
48.bas(1) error 14: Expected identifier in 'dim shared 48_data(0 to 1228800-1) as ubyte = { _'
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FreeBASIC crashes when compiling very large programs

Post by caseih »

FBC is telling you it expected an identifier (a variable name) but could not find one in your code. That's because "48_data" is not a valid variable name. Variable names cannot start with a number. Change that and I'm sure it will compile.
dodicat
Posts: 7983
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC crashes when compiling very large programs

Post by dodicat »

But your array name starts with 48.
Put an underscore before the 48.

Code: Select all

dim shared _48_data(0 to 1228800-1) as ubyte = { _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF}
'etc..... 
fatman2021
Posts: 215
Joined: Dec 14, 2013 0:43

Re: FreeBASIC crashes when compiling very large programs

Post by fatman2021 »

dodicat wrote:But your array name starts with 48.
Put an underscore before the 48.

Code: Select all

dim shared _48_data(0 to 1228800-1) as ubyte = { _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF, _
&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C, _
&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A, _
&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D, _
&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF,&h9D,&h8A,&h8C,&hFF}
'etc..... 
Nope...Segmentation fault (core dumped)
fatman2021
Posts: 215
Joined: Dec 14, 2013 0:43

Re: FreeBASIC crashes when compiling very large programs

Post by fatman2021 »

fbc -gen gcc -r -c 1.BAS:

Code: Select all

typedef   signed char       int8;
typedef unsigned char      uint8;
typedef   signed short      int16;
typedef unsigned short     uint16;
typedef   signed int        int32;
typedef unsigned int       uint32;
typedef   signed long long  int64;
typedef unsigned long long uint64;
typedef struct { char *data; int64 len; int64 size; } FBSTRING;
typedef int8 boolean;
static void fb_ctor__1( void ) __attribute__(( constructor ));
struct $14__FB_DATADESC$ {
	int16 TYPE __attribute__((packed, aligned(1)));
	void* NODE __attribute__((packed, aligned(1)));
};
#define __FB_STATIC_ASSERT( expr ) extern int __$fb_structsizecheck[(expr) ? 1 : -1]
__FB_STATIC_ASSERT( sizeof( struct $14__FB_DATADESC$ ) == 10 );
static struct $14__FB_DATADESC$ label$14431[12] = { { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4288514700" }, { (int16)10, (void*)"4294967295" }, { (int16)-1, (void*)0ull } };

...etc.
fbc -gen llvm -r -c 1.BAS

Code: Select all

@__fb_ZTS6Object = global %fb_RTTI$ zeroinitializer
@Lt_0007 = private constant [11 x i8] c"4294967295\00"
@Lt_0035 = private constant [11 x i8] c"4287923338\00"
@Lt_0036 = private constant [11 x i8] c"4287923594\00"
@Lt_0040 = private constant [11 x i8] c"4287923337\00"
@Lt_0047 = private constant [11 x i8] c"4287988874\00"
@Lt_0048 = private constant [11 x i8] c"4287989130\00"
@Lt_004F = private constant [11 x i8] c"4288054666\00"
@Lt_0053 = private constant [11 x i8] c"4288120458\00"
@Lt_0054 = private constant [11 x i8] c"4288120202\00"
@Lt_005B = private constant [11 x i8] c"4288185994\00"
@Lt_005C = private constant [11 x i8] c"4288186250\00"
@Lt_0060 = private constant [11 x i8] c"4288186251\00"
@Lt_0061 = private constant [11 x i8] c"4288251787\00"
@Lt_0062 = private constant [11 x i8] c"4288251786\00"
@Lt_0066 = private constant [11 x i8] c"4288317323\00"
....etc.
%__FB_DATADESC$ = type <{ i16, i8* }>
@.Lt_FFD3 = global [12 x %__FB_DATADESC$] [ %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0D53 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 10 to i16), i8* bitcast (i8* @Lt_0007 to i8*) }, %__FB_DATADESC$ { i16 trunc (i64 -1 to i16), i8* 0 } ]
...etc.
@llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32, void ()* } { i32 0, void ()* @fb_ctor__1 }]
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FreeBASIC crashes when compiling very large programs

Post by caseih »

fatman2021 wrote:Nope...Segmentation fault (core dumped)
Okay, so at what point does the segmentation fault occur? How big of an array can you create and initialize until you get the fault?

Your last post I don't understand. What does it mean? Are you saying GCC is segfaulting compiling the C output, or does the C output never get completed because FBC is crashing? You need to be more descriptive here. Also you'll need to post a complete, but minimal example that illustrates the problem. Not just a snippet with .... That's not going to be helpful for others to help track down the problem. If you can't paste it here on the forum because it's too large, post it somewhere else (like on Gist https://gist.github.com/) and link to it.
Last edited by caseih on Sep 30, 2017 2:20, edited 2 times in total.
Post Reply