Compiler crashing

[Sasszem]

I've just started a project with xa, but after some time I've ran into the compiler crashing on my code. It also found illegal pointer arithmetic errors in the code which compiled without a problem previous day. I have no idea what could cause this, as some random test code I wrote compiled without a problem. Here's the backtrace, but I don't think this would be useful.

*** Error in `xa': free(): corrupted unsorted chunks: 0x00000000006fc810 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f1dcad4c7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f1dcad5537a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f1dcad5953c]
/lib/x86_64-linux-gnu/libc.so.6(_IO_setb+0x4b)[0x7f1dcad5054b]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_close_it+0xae)[0x7f1dcad4e8ee]
/lib/x86_64-linux-gnu/libc.so.6(fclose+0x18f)[0x7f1dcad423ef]
xa[0x40227a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f1dcacf5830]
xa[0x402ca9]
======= Memory map: ========
00400000-00412000 r-xp 00000000 08:12 524295                             /usr/local/bin/xa
00612000-00613000 r--p 00012000 08:12 524295                             /usr/local/bin/xa
00613000-00614000 rw-p 00013000 08:12 524295                             /usr/local/bin/xa
00614000-00617000 rw-p 00000000 00:00 0 
006e0000-0072a000 rw-p 00000000 00:00 0                                  [heap]
7f1dc4000000-7f1dc4021000 rw-p 00000000 00:00 0 
7f1dc4021000-7f1dc8000000 ---p 00000000 00:00 0 
7f1dcaabf000-7f1dcaad5000 r-xp 00000000 08:12 1839696                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1dcaad5000-7f1dcacd4000 ---p 00016000 08:12 1839696                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1dcacd4000-7f1dcacd5000 rw-p 00015000 08:12 1839696                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1dcacd5000-7f1dcae95000 r-xp 00000000 08:12 1840554                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1dcae95000-7f1dcb095000 ---p 001c0000 08:12 1840554                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1dcb095000-7f1dcb099000 r--p 001c0000 08:12 1840554                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1dcb099000-7f1dcb09b000 rw-p 001c4000 08:12 1840554                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1dcb09b000-7f1dcb09f000 rw-p 00000000 00:00 0 
7f1dcb09f000-7f1dcb0c5000 r-xp 00000000 08:12 1840552                    /lib/x86_64-linux-gnu/ld-2.23.so
7f1dcb28d000-7f1dcb290000 rw-p 00000000 00:00 0 
7f1dcb292000-7f1dcb2c4000 rw-p 00000000 00:00 0 
7f1dcb2c4000-7f1dcb2c5000 r--p 00025000 08:12 1840552                    /lib/x86_64-linux-gnu/ld-2.23.so
7f1dcb2c5000-7f1dcb2c6000 rw-p 00026000 08:12 1840552                    /lib/x86_64-linux-gnu/ld-2.23.so
7f1dcb2c6000-7f1dcb2c7000 rw-p 00000000 00:00 0 
7ffed359b000-7ffed35bc000 rw-p 00000000 00:00 0                          [stack]
7ffed35ee000-7ffed35f1000 r--p 00000000 00:00 0                          [vvar]
7ffed35f1000-7ffed35f3000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

PS: I've tried updating xa, reinstalling, and updating from this repo, with no success.

[Sasszem]

Oh damn it. I've been searching for the problem for nearly a week. Ten minutes after opening an issue & I found it randomly... The problem was that for some reason I've written .data instead of .byte. It crashed the compiler and generated false errors, so I mainly looked at my code. It was an annoying typo, and the compiler certainly couldn't handle it.

[fachat]

It would be nice if you could better describe the problem where xa crashed, and maybe even provide a test case, e.g. two lines one with .byte and one with .data with the same parameters where it crashes on .data. That would help us in fixing this problem, and if that does not work, at lease print an appropriate error message. Thanks

[fachat]

Reopening because a bug that is not fixed is not fixed...

[Sasszem]

Here's the simplest code I've came up with, by removing instructions from my actual code:

mainloop:

    ldx #255;
    waitx:
        ldy #255;
        waity:
            dey;
        bne waity;

        dex;
    bne waitx;

    joy:
        right:
            lda #8;
            bit $dc00;
            bne left;
                ;there were some code
        left:
            lda #4;
            bit $dc00;
            bne up;
                ;there too
        up:
            ;lda #2;
            ;bit $dc00;
            bne mainloop;
                ;and there
jmp mainloop;

.data 0,0,0,0;

Remove the .data line and it compiles without any error. Removing any more instructions will prevent the compiler from crashing, but gives illegal pointer arithmetic errors. It makes no sense...

[Sasszem]

Could you replicate the problem?

[fachat]

sorry for the late reply. Still crashes with 2.3.9

[fachat]

Ok, the problem here really is that ".data" is not something to insert data into to the binary, but to switch to the data segment when building a relocating file. So the "0,0,0,0" are completely ignored - use ".byte" or ".word" for that, depending on what width of the data items you need.

As for the crash, there was a bug in xa that did not reset the segment (either "data", "bss", ...) to its initial value between pass1 and pass2 - it just assumed you would not end in a different segment, or the first statement basically would set the right segment. See the "issue-3" branch for a fix, if you could try that out? here's the diff for the fix: https://github.com/fachat/xa65/commit/003f35f45b5b2ac98ef3089003344ba45f5dbcfc

That also explained the "illegal pointer arithmetic on the forward branches - they could only be resolved in pass2 (as they are forward not backward branches), but in pass2 the segment was incorrectly set to "data", while in the first pass it was "abs" (=no relocation), and pointer arithmetic (basically PC+/-branch offset) does not work across different segments.

As for ".data" not giving a warning when the assembler is not used in relocation mode.... that is another issue I guess.

I'll forward this to Cameron to have it put into the next proper xa version.