FileReader sometimes encounters NotReadableError when loading large blob

NEW
Unassigned

Status

()

Core
DOM
P2
normal
11 months ago
10 months ago

People

(Reporter: mstange, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox54 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
Created attachment 8833699 [details]
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.
(Reporter)

Comment 1

11 months ago
(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

10 months ago
Andrea, any chance you can take a look at this please?  Thank you!
Flags: needinfo?(amarchesini)
(Reporter)

Comment 3

10 months ago
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.
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
Flags: needinfo?(amarchesini)
Priority: -- → P2

Comment 5

10 months ago
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?)
(Reporter)

Comment 6

10 months ago
The addon that I attached always downloads the same symbols.
You need to log in before you can comment on or make changes to this bug.