Oops, yeah.

Locally I already have related failed DCHECKs so this ain't gonna be pretty.

# Fatal error in ../../src/sandbox/sandboxed-pointer-inl.h, line 35
# Check failed: GetProcessWideSandbox()->Contains(pointer).
#
#
#
#FailureMessage Object: 0x7fad9b7e54f8
==== C stack trace ===============================

    
/sources/aapoalas/v8/v8/out/x64.debug/libv8_libbase.so(v8::base::debug::StackTrace::StackTrace()+0x1e)
 
[0x7fae87a1ef0e]
    /sources/aapoalas/v8/v8/out/x64.debug/libv8_libplatform.so(+0x5219d) 
[0x7fae8797419d]
    /sources/aapoalas/v8/v8/out/x64.debug/libv8_libbase.so(V8_Fatal(char 
const*, int, char const*, ...)+0x1ac) [0x7fae879eeeec]
    
/sources/aapoalas/v8/v8/out/x64.debug/cctest(v8::internal::WriteSandboxedPointerField(unsigned
 
long, v8::internal::PtrComprCageBase, unsigned long)+0x59) [0x5561832b6a49]
    
/sources/aapoalas/v8/v8/out/x64.debug/libv8_for_testing.so(v8::internal::HeapObject::WriteSandboxedPointerField(unsigned
 
long, v8::internal::Isolate*, unsigned long)+0x47) [0x7fae8ce2eee7]
    
/sources/aapoalas/v8/v8/out/x64.debug/libv8_for_testing.so(v8::internal::JSArrayBuffer::set_backing_store(v8::internal::Isolate*,
 
void*)+0x40) [0x7fae8da717d0]
    
/sources/aapoalas/v8/v8/out/x64.debug/libv8_for_testing.so(v8::internal::JSArrayBuffer::Attach(std::__Cr::shared_ptr<v8::internal::BackingStore>)+0x45c)
 
[0x7fae8da6e81c]

On Wednesday, 27 September 2023 at 15:18:43 UTC+3 Clemens Backes wrote:

> I guess you meant to link to https://crrev.com/c/4896678. I triggered 
> dry-runs, let's see what happens.
>
> On Wed, Sep 27, 2023 at 2:12 PM Aapo Alasuutari <aapo.al...@gmail.com> 
> wrote:
>
>> Thank you for the response!
>>
>> Hopefully this was then much easier than I even expected. I opened this 
>> CL: https://groups.google.com/g/v8-dev/c/wuncGizO1EU
>> Unfortunately I'm not a dry-runner so I cannot start try-bots on this 
>> myself. I'll try running some tests locally at least.
>>
>> -Aapo
>>
>> On Wednesday, 27 September 2023 at 14:15:23 UTC+3 Clemens Backes wrote:
>>
>>> This is the place where we store the special "empty backing store 
>>> buffer" in the ArrayBuffer if the passed BackingStore is empty:
>>>
>>> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/objects/js-array-buffer.cc;l=82;drc=57bf7660f3e50a0f68f329059f0dff8f641effc4
>>>
>>> In a non-sandbox build, this will just store nullptr.
>>>
>>> That said, I can't tell you why we have this optimization and which 
>>> part(s) of the system depend on that. As the backing store is kept alive by 
>>> the ArrayBuffer anyway, I guess we could also just store the actual 
>>> buffer's start in the ArrayBuffer::backing_store field.
>>> Waiting to be corrected :) 
>>>
>>> On Wed, Sep 27, 2023 at 11:22 AM Aapo Alasuutari <aapo.al...@gmail.com> 
>>> wrote:
>>>
>>>> Hello
>>>>
>>>> I'm trying to take a look at the `v8::ArrayBuffer::Data()` method with 
>>>> the intention of fixing this bug: 
>>>> https://bugs.chromium.org/p/v8/issues/detail?id=13488 (and by 
>>>> extension possibly unblock 
>>>> https://bugs.chromium.org/p/v8/issues/detail?id=13489)
>>>>
>>>> Put it short: The method returns a null pointer for all zero-length 
>>>> buffers even when the ArrayBuffer is internally backed by an external 
>>>> pointer. These sorts of externally backed zero-length buffers are 
>>>> sometimes 
>>>> used in eg. Node API to pass opaque pointers to and from JavaScript. 
>>>> Getting the proper pointer requires using the 
>>>> `v8::ArrayBuffer::GetBackingStore()` API, after which its `Data()` API 
>>>> returns the real external pointer.
>>>>
>>>> I've been trying to track where this difference springs from but 
>>>> haven't had much success. The `Data()` method calls the `backing_store()` 
>>>> method of a `i::Handle<i::JSArrayBuffer>` which I _think_ is defined with 
>>>> the `DEF_GETTER` macro in `js-array-buffer-inl.h` line 48:
>>>>
>>>> DEF_GETTER(JSArrayBuffer, backing_store, void*) {
>>>>   Address value = ReadSandboxedPointerField(kBackingStoreOffset, 
>>>> cage_base);
>>>>   return reinterpret_cast<void*>(value);
>>>> }
>>>>
>>>> But here I get confused: `ReadSandboxedPointerField` (in 
>>>> `sandboxed-pointer-inl.h`) seems simple enough that there should be 
>>>> absolutely no checks against the length of the buffer, nor does it seem 
>>>> particularly likely for the backing store offset parameter to be somehow 
>>>> wrong.
>>>>
>>>> If anyone has an idea of where I should look into, that'd be much 
>>>> appreciated
>>>> -Aapo Alasuutari
>>>>
>>>> -- 
>>>> -- 
>>>> v8-dev mailing list
>>>> v8-...@googlegroups.com
>>>> http://groups.google.com/group/v8-dev
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "v8-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to v8-dev+un...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/v8-dev/350ede0e-0c6d-433e-b9b3-a85525c7049fn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/v8-dev/350ede0e-0c6d-433e-b9b3-a85525c7049fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>>
>>> Clemens Backes
>>>
>>> Software Engineer
>>>
>>> clem...@google.com
>>>
>>> Google Germany GmbH
>>>
>>> Erika-Mann-Straße 33
>>>
>>> 80636 München
>>>
>>> Geschäftsführer: Paul Manicle, Liana Sebastian   
>>>
>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>
>>> Sitz der Gesellschaft: Hamburg
>>>
>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten 
>>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, 
>>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, 
>>> dass die E-Mail an die falsche Person gesendet wurde.
>>>
>>>
>>> This e-mail is confidential. If you received this communication by 
>>> mistake, please don't forward it to anyone else, please erase all copies 
>>> and attachments, and please let me know that it has gone to the wrong 
>>> person.
>>>
>>>
>>> -- 
>> -- 
>> v8-dev mailing list
>> v8-...@googlegroups.com
>> http://groups.google.com/group/v8-dev
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to v8-dev+un...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/v8-dev/25a7a109-5b44-4250-b5f2-bc060ef307b4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/v8-dev/25a7a109-5b44-4250-b5f2-bc060ef307b4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
>
> Clemens Backes
>
> Software Engineer
>
> clem...@google.com
>
> Google Germany GmbH
>
> Erika-Mann-Straße 33
>
> 80636 München
>
> Geschäftsführer: Paul Manicle, Liana Sebastian   
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Sitz der Gesellschaft: Hamburg
>
> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten 
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, 
> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, 
> dass die E-Mail an die falsche Person gesendet wurde.
>
>
> This e-mail is confidential. If you received this communication by 
> mistake, please don't forward it to anyone else, please erase all copies 
> and attachments, and please let me know that it has gone to the wrong 
> person.
>
>
>

-- 
-- 
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-dev/ff5a737c-76fd-42a9-83d5-288df13f7ae4n%40googlegroups.com.

Reply via email to