flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Elusive crash in fasmg

Author
Thread Post new topic Reply to topic
jacobly



Joined: 04 Feb 2016
Posts: 38
jacobly
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
Post 07 Jan 2020, 19:37
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7564
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 09 Jan 2020, 09:09
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 38
jacobly
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.
Post 10 Jan 2020, 07:20
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7564
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 10 Jan 2020, 09:10
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 38
jacobly
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).
Post 10 Jan 2020, 16:09
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7564
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 10 Jan 2020, 16:25
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 38
jacobly
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    
Post 10 Jan 2020, 21:02
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7564
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 10 Jan 2020, 22:23
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 38
jacobly
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    
Post 11 Jan 2020, 01:50
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.