[Webkit-unassigned] [Bug 58443] [GTK] Support the file system API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=58443





--- Comment #4 from Zan Dobersek <zandobersek at gmail.com>  2011-07-26 11:53:10 PST ---
Created an attachment (id=102035)
 --> (https://bugs.webkit.org/attachment.cgi?id=102035&action=review)
WIP patch

This is a work-in-progress patch that brings support for FileSystem API to Gtk port.

This is a first implementation (AFAIK) for a port that uses JavaScriptCore so some fixes were needed in bindings/js. The only other port to implement this feature is Chromium, so some changes (for instance those in LocalFileSystem class) should be discussed to avoid any problems. Also to discuss are the possible security problems and additional API for Gtk port.

AsyncFileSystemGtk, AsyncFileWriterGtk and AsyncFileWriterClientGtk are implemented. Two helper classes are also added - AsyncFileSystemTaskControllerGtk and AsyncFileSystemCallbacksGtk. The first controls posting tasks to ScriptExecutionContext (either a Document object or a Worker) and the second is used to wrap normal callbacks and properly execute them using a task controller.

With this patch non-worker tests in fast/filesystems/ (24 of them) pass flawlessly. When running a single worker test, for example async-operations.html, repeating it 5 times, the second time the test fails because of a malformed EntryArray object (object has undefined length when there are actual entries that were read) and the third time the test crashes because of what appears to be an already freed HashEntry key. Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.  
[Switching to Thread 0x7fff9cd31700 (LWP 15534)]
0x00007ffff4458540 in JSC::HashEntry::key (this=0x72) at ../../Source/JavaScriptCore/runtime/Lookup.h:76
76              StringImpl* key() const { return m_key; }
#0  0x00007ffff4458540 in JSC::HashEntry::key (this=0x72) at ../../Source/JavaScriptCore/runtime/Lookup.h:76
No locals.
#1  0x00007ffff44586fb in JSC::HashTable::entry (this=0x7ffff750a020, identifier=...)
    at ../../Source/JavaScriptCore/runtime/Lookup.h:169
        __PRETTY_FUNCTION__ = "const JSC::HashEntry* JSC::HashTable::entry(const JSC::Identifier&) const"
        entry = 0x72
#2  0x00007ffff4458640 in JSC::HashTable::entry (this=0x7ffff750a020, exec=0x7fff9b9300c0, identifier=...)
    at ../../Source/JavaScriptCore/runtime/Lookup.h:155
No locals.
#3  0x00007ffff529756e in WebCore::JSEntryArray::getOwnPropertySlot (this=0x7ffff7ecba38, exec=0x7fff9b9300c0, 
    propertyName=..., slot=...) at DerivedSources/WebCore/JSEntryArray.cpp:165
        entry = 0x7fff9cd30310
        ok = false
        index = 4425488
#4  0x00007ffff77e67e5 in JSC::JSCell::fastGetOwnPropertySlot (this=0x7ffff7ecba38, exec=0x7fff9b9300c0, 
    propertyName=..., slot=...) at ../../Source/JavaScriptCore/runtime/JSObject.h:536
No locals.
#5  0x00007ffff785c39f in JSC::JSValue::get (this=0x7fff9cd30430, exec=0x7fff9b9300c0, propertyName=..., slot=...)
    at ../../Source/JavaScriptCore/runtime/JSObject.h:788
        prototype = {u = {asInt64 = 0, ptr = 0x0, asBits = {payload = 0, tag = 0}}}
        cell = 0x7ffff7ecba38
#6  0x00007ffff788b736 in JSC::cti_op_get_by_id (args=0x7fff9cd30480)
---Type <return> to continue, or q <return> to quit---
    at ../../Source/JavaScriptCore/jit/JITStubs.cpp:1563
        stackHack = {stackFrame = @0x7fff9cd30480, savedReturnAddress = {m_value = 0x7fff9d950c68}}
        callFrame = 0x7fff9b9300c0
        slot = {m_getValue = 0x7fff9b930118, m_getIndexValue = 0x2, m_slotBase = {u = {asInt64 = 140737352874552, 
              ptr = 0x7ffff7ecba38, asBits = {payload = -135480776, tag = 32767}}}, m_data = {getterFunc = 0xdf8350, 
            index = 14648144}, m_value = {u = {asInt64 = 0, ptr = 0x0, asBits = {payload = 0, tag = 0}}}, 
          m_thisValue = {u = {asInt64 = 0, ptr = 0x0, asBits = {payload = 0, tag = 0}}}, m_offset = 0, 
          m_cachedPropertyType = JSC::PropertySlot::Uncacheable}
        stubInfo = 0x7fff9cd30480
        stackFrame = @0x7fff9cd30480
        ident = @0xdf5550
        baseValue = {u = {asInt64 = 140737352874552, ptr = 0x7ffff7ecba38, asBits = {payload = -135480776, 
              tag = 32767}}}
        result = {u = {asInt64 = 140735824462960, ptr = 0x7fff9cd30470, asBits = {payload = -1663892368, 
              tag = 32767}}}
        codeBlock = 0x7fff9cd30480
#7  0x00007ffff7889d65 in JSC::JITThunks::tryCacheGetByID (callFrame=0x7fff9cd303a0, codeBlock=0x7fff9cd303d0, 
    returnAddress=..., baseValue=..., propertyName=..., slot=..., stubInfo=0x7ffff7ecba38)
    at ../../Source/JavaScriptCore/jit/JITStubs.cpp:941
No locals.
#8  0x00007fff9cd304b0 in ?? ()
.
.
.

This might be a problem in how AsyncFileSystemTaskControllerGtk utilizes workers or maybe even how JavaScriptCore implements them. Given all the worker tests pass when running with --singly flag it might be a matter of a hash table not cleared or something similar ...

Throughout the patch there might be memory leaks and debugging leftovers. This is a work-in-progress patch, not meant for review, but don't worry, such things will be fixed or removed before a patch is posted for reviewing.

I am open to discussion about approach and fixing the worker crashes.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.