New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 799917 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug

Blocking:
issue 757440



Sign in to add a comment

Member pointing to WTF containers is incorrect

Project Member Reported by mlippautz@chromium.org, Jan 8 2018

Issue description

Containers, such as HeapVector, explicitly define themselves to be GarbageCollected through the macro "IS_GARBAGE_COLLECTED_TYPE()"

This allows Members to point to such containers, which is not correct as Member assumes that the pointer is pointing to an on-heap object and will crash during marking the object as there is no header/page on Oilpan's heap.

Additionally, this will also break with the incremental marking barrier.

For HeapVector:
- Codesearch [1]
- Crash example in [2]

Similar restrictions hold for all Heap* containers.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/events/TreeScopeEventContext.h?type=cs&q=%22Member%3CHeapVector%22&l=96&ssfr=1
[2] https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20EXISTS%20(SELECT%201%20FROM%20UNNEST(CrashedStackTrace.StackFrame)%20WHERE%20FunctionName%20LIKE%20%27%25TreeScopeEventContext%25%27)&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=492c1c537e927e15&index=3#0
 
Status: WontFix (was: Assigned)
I figured out that this actually works.

The reason is the override for the allocator "USE_ALLOCATOR" in the collections which allocates them also on the managed heap. This also means that Member<HeapVector<...>> is a valid construct.

Sign in to add a comment