weixin_39877504
2020-12-02 22:59 阅读 44

Out of memory at ImageData creation

I'm heavily using Pica to resize images in an application, but after doing too many in sequence I get the following JavaScript error:

RangeError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': Out of memory at ImageData creation

I've got it locked down to single-threaded operation so invocations of Pica are sequential instead of parallel, but I'm not sure what else I can do apart from not use Pica.

该提问来源于开源项目:nodeca/pica

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

26条回答 默认 最新

  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    No ideas. At first glance, all major resources should be released in time.

    Could you create a repo with minimal example how to reproduce? Something like html file with js that can be opened in browser to see error.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Here's an example that can cause the OoM error:

    https://jsfiddle.net/updsna4a/7/

    Drag and drop say five very large images (I'm testing with images about 4,600x3,000) and I get an OoM error in the console:

    
    Uncaught (in promise) RangeError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': Out of memory at ImageData creation
        at VM1226 pica.js:1772
        at VM1226 pica.js:999
        at roll (VM1226 pica.js:992)
        at VM1226 pica.js:1002
    

    They should be created in sequence.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    At first glance, you do not release data URL of previews. Try to narrow your sample to leave only pica-related code.

    For example, take 1 source image from data URL (with your desired size) and resize it many time in sequence. I think, you problem can be caused not by pica but by wrappers.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Okay, hopefully this is proof positive: https://jsfiddle.net/updsna4a/10/

    If you drag one image to it, it will call Pica 10 times and do absolutely nothing but calling Pica and it will still run out of memory.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Sorry, it's not exclusively Pica code, but the loop is only Pica.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59
    1. Change your code to not run multiple resize in parallel. Run in sequence instead.
    2. Use pica.toBlob instead of dataURI

    IMHO problem is that you allocate to much memory on parallel run, that's not pica issue.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    1.) It's not parallel running...it's sequentially running. 2.) I can try that, but I'm not using that in the loop, only the first run (which works).

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Please take a closer look at the code...I can simplify further if necessary, but the latest revision is proof positive that it's a Pica issue.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    Could you try this things:

    1. Comment out p.resize call and still run the rest of code
    2. Disable web workers via pica config
    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Of course that will work...it's not doing anything after the initial conversion:

    https://jsfiddle.net/updsna4a/12/

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    Ok. May be i've missed something between v2 and v3. I'll try to investigate but can't promise any deadlines. Absolutely no ideas now where pica can leak.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Are you hanging onto img or canvas references? Re-using one instance would be a good way to avoid leaks there.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    https://github.com/nodeca/pica/blob/3.0.6/index.js#L345 that caused significant slowdown in chrome.

    If you have a time - try 2.x version (with callbacks, without webassembly). It was active for a long period, and i had no complains about memory.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Ugh...I was just testing on my MacBook Pro and I can't reproduce the OoM error. It would seem this is specific to Chrome on Linux.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    Hmmm... chrome or chromium? Which version? Try to disable WASM then.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Chrome Version 59.0.3071.115 (Official Build) (64-bit)

    I tried disabling WASM and that didn't help. In my fiddle I drop a 6.4 meg image and it creates seven instances before dying. On my MacBook Pro it creates forty with no problems. My desktop machine has 32 gig of memory and is a far more powerful machine. This seems to be a bug related to Chrome on Linux. However, do you have a Linux installation you can test this on? I want to make sure this isn't just something wrong with my machine.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    Just tested on Chromium and it gets to ten instances before dying.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    However, do you have a Linux installation you can test this on? I want to make sure this isn't just something wrong with my machine.

    Yes. I work under Ubuntu 14.04lts and have Chrome 59.0.3071.115 and Chromium 59.0.3071.109 installed.

    Do you have page, that i can open in browser and tell you result? As far as i understand, jsfiddle from your link does not execute anything and need some additional efforts to run.

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    if you just run this: https://jsfiddle.net/updsna4a/18/

    then just drag and drop a large image to the preview panel (the bottom-left frame) it should create forty copies of the image. On Windows and Mac it works fine, on Linux (for me) it crashes after seven.

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    I've opened your link https://jsfiddle.net/updsna4a/18/ and executed top in parallel. Then dragged 17mb jpeg 5200x2900.

    All 40 iteration passed. Memory consumption jumped up and down. At some moment Chrome occupied 3.7Gb of memory, but it returned everything back in the end. GC logic depends on available memory and not a big deal.

    In short - no, it did not crashed. May be you have no swap at your linux setup?

    点赞 评论 复制链接分享
  • weixin_39877504 weixin_39877504 2020-12-02 22:59

    I watched with htop the entire time and it never actually ran out of physical memory even and I have a 20 gig swap and it was never even touched. I believe this is a bug on my machine....I keep meaning to format and rebuild anyway. Perhaps this is the last straw. :)

    点赞 评论 复制链接分享
  • weixin_39637921 weixin_39637921 2020-12-02 22:59

    I can reprocude it on my Debian machine with Google Chrome 58.0.3029.81 (64-bit) with https://jsfiddle.net/updsna4a/18/.

    点赞 评论 复制链接分享
  • weixin_39637921 weixin_39637921 2020-12-02 22:59

    Im my case also chrome tab often crashes (with aw snap; reported to google).

    点赞 评论 复制链接分享
  • weixin_39717318 weixin_39717318 2020-12-02 22:59

    Reproduced this after about 450 sequential resize operations in Chromium Version 62.0.3202.94 (Developer Build) (64-bit) on Arch Linux (4.13.12-1-ARCH).

    点赞 评论 复制链接分享
  • weixin_39872624 weixin_39872624 2020-12-02 22:59

    IMHO it worth create test with ImageData operations only and forward it to chrome bugtracker.

    I agree with fact of bug, but not sure it's caused by pica itself. I already checked code and could not find any leaks. If anyone has ideas what can i do - let me know.

    点赞 评论 复制链接分享
  • weixin_39856630 weixin_39856630 2020-12-02 22:59

    Hello guys!

    Any solution? I have the same problem. I play it on an Android 5.1.1 phone using Chrome 85.0.4183.101.

    The cell phone is a Samsung J3 2016.

    点赞 评论 复制链接分享

相关推荐