Skip to content

Conversation

@FromLiQg
Copy link
Contributor

Try to fix bug that it read a null pointer after initialize a compilation context for fast jit failed.
When memory_allocator_alloc return NULL, jit_cc_init will call jit_cc_destroy and we try to free the memory of cc.
But we ingored to do some check for cc->entry_label that may be 0 (This represents an initialization failure.), which causes the program to read a null pointer.
PS: This PR is for internal issues #403

FromLiQg and others added 20 commits August 12, 2022 17:45
Use pointer comparison instead of struct memory comparison.
When using call_indirect, type comparison is required.
I optimized the speed of type comparison,
and changed type structure memory comparison to pointer comparison.
whitch stores the number of type references
in wasm_interp_fast.c and wasm_interp_classic.c
when "globals" initialization fails,
the memory allocated is not released, resulting in memory leakage
after initialize a compilation context for fast jit failed.
@lum1n0us
Copy link
Contributor

IIUC, form_and_translate_func() will make sure every function has an entry and an exit. So I am curious about when the new NULL check will work.

@FromLiQg
Copy link
Contributor Author

IIUC, form_and_translate_func() will make sure every function has an entry and an exit. So I am curious about when the new NULL check will work.

We use "Instrument Test" to test abnormal cases.
In this case, we force the function mem_allocator_malloc to return NULL when the specific call stack occur.
And the function form_and_translate_func() may not be called.
The detail case is in https://github.com/wasm-micro-runtime/wamr-internal-dev/issues/403.
I described the whole situation.
@lum1n0us

@xujuntwt95329
Copy link
Collaborator

xujuntwt95329 commented Aug 22, 2022

@lum1n0us This issue is found by instrumentation test (it is a destructive test to cover abnormal cases).
This bug indicates that somewhere doesn't check or deal with the return value of wasm_runtime_malloc correctly.

@FromLiQg
Copy link
Contributor Author

FromLiQg commented Aug 22, 2022

I know what you mean.
The original design was:

JitCompContext *
jit_cc_init(JitCompContext *cc, unsigned htab_size)
{
    JitBasicBlock *entry_block, *exit_block;
    unsigned i, num;

    memset(cc, 0, sizeof(*cc));
    cc->_reference_count = 1;
    jit_annl_enable_basic_block(cc);

    /* Create entry and exit blocks.  They must be the first two
       blocks respectively.  */
    if (!(entry_block = jit_cc_new_basic_block(cc, 0))
        || !(exit_block = jit_cc_new_basic_block(cc, 0)))
        goto fail;
/*ignored codes for convenience*/
    cc->entry_label = jit_basic_block_label(entry_block);
    cc->exit_label = jit_basic_block_label(exit_block);
/*ignored codes for convenience*/
fail:
    jit_cc_destroy(cc);
    return NULL;
}

And when exec entry_block = jit_cc_new_basic_block(cc, 0),it goto fail.
So cc->entry_label = 0, and I think this represent the error case. So I use this case to detect NULL.
or do we need to do something in jit_cc_new_basic_block?
But I have no idea dealing with the else case in this function to fix the bug.

JitBasicBlock *
jit_cc_new_basic_block(JitCompContext *cc, int n)
{
    JitReg label = jit_cc_new_label(cc);
    JitBasicBlock *block = NULL;

    if (label && (block = jit_basic_block_new(label, n)))
        /* Void 0 register indicates error in creation.  */
        *(jit_annl_basic_block(cc, label)) = block;
    else
        jit_set_last_error(cc, "create basic block failed");

    return block;
}

@lum1n0us

@wenyongh wenyongh merged commit 1dcc59f into bytecodealliance:main Aug 24, 2022
vickiegpt pushed a commit to vickiegpt/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
…ytecodealliance#1401)

The entry and exit basic blocks might be destroyed before they are created.
Found by instrument test. Add checks to fix the issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants