Skip to content

Set the correct pointer value in 'ecma_copy_ecma_string' function. #1010

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion jerry-core/ecma/base/ecma-helpers-string.c
Original file line number Diff line number Diff line change
Expand Up @@ -422,7 +422,7 @@ ecma_copy_ecma_string (ecma_string_t *string_desc_p) /**< string descriptor */
ecma_string_heap_header_t *new_data_p = (ecma_string_heap_header_t *) mem_heap_alloc_block (data_size);
memcpy (new_data_p, data_p, data_p->size + sizeof (ecma_string_heap_header_t));

ECMA_SET_NON_NULL_POINTER (new_str_p->u.collection_cp, data_p);
ECMA_SET_NON_NULL_POINTER (new_str_p->u.collection_cp, new_data_p);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question: is this the only issue in this code block? I'm not familiar with this function but we have *new_str_p = *string_desc_p; above. That copies over refs_and_container, hash, and u.collection_cp. The latter will be overwritten (fixed in this patch), hash does not change. What about the reference count? Is that OK not to (re)set?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just check the comment at the beginning:
@return pointer to copy of ecma-string with reference counter set to 1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So probably copying the refcounter is also a bug. I had a feelewng that this is an untested code path. That is why we need a reftest.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the comment. But where is it set to 1 in this code path?

Copy link
Member

@zherczeg zherczeg Apr 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this is probably another bug. Good catch. We definitely need a reftest for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that it is possible to construct a regression test case that can catch the refcount issue... It seems to me that this will be "just" eating up memory but not cause any semantic error. I'd be glad to be proven wrong though.

(The pointer issue is different. That might be possible to catch.)

Copy link
Member

@zherczeg zherczeg Apr 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here the problem is that there is a reference to the old string. A regression test would look like this:

var a = "string";
var b = [];
for (i = 0; i < 10000; i++) b[i] = a;
gc();
for (i = 0; i < 9000; i++) b[i] = null;
gc(); // could be a crash


break;
}
Expand Down