fix bug of "deref bytecode twice" in jerry_exec_snapshot

[jiangzidong]

in jerry_exec_snapshot, if the snapshot is is_run_eval, then the bytecode will deref in vm_run_eval. The jerry_exec_snapshot shouldn't call deref function after vm_run_eval.

JerryScript-DCO-1.0-Signed-off-by: Zidong Jiang zidong.jiang@intel.com

[LaszloLango]

Thanks for the fix. Please add a unit test for this issue.

[zherczeg]

LGTM

[jiangzidong]

Both global mode and eval mode will return the value of the last js statement. Is it what we expect?

[LaszloLango]

yes

[LaszloLango]

LGTM

[LaszloLango]

@jiangzidong, please squash your commits and rebase to the current master, so I can land it properly.

[jiangzidong]

@LaszloLango done

[jiangzidong]

Actually, I think the unit-test-api.c can't perfectly detect we are derefing the bytecode which is already freed.
in ecma_bytecode_deref, we have JERRY_ASSERT (bytecode_p->refs > 0).
When the bytecode's refs become 0, it will call jmem_heap_free_block, and the its original heap space become free_heap (jmem_heap_free_t), and then bytecode_p become a dangling pointer, the value of bytecode_p->refs will be a part of the jmem_heap_free_t->next_offset.
Then, when the same bytecode is called deref by mistake, whether the JERRY_ASSERT (bytecode_p->refs > 0) detect the error depends on whether the part of the next_offset address is 0. In my host envirenment, it's 0 luckily, and it throw error. But if the part of address is above 0, then the jmem_heap_free_t->next_offset will be changed because of the following bytecode_p->refs--, and the

I can't find a proper ASSERT to detect whether the bytecode_p is dangling pointer. Do you have any suggestion?

[zherczeg]

I think this issue cannot be helped, since a memory allocator is free to do anything with the memory block after it is freed. A valgrind like "do not reuse memory" allocator could help, but that would require a new allocator for jerry.