1336767 - FileReader sometimes encounters NotReadableError when loading large blob

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Markus Stange [:mstange]]

Attachment: reproducible_filereadererror.xpi

The Gecko profiler addon is currently doing the equivalent of:

  (new Promise((resolve, reject) => {
    const request = new XMLHttpRequest();
    request.open('GET', 'http://symbols.mozilla.org/XUL/6CC2672F40693090A854495DE61B4BA80/XUL.sym', true);
    request.responseType = 'blob';
    request.onload = () => {
      if (request.status != 200) {
        reject(new Error(`got error status ${request.status}`));
      } else {
        resolve(request.response);
      }
    };
    request.onerror = reject;
    request.send();
  })).then(symbolDump => {
    return new Promise((resolve, reject) => {
      const reader = new FileReader();
      reader.onload = () => resolve(new Uint8Array(reader.result));
      reader.onerror = error => {
        // This is called, with error being a ProgressEvent, and
        // reader.error.name == 'NotReadableError'.
        reject(reader.error);
      };
      reader.readAsArrayBuffer(symbolDump);
    });
  });

I'm attaching a modified version of the gecko profiler addon that executes this code (with a bit of indirection) on startup. (And when the addon is disabled and re-enabled.) It's unsigned so you need to set the pref xpinstall.signatures.required to false.

I've debugged this a little and got here:

(lldb)
Process 19955 stopped
* thread #1: tid = 0x774345, 0x0000000115c67d62 XUL`mozilla::dom::FileReader::OnLoadEnd(this=0x0000000129af6980, aStatus=NS_OK) + 130 at FileReader.cpp:667, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x0000000115c67d62 XUL`mozilla::dom::FileReader::OnLoadEnd(this=0x0000000129af6980, aStatus=NS_OK) + 130 at FileReader.cpp:667
   664    // In case we read a different number of bytes, we can assume that the
   665    // underlying storage has changed. We should not continue.
   666    if (mDataLen != mTotal) {
-> 667      FreeDataAndDispatchError(NS_ERROR_FAILURE);
   668      return NS_OK;
   669    }
   670
(lldb) p mDataLen
(uint32_t) $17 = 197195800
(lldb) p mTotal
(uint64_t) $18 = 214696529

This looks very similar to bug 1333384.

It's fairly well reproducible with my main profile on Mac.

Comment 1

[Markus Stange [:mstange]]

(I'm going to change the profiler to use request.responseType = 'arraybuffer' instead, but I wanted to file this because it seems like a bad bug.)

Comment 2

[(no longer active)]

Andrea, any chance you can take a look at this please?  Thank you!

Comment 3

[Markus Stange [:mstange]]

Andrea told me that he hasn't been able to reproduce it yet. I can try to reduce the addon some more and maybe find a regression range.

Comment 4

[Andrea Marchesini [:baku]]

I'm not able to reproduce this issue. I tried to install, uninstall, disable, enable the addon, but nothing happens. I always see:

fetching symbol dump for library XUL 6CC2672F40693090A854495DE61B4BA80 from http://symbols.mozilla.org/XUL/6CC2672F40693090A854495DE61B4BA80/XUL.sym
using responseType blob
received symbol dump for XUL 6CC2672F40693090A854495DE61B4BA80

Comment 5

[(no longer active)]

The symbols downloaded are obviously platform dependent.  It may be that the bug doesn't repro under Linux (I assume that's the OS you're running?)

Comment 6

[Markus Stange [:mstange]]

The addon that I attached always downloads the same symbols.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information