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

Conversation

robertsipka
Copy link
Contributor

JerryScript-DCO-1.0-Signed-off-by: Robert Sipka rsipka.uszeged@partner.samsung.com

JerryScript-DCO-1.0-Signed-off-by: Robert Sipka rsipka.uszeged@partner.samsung.com
@zherczeg
Copy link
Member

Please add some regression test for this.

@LaszloLango LaszloLango added bug Undesired behaviour ecma core Related to core ECMA functionality labels Apr 15, 2016
@@ -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

@zherczeg
Copy link
Member

Is this issue still valid?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Undesired behaviour ecma core Related to core ECMA functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants