Common error: Array buffer allocation failed #895

dcposch · 2016-09-02T03:30:07Z

WebTorrent version: 0.96
Environment version: Electron 1.3.3

This is currently the most frequent uncaught error in the WebTorrent Desktop telemetry. It comes from the underlying library.

Processes: webtorrent, platforms: win32, versions: 0.13.1 
RangeError: Array buffer allocation failed
    at Buffer.Uint8Array (native)
    at FastBuffer (buffer.js:8:1)
    at createUnsafeBuffer (buffer.js:33:12)
    at allocate (buffer.js:176:12)
    at Function.Buffer.allocUnsafe (buffer.js:136:10)
    at Function.Buffer.concat (buffer.js:326:23)
    at ...\app.asar\node_modules\fs-chunk-store\index.js:200:23
    at end (...\node_modules\run-parallel\index.js:16:15)
    at done (...\node_modules\run-parallel\index.js:20:10)
    at each (...\node_modules\run-parallel\index.js:26:7)

As you can see above, we've only seen this error on Windows.

One reason why a buffer allocation can fail is because the OS is out of memory. I don't think that's the case here, though. It affects even systems with lots of memory:

$ cat telemetry/2016-09-01.log | grep "Array buffer allocation" | jq .system.totalMemoryMB | sort -n | uniq -c
<hand edited to round to the nearest GB:>
   6 4GB
   6 8GB
   3 16GB
   1 24GB
   3 32GB

Finally, when this bug starts happening to someone, it tends to happen a lot. Of the ~4000 WebTorrent Desktop telemetry reports from yesterday, only 19 contained this error, but each of those had an average of about 10 "Array buffer allocation failed" errors.

dcposch · 2016-09-02T03:33:39Z

@feross

dcposch · 2016-09-02T03:48:36Z

I think I know why this is happening. This is because we're packing the Windows app as a 32-bit app, where we run out of address space after only 4GB of memory use. Maybe we can also fail to allocate a buffer before then if there isn't a big enough block of continuous memory available.

I just grepped all past logs. We've seen 303 distinct sessions that have this error and they're all on Windows, with process.platform equal to ia32.

Ideas for how to fix this in `webtorrent.js` / `fs-chunk-store`

Limit the amount of data that will be stored in RAM at any given time
If a buffer allocation fails, evict data and try again. (It can always be read from the underlying file again later.)

DiegoRBaquero · 2016-09-02T13:19:09Z

@dcposch Why not package it as 64-bit (too) ?

feross · 2016-09-15T00:00:08Z

@dcposch Nice sleuthing! 👍

One additional piece of data that would be worth having: Approximately how many torrents did these users have in the app? Even if we keep memory usage low for each active torrent (say ~50MB) we'll still start to feel squeezed for memory once they add around 40 torrents, and run completely out at 80 torrents.

We try to use as little memory as possible, but I believe that we keep torrent pieces that are currently being downloaded in memory until they're complete (i.e. all the blocks inside the piece are received). So for active torrents, there could be 5-10 pieces in memory, at a couple MB each (for an average torrent under 10GB), hence the 50MB number.

@DiegoRBaquero Here's some context for why we made the decision to go with 32-bit in WD: webtorrent/webtorrent-desktop#437 (comment) Basically, users don't know which installer to use. We thought that 32-bit would have no issues.

disarticulate · 2017-10-22T16:12:02Z

I'm getting this, along with the create-torrent:

index.js?12e3:77 Uncaught RangeError: Array buffer allocation failed
    at new ArrayBuffer (<anonymous>)
    at typedArrayConstructByLength (<anonymous>)
    at new Uint8Array (native)
    at createBuffer (webpack-internal:///3:77:12)
    at allocUnsafe (webpack-internal:///3:200:10)
    at Function.Buffer.allocUnsafe (webpack-internal:///3:213:10)
    at Function.concat (webpack-internal:///3:395:23)
    at Block._transform (webpack-internal:///273:30:24)
    at Block.Transform._read (webpack-internal:///279:182:10)
    at Block.Transform._write (webpack-internal:///279:170:83)

It appears on chrome quickly, on firefox after about 5-6 5-6mb files.

webtorrent/create-torrent#63

I've got a webpack build with v.0.98.20 under linux, chrome 61.0.3163.100 64 Bit and Firefox 56.0 64-bit

Thought there might be an issue with Webpack so I put the latest Webtorrent in a script tag, and still get:

webtorrent.min.js:3 Uncaught RangeError: Array buffer allocation failed
    at new ArrayBuffer (<anonymous>)
    at typedArrayConstructByLength (<anonymous>)
    at new Uint8Array (native)
    at r (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:5422)
    at u (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:6111)
    at Function.o.allocUnsafe (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:14174)
    at Function.o.concat (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:14958)
    at r._transform (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:2625)
    at r.i._read (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:6:15974)
    at r.i._write (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:6:15820)

This is what's being passed:

tor-upload-btn.vue?f15d:83 (2) [Uint8Array(2943868), Uint8Array(1813)]
(anonymous) @ tor-upload-btn.vue?f15d:83
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:84 PANO_20160525_154617.jpg
(anonymous) @ tor-upload-btn.vue?f15d:84
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:83 (2) [Uint8Array(2943868), Uint8Array(1813)]
(anonymous) @ tor-upload-btn.vue?f15d:83
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:84 PANO_20160525_154617.jpg.geojson
(anonymous) @ tor-upload-btn.vue?f15d:84
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
index.js?5057:60 1508693677193--cbh3tftckj92-af1ce0a00c-af1ce0a00c o {_events: {…}, _maxListeners: undefined, _debugId: "2c1580b", client: o, announce: Array(8), …}
worker.js?3874:140 findDataByKey 1508693677251--cbh3tfwsrcc8-af1cecd0eb-af1cecd0eb undefined
worker.js?3874:156 findDataByKey 1508693677251--cbh3tfwsrcc8-af1cecd0eb-af1cecd0eb {geohash: "cbh3tfwsrcc8", begin: "af1cecd0eb", cease: "af1cecd0eb", url: "/g/cbh3tfwsrcc8/af1cecd0eb/af1cecd0eb", name: "PANO_20160526_103235.jpg", …}
viewer2.vue?04aa:81 {geohash: "cbh3tfwsrcc8", begin: "af1cecd0eb", cease: "af1cecd0eb", url: "/g/cbh3tfwsrcc8/af1cecd0eb/af1cecd0eb", name: "PANO_20160526_103235.jpg", …}
tagInput.vue?a214:46 tagInput string
tor-upload-btn.vue?f15d:83 (2) [Uint8Array(5121013), Uint8Array(1813)]
(anonymous) @ tor-upload-btn.vue?f15d:83
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:84 PANO_20160526_103235.jpg
(anonymous) @ tor-upload-btn.vue?f15d:84
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:83 (2) [Uint8Array(5121013), Uint8Array(1813)]
(anonymous) @ tor-upload-btn.vue?f15d:83
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
tor-upload-btn.vue?f15d:84 PANO_20160526_103235.jpg.geojson
(anonymous) @ tor-upload-btn.vue?f15d:84
uploadFile @ tor-upload-btn.vue?f15d:82
boundFn @ vue.esm.js?efeb:179
invoker @ vue.esm.js?efeb:1821
webtorrent.min.js:3 Uncaught RangeError: Array buffer allocation failed
    at new ArrayBuffer (<anonymous>)
    at typedArrayConstructByLength (<anonymous>)
    at new Uint8Array (native)
    at r (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:5422)
    at u (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:6111)
    at Function.o.allocUnsafe (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:14174)
    at Function.o.concat (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:14958)
    at r._transform (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:3:2625)
    at r.i._read (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:6:15974)
    at r.i._write (https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js:6:15820)

disarticulate · 2017-10-22T17:47:24Z

When I look at the Uint8Array and try to get the buffer I get

[Exception: TypeError: Method get %TypedArray%.prototype.buffer called on incompatible receiver [object Object] at Uint8Array.get buffer [as buffer] (<anonymous>) at Uint8Array.remoteFunction (<anonymous>:2:14)]

they're being created by:

          let buffer = Buffer.from(stringify(item), 'utf-8')
          buffer.name = vm.filenames[index] || vm.getName(item)

disarticulate · 2017-10-22T17:52:25Z

One of the files is an ArrayBuffer from a regular file upload:


ArrayBuffer
name
:
"IMG_20160531_124746.jpg"
path
:
["IMG_20160531_124746.jpg"]

disarticulate · 2017-10-22T18:55:42Z

When inspect the Memory in chrome I get what appears to be duplicated Buffers of all the same Alloc. Size:

backing_store in ArrayBuffer @859431	23	800 %	204 8800 %
buffer in Uint8Array @858979	22	800 %	204 9920 %
[150] in Array @858675	21	320 %	32 717 80624 %
val in system / Context @837155	20	1120 %	32 718 11024 %
context in reactiveSetter() @837037	19	720 %	720 %
set chunks in n @837021	18	240 %	32 720 58224 %
val in system / Context @857631	17	1120 %	32 720 88624 %
context in reactiveSetter() @837079	16	720 %	720 %
set store in n @837061	15	240 %	32 725 37424 %
val in system / Context @816225	14	1120 %	32 725 67824 %
context in reactiveSetter() @813615	13	720 %	720 %
set store in o @722763	12	240 %	33 087 45324 %
[0] in Array @732143	11	320 %	9680 %
val in system / Context @727407	10	1120 %	1 2720 %
context in reactiveSetter() @727409	9	720 %	720 %
set torrents in o @731911	8	240 %	9 5680 %
val in system / Context @727217	7	1120 %	9 7280 %
context in reactiveSetter() @727219	6	720 %	720 %
set client in @728249	5	240 %	11 5280 %

 

system / JSArrayBufferData @859433 | • |   |   | 204 800 |   |   |  
-- | -- | -- | -- | -- | -- | -- | --
system / JSArrayBufferData @859639 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @859821 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @859971 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @860121 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @860271 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @860369 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @861135 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @861563 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @861713 | • |   |   | 204 800 |   |   |  
system / JSArrayBufferData @861863 | • |   |   | 204 800

Memory use appears to increase geometrically sometimes.

89.6->129->168->199

These are just 1-6 mb files. Empirically, there shouldn't be 40mb of overheade

disarticulate · 2017-10-22T20:41:11Z

So to boil it down, I put this together:

<!DOCTYPE html>
<html lang="en">
  <head>
  	<script src="https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js"></script>
  	<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.min.js"></script>
  </head>
<body>
	<canvas id="pixel"></canvas>
</body>
<script>
console.log(_)
var client = new WebTorrent()
var pixelsSrc = document.getElementById('pixel')

pixelsSrc.width = 50
pixelsSrc.height = 50

var context = pixelsSrc.getContext("2d")
context.fillRect(0, 0, 5, 5)
context.fillRect(5, 5, 5, 5)
var [i,j,k] = [0,0,0]
var blobSize = 0

function t() {
  i++
  j++
  k++
  context.fillRect(i, 5, j, k)
  context.fillStyle = `rgba(${i}, ${j}, ${k}, .5)`
  var blob = new Blob([pixelsSrc.toDataURL()], {type:'image/png'})
  blobSize += blob.size
  console.log(i,j,k, blobSize)
  client.seed(blob, {}, function(torrent){
	console.log(torrent)
  })
}

var s = 0
function myLoop () {           //  create a loop function
   setTimeout(function () {    //  call a 3s setTimeout when the loop is called
      t()					   //  your code here
      s++;                     //  increment the counter
      if (s < 100) {            //  if the counter < 10, call the loop function
         myLoop();             //  ..  again which will trigger another 
      }                        //  ..  setTimeout()
   }, 1000)
}
myLoop()
</script>

It crashes pretty quickly with very little memory use. Not sure it's the same thing as there's no error message printed, but I'd expect 6-7 buffers arn't significant?


        Test multiple Megabyte files and memory usage

I'm not sure how to test this beyond inspecting the browser. On Chrome I get a Memory footprint of 978 MB with zuul test framework I've also documented buffer overflows here: webtorrent#895 There's some kind of exponential duplication


        Test multiple Megabyte files and memory usage

I'm not sure how to test this beyond inspecting the browser. On Chrome I get a Memory footprint of 978 MB with zuul test framework I've also documented buffer overflows here: webtorrent#895 There's some kind of exponential duplication

disarticulate · 2017-10-26T00:07:10Z

i've got a test up here:
https://github.com/disarticulate/webtorrent/blob/master/test/browser/large-file.js

It looks like the issue in the browser is an exponential increase in memory usage, from JSArrayBufferData according to the chrome heapsnapshots.

The functional software that determines piece length:
https://github.com/disarticulate/piece-length

Is calculating inordinately small pieces (based on whatever the bug is.

pieceLength	file sizes (3)	memory size
1000000	7.5MB	101MB
100000	7.5MB	213MB
10000	7.5MB	1624MB

The quick fix if you're Generating a seed is to up the piece length.

If you're adding and downloading, small piece length torrents are going to eat up the memory leak(?).

balajiHms · 2018-04-03T04:59:49Z

I have been facing same issue.
I have created desktop application using electron.In that i have used pptxgen.js which is for making PPT generation using JavaScript.
I got mentioned error and application has been crashed.
"ERROR Error: Uncaught (in promise): RangeError: Array buffer allocation failed"

If anyone knows the solution kindly help me.

stale · 2018-07-02T05:07:31Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

feross · 2019-08-04T17:29:48Z

We're going to start shipping 64-bit only in WebTorrent Desktop, so I expect this error will go away for almost all users.

feross · 2019-08-04T17:36:42Z

See: webtorrent/webtorrent-desktop#1637

dcposch changed the title ~~Common error: Ar~~ Common error: Array buffer allocation failed Sep 2, 2016

dcposch mentioned this issue Sep 2, 2016

Common error: Array buffer allocation failed #873

Closed

feross mentioned this issue Jan 29, 2017

webseed download speed not reported #1006

Closed

This was referenced Oct 26, 2017

Uncaught RangeError: Array buffer allocation failed webtorrent/create-torrent#63

Closed

Allocation failed #1186

Closed

Window Crashes and Seeding Stops after a few Consecutive Seeds #1118

Closed

WebTorrent v1.0.0 #668

Open

stale bot added the stale label Jul 2, 2018

stale bot closed this Jul 9, 2018

lock bot locked as resolved and limited conversation to collaborators Oct 7, 2018

webtorrent unlocked this conversation Aug 4, 2019

webtorrent / webtorrent

Common error: Array buffer allocation failed #895

Common error: Array buffer allocation failed #895

dcposch commented Sep 2, 2016 •

edited

This comment has been minimized.

dcposch commented Sep 2, 2016

This comment has been minimized.

dcposch commented Sep 2, 2016 •

edited

This comment has been minimized.

DiegoRBaquero commented Sep 2, 2016

This comment has been minimized.

feross commented Sep 15, 2016

This comment has been minimized.

disarticulate commented Oct 22, 2017 •

edited

This comment has been minimized.

disarticulate commented Oct 22, 2017 •

edited

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 26, 2017

This comment has been minimized.

balajiHms commented Apr 3, 2018

This comment has been minimized.

stale bot commented Jul 2, 2018

This comment has been minimized.

feross commented Aug 4, 2019

This comment has been minimized.

feross commented Aug 4, 2019

webtorrent / webtorrent

Sponsor webtorrent/webtorrent

Track tasks and feature requests

Common error: Array buffer allocation failed #895

Common error: Array buffer allocation failed #895

Comments

dcposch commented Sep 2, 2016 • edited

This comment has been minimized.

dcposch commented Sep 2, 2016

This comment has been minimized.

dcposch commented Sep 2, 2016 • edited

Ideas for how to fix this in webtorrent.js / fs-chunk-store

This comment has been minimized.

DiegoRBaquero commented Sep 2, 2016

This comment has been minimized.

feross commented Sep 15, 2016

This comment has been minimized.

disarticulate commented Oct 22, 2017 • edited

This comment has been minimized.

disarticulate commented Oct 22, 2017 • edited

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 22, 2017

This comment has been minimized.

disarticulate commented Oct 26, 2017

This comment has been minimized.

balajiHms commented Apr 3, 2018

This comment has been minimized.

stale bot commented Jul 2, 2018

This comment has been minimized.

feross commented Aug 4, 2019

This comment has been minimized.

feross commented Aug 4, 2019

dcposch commented Sep 2, 2016 •

edited

dcposch commented Sep 2, 2016 •

edited

Ideas for how to fix this in `webtorrent.js` / `fs-chunk-store`

disarticulate commented Oct 22, 2017 •

edited

disarticulate commented Oct 22, 2017 •

edited