Elusive crash in fasmg

Index > Compiler Internals > Elusive crash in fasmg

Author

Thread

jacobly

Joined: 04 Feb 2016
Posts: 44

jacobly 07 Jan 2020, 19:37

There seems to be a bug in the latest commit (experimental bracket pairing option for MATCH) that is causing random memory corruption. I managed to track it down to the last stosd in alm_match (the one that stores the value from [enclosings]). If you need a test case I can provide one, but it is really fragile so hopefully the problem is obvious without it.

Edit: I also stumbled on another probably unrelated bug.

Code:

calminstruction calminstruction
        compute a, *
end calminstruction

This causes a consistent segfault across multiple targets (not that I expect it to assemble of course, but I ran across it while running a reducer looking for crashes).

Last edited by jacobly on 07 Jan 2020, 21:13; edited 2 times in total

07 Jan 2020, 19:37

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 09 Jan 2020, 09:09

Please let me know if any issues remain. I consider the base engine mostly ready feature-wise, at least for the first official release. I'm going to do some fuzzing myself and I keep working on macro packages - the more I have converted for the first demonstration, the better (even though their quality may not be best initially).

09 Jan 2020, 09:09

jacobly

Joined: 04 Feb 2016
Posts: 44

jacobly 10 Jan 2020, 07:20

Alright, I think I finally tracked down what is actually causing my crash without getting distracted by other bugs. Let me know what other information you need, but for now I know that fit_value's stosb with a count of one is writing one past the end of an allocation when called from single_data_unit with a [data_unit_length] of one. I also note that the crashing programs tend to use emit quite a bit.

10 Jan 2020, 07:20

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 10 Jan 2020, 09:10

Can you provide any steps to reproduce? Unfortunately I see nothing suspicious in the location you mentioned and my guess would be that memory has been corrupted by a bug elsewhere.

10 Jan 2020, 09:10

jacobly

Joined: 04 Feb 2016
Posts: 44

jacobly 10 Jan 2020, 16:09

Unfortunately, the bug only crashes with a specific allocator and ASLR layout so I'm not too hopeful easily reproducing it on another computer. It happens in an unusual allocation case, so it might even be a bug in the allocator. I'll keep debugging though, and hopefully I can find some minimal example that overflows the buffer, even if it doesn't crash (My current minimal example is 15K and full of random comments that can't be removed).

10 Jan 2020, 16:09

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 10 Jan 2020, 16:25

Is this with x64 version? It uses a custom allocator.

Other than that I feel like I'm mostly ready to make an official release. I only replaced a small subset of the macros, but the speedup is already there and I can keep rewriting the other ones gradually.

10 Jan 2020, 16:25

jacobly

Joined: 04 Feb 2016
Posts: 44

jacobly 10 Jan 2020, 21:02

There is a strong correlation between overflowing an allocation that happens to end at brk and having called realloc_brk, so I suspect that it is not setting the allocation header correctly or something.

Edit: I have finally found the issue, here's a way to reproduce it:

Code:

    minit_done:
        mov     ecx,MALLOC_SYSTEM_SIZE-4
        call    malloc
        inc     ecx
        mov     ebx,ecx
        call    realloc
        cmp     ecx,ebx
        jb      internal_error
        ret

10 Jan 2020, 21:02

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 10 Jan 2020, 22:23

Thank you! I believe I found the bug, here's my fix:

Code:

@@ -300,11 +300,11 @@
        push    rax
        call    malloc_brk
        pop     rax
        mov     edx,[eax-4]
        mov     ecx,edx
-       add     ecx,[eax+edx]
+       add     ecx,[eax+edx-4]
        mov     [eax-4],ecx
        sub     ecx,4
        ret
    realloc_and_copy:
        push    rax rdi rsi

Please let me know if it does it for you.

10 Jan 2020, 22:23

jacobly

Joined: 04 Feb 2016
Posts: 44

jacobly 11 Jan 2020, 01:50

Yep, that fixed the original crash. Also, it seems like you could just do this instead:

Code:

        push    rax
        call    malloc_brk
        pop     rax
        add     ecx,[eax-4]
        lea     edx,[ecx+4]
        mov     [eax-4],edx
        ret

11 Jan 2020, 01:50

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum