vnmakarov / mir

A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
MIT License
2.24k stars 147 forks source link

crash inside _MIR_duplicate_func_insns #319

Closed Itay2805 closed 1 year ago

Itay2805 commented 1 year ago

I have a very weird crash inside of _MIR_duplicate_func_insns, when I call MIR_gen on a function, that is caused from a label operand having a NULL value. after a bit of debugging I see that in redirect_duplicated_labels, when it is called from process_inlines, the label is being set to null by the following code (aka insn->ops[n].u.label->data is NULL):

insn->ops[n].u.label = insn->ops[n].u.label->data;

this is the state of the IR just before the following instruction is processed (done by using MIR_output_func at the end of the previous iteration) (this is the instruction in func_insn):

call    [Corelib-v1]System.Threading.ThreadStart::Invoke()$proto, [Corelib-v1]System.Threading.ThreadStart::Invoke(), .c4_ti0

This part is formed from the following inlines, you can see that RunWorker has inside of it the following code:

    call    [Corelib-v1]System.Threading.ThreadStart::Invoke()$proto, [Corelib-v1]System.Threading.ThreadStart::Invoke(), ti0
L801:
    jmp L25

is indeed inlined into Callback, and the problem is that specifically after processing that inlined call instruction the jmp L25 is turned into a jmp NULL.

I am still trying to debug the issue and figure what it is and if there is an easy way to reproduce it, but figured I would at least post what I have so far, will update if I find anything from more debugging

Itay2805 commented 1 year ago

ok the issue was with my generation, I had a label I jump to but I don't actually place it in the function, this could have been avoided with a better check at link time that every jump has a destination inside the same function but its not a bug so I am closing this issue