Unable to reproduce the issue on Windows 7, Mac 10.11.5, Ubuntu 14.04 using 53.0.2780.0, latest canary 53.0.2781.0 with below steps:

1.Added the given PDF viewer extension to chrome.
2.Opened URL: http://etheses.whiterose.ac.uk/9968/1/Damianou_Thesis.pdf
3.Set zoom to 150.
4.Navigated to page 177 and then moved to page 178.
5.Observed that page displayed without any crash.

Please find attached screencast and update if anything missed here in triaging the issue.

qwer1304@Could you please check the issue on clean profile and update the thread with crash id from chrome://crashes if issue still persists.

Deleted: 623375.mp4 5.0 MB

	623375.mp4 5.0 MB View Download

This is a Windows issue. Try reproducing on Win 10.
It could be a Win 10 ONLY issue as well.

Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can reproduce this on a fresh installation of Chrome canary and only the extension installed. Steps:
1. Install the extension
2. Load file
3. Set Zoom (in extension) to 170%
4. Go to page 178
5. Try to scroll

Result:
 - either a crash, or
 - a blinking black screen

If it's the latter, click '-' on Zoom and you will briefly see some text, but then it will either crash or there will be a black screen, and so on until you set the Zoom to 100% or less.

PS Crash report isn't generated.

Attaching the three pages that demonstrate the problem.
Notes:
1.p178 (2nd page) alone does not demonstrate the problem
2.there's no crash, but black screen
3.I had another Chrome window open with flash playing therein. When the pdf tab went black so did the flash tab and flash stopped playing.
4.Ran this in Version 53.0.2784.2 canary SyzyASan, but didn't notice any memory corruption messages.
5.Had to reduce zoom factor to 70% to stop "black screening".

Deleted: p177_179.pdf 481 KB

p177_179.pdf 481 KB Download

qwer1304@Could you please check the issue by upgrading chrome to latest canary 54.0.2816.0 and update the thread whether issue still persists or not?

Thanks,

ssamanoori: "PDF Viewer" extension is not the same as as the "Chrome PDF Viewer."

+rob FYI. I can repro this fairly consistently on Windows 7. Chromium says OOM.

With 64-bit Chrome on Linux, going to page 178 from 177 produces a huge spike in memory usage for the extension. It goes from ~200 MB up to ~4.1 GB, before settling back down. Users with lots of RAM and 64-bit Chrome can weather the storm, but those with less RAM or 32-bit Chrome cannot.

No crash for me in 52 (but I have an excessive amount of RAM, so that's not representative).
I observed a spike of about 2G in the task manager around page 177 when I scrolled from page 175 to page 178 (which about 1 second page freeze).

See the attached profile, captured in 54.0.2819.0. You can inspect the timeline recording by opening the devtools, opening the context menu, "Load Timeline data" and selecting the attached file. Select range 3500 - 4700ms to see the events at the memory spike.
The devtools does not show any significant memory usage by JS objects, which is probably also the reason for OOM ( bug 448150 ).

schenney, is the inaccurate memory report a probable cause for OOM when lots of patterns are repeatedly painted on <canvas> elements? ( bug 448150 )

See comment 11 for instructions on reading the timeline. It looks a bit odd in Chrome 52, so I suggest to load it in Canary.

Deleted: TimelineRawData-20160804T013116.json 8.7 MB

TimelineRawData-20160804T013116.json 8.7 MB View Download

Yes, in response to comment #11, it is certainly plausible that memory is not being reported correctly to V8, or that there is some other issue with not flushing caches etc.

Has anyone managed to isolate the content or sequence of events that is causing the problem? We have other reports of black screen artifacts on Windows with pdf.js. See https://bugs.chromium.org/p/chromium/issues/detail?id=630394. My guess right now is that these are duplicates, but here we have the advantage (!) of crashing and this seems easier to reproduce.

Adding Canvas component based on comment #11.

I can repro it on ToT under linux. Basically when scrolling from p177 to p178, there is a huge memory increase, from 100MB to 1GB. But this seems to happen with the extension only. I don't see any memory spike when the extension is disabled. Could it because of the extension?

Here's a crash stack, probably confirming out of memory on the GPU.

Objects involved in the operation:
sequence "this" @ 0x0x3aef2ad55a80 {
}
Received signal 6
#0 0x7f73fe90f08e base::debug::StackTrace::StackTrace()
#1 0x7f73fe90ebcf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f73ebb11330 <unknown>
#3 0x7f73e9decc37 gsignal
#4 0x7f73e9df0028 abort
#5 0x7f73ea441fe5 __gnu_debug::_Error_formatter::_M_error()
#6 0x7f73f1f01b2c std::__debug::vector<>::operator[]()
#7 0x7f73f1f00701 gpu::gles2::StrictIdHandler::MarkAsUsedForBind()
#8 0x7f73f1e65737 gpu::gles2::GLES2Implementation::BindTextureHelper()
#9 0x7f73f1e787be gpu::gles2::GLES2Implementation::BindTexture()
#10 0x7f73f78631e1 _ZZN12_GLOBAL__N_19gles_bindIvJjjEEESt8functionIFT_DpT0_EEMN3gpu5gles214GLES2InterfaceEFS2_S4_EPS9_ENKUljjE_clEjj
#11 0x7f73f7863044 _ZNSt17_Function_handlerIFvjjEZN12_GLOBAL__N_19gles_bindIvJjjEEESt8functionIFT_DpT0_EEMN3gpu5gles214GLES2InterfaceEFS4_S6_EPSB_EUljjE_E9_M_invokeERKSt9_Any_datajj
#12 0x7f73fcc307fd std::function<>::operator()()
#13 0x7f73fcca846c GrGLGpu::bindTexture()
#14 0x7f73fcccee46 GrGLProgram::bindTextures()
#15 0x7f73fcccefac GrGLProgram::setFragmentData()
#16 0x7f73fcccea28 GrGLProgram::setData()
#17 0x7f73fcca16e2 GrGLGpu::flushGLState()
#18 0x7f73fcca7316 GrGLGpu::draw()
#19 0x7f73fccb6699 GrGLGpuCommandBuffer::onDraw()
#20 0x7f73fcb58f34 GrGpuCommandBuffer::draw()
#21 0x7f73fcbef4ab GrVertexBatch::onDraw()
#22 0x7f73fcb4da5f GrBatch::draw()
#23 0x7f73fcb4b648 GrDrawTarget::drawBatches()
#24 0x7f73fcb48271 GrDrawingManager::flush()
#25 0x7f73fcb333db GrContext::flush()
#26 0x7f73fcb35ece GrContext::prepareSurfaceForExternalIO()
#27 0x7f73fcb43cf0 GrDrawContext::prepareForExternalIO()
#28 0x7f73fcd38cbf SkGpuDevice::flush()
#29 0x7f73fcd44d4d SkSurface_Gpu::onPrepareForExternalIO()
#30 0x7f73fc9c7086 SkSurface::prepareForExternalIO()
#31 0x7f73f5c46945 cc::ResourceProvider::ScopedSkSurfaceProvider::~ScopedSkSurfaceProvider()
#32 0x7f73f5bf44d4 cc::(anonymous namespace)::RasterizePicture()
#33 0x7f73f5bf3096 cc::GpuRasterBufferProvider::PlaybackOnWorkerThread()
#34 0x7f73f5bf2c63 cc::GpuRasterBufferProvider::RasterBufferImpl::Playback()
#35 0x7f73f5cebbe7 cc::(anonymous namespace)::RasterTaskImpl::RunOnWorkerThread()
#36 0x7f73f9263920 content::CategorizedWorkerPool::RunTaskInCategoryWithLockAcquired()
#37 0x7f73f92629c5 content::CategorizedWorkerPool::RunTaskWithLockAcquired()
#38 0x7f73f92628c1 content::CategorizedWorkerPool::Run()
#39 0x7f73f9263b5d content::(anonymous namespace)::CategorizedWorkerPoolThread::Run()
#40 0x7f73fead5701 base::SimpleThread::ThreadMain()
#41 0x7f73feac56fa base::(anonymous namespace)::ThreadFunc()
#42 0x7f73ebb09184 start_thread
...

The extension is allocating a full pdf page-sized canvas for every page, it seems, though probably only drawing anything when there is a figure or diagram. It seems all we could do here is lazily allocate the canvas backing, but that seems stupid for this use case. It seems the extension could do the same thing.

Please follow up with the extension owners as to why they create so many large canvases. I simply don't think they are expecting such large documents.

xidachen@, maybe https://chromium.googlesource.com/chromium/src/+/master/components/tracing/docs/memory_infra.md# is helpful.

Whatever is going on, the GPU label in the Browser process in one memory trace I ran ramped up suddenly to over 800MB before falling back down again once the graph on page 178 was rendered. Something about how the extension draws that graph is sucking up enormous quantities of temporary GPU memory.

schenney@: I have attached the tracing for memory. Apparently at some moment it is allocating 4.3GB on "Native heap", and I cannot get further info about that.  It doesn't see to be related to GPU process.

Deleted: trace_memory_bloat.json.gz 13.1 MB

trace_memory_bloat.json.gz 13.1 MB Download

zidachen@, are you software rastering? Does that make a difference? I'll rerun my tests too.

schenney@: yes, that was on software. Now attaching the gpu memory trace. Still it is the Renderer process that is using the most of the memory. GPU process doesn't increase a lot at the spike.

Deleted: trace_memory_gpu.json.gz 7.4 MB

trace_memory_gpu.json.gz 7.4 MB Download

In Debug Linux I'm getting consistent asserts now in garbage collection. I don't know which of the Peer::~Peer DCHECKS are failing. So maybe this is a WebWorker issue. Adding them to the crowd and Untriaging, as it doesn't look like it's canvas or GPU specific.

#0 0x7f16b38cb08e base::debug::StackTrace::StackTrace()
#1 0x7f16b38cabcf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f16a0acd330 <unknown>
#3 0x7f169eda8c37 gsignal
#4 0x7f169edac028 abort
#5 0x7f16b38c78a6 base::debug::(anonymous namespace)::DebugBreak()
#6 0x7f16b38c7888 base::debug::BreakDebugger()
#7 0x7f16b3932a2d logging::LogMessage::~LogMessage()
#8 0x7f169b244395 blink::WorkerThreadableLoader::Peer::~Peer()
#9 0x7f169b249f45 blink::GarbageCollectedFinalized<>::finalizeGarbageCollectedObject()
#10 0x7f169b249f25 blink::FinalizerTraitImpl<>::finalize()
#11 0x7f169b249f05 blink::FinalizerTrait<>::finalize()
#12 0x7f16a5dbc061 blink::HeapObjectHeader::finalize()
#13 0x7f16a5dc0c68 blink::NormalPage::sweep()
#14 0x7f16a5dbcf29 blink::BaseArena::sweepUnsweptPage()
#15 0x7f16a5dbd310 blink::BaseArena::completeSweep()
#16 0x7f16a5dc82ca blink::ThreadState::completeSweep()
#17 0x7f16a5dc9a6f blink::ThreadState::scheduleV8FollowupGCIfNeeded()
#18 0x7f169a0c4e48 blink::V8GCController::gcEpilogue()
#19 0x7f16a973bf65 v8::internal::Heap::PerformGarbageCollection()
#20 0x7f16a973ac56 v8::internal::Heap::CollectGarbage()
#21 0x7f16a970aab4 v8::internal::Factory::NewJSObjectFromMap()
#22 0x7f16a970c3a4 v8::internal::Factory::NewJSArray()
#23 0x7f16a970c40c v8::internal::Factory::NewJSArray()
#24 0x7f16a933778b v8::Array::New()
#25 0x7f169a089ef6 blink::ScriptValueDeserializer::newDenseArray()
#26 0x7f169a08697b blink::SerializedScriptValueReader::readWithTag()
#27 0x7f1698df08b7 blink::SerializedScriptValueReaderForModules::read()
#28 0x7f1698df1a90 blink::ScriptValueDeserializerForModules::read()
#29 0x7f169a08b79f blink::ScriptValueDeserializer::doDeserialize()
#30 0x7f169a08b4d2 blink::ScriptValueDeserializer::deserialize()
#31 0x7f1698df21d4 blink::SerializedScriptValueForModulesFactory::deserialize()
#32 0x7f169a0a847a blink::SerializedScriptValueFactory::deserialize()
#33 0x7f169a09aecd blink::SerializedScriptValue::deserialize()
#34 0x7f169a12a46f blink::V8MessageEvent::dataAttributeGetterCustom()

Reg: c#22, DCHECK failure on WorkerThreadableLoader::Peer::~Peer seems to be a different issue because WorkerThreadableLoader::Peer was introduced very recently:
https://chromium.googlesource.com/chromium/src/+/279f12d293087b7619089ecbe418e83df9d04a76%5E%21/#F0

+yhirano@, can you take a look at c#22? If it's a separate problem, please file a new issue.

Removing Blink>Loader since loading-triage cannot help here.

yhirano: if there is indeed an issue with your loading-related patch, please add Blink>Loader component back (or to your newly created bug, if it is a separate issue)

Filed a new  bug 635436 .

Let me remove Blink>Workers label because of c#23-25.

rob@robwu.nl: are you the owner of the extension? I did some debugging and here is what I found.

The code went into content\build\pdf.js, line 4917:
var tmpCanvas = owner.cachedCanvas.getCanvas('pattern', width, height, true);

where both width and height is 3000, and I believe that is the MAX_PATTERN_SIZE.

I think the problem is that the cachedCanvas is not getting garbage collected quickly enough. So is there a way to change the extension to set the cachedCanvas.width and height to be 0, when the cachedCanvas is not used anymore.

Also, creating a temp canvas to be the MAX_PATTERN_SIZE of 3000 seems to be a very large canvas, maybe also considering to lower that number?

#28
Yes, I am owner of the extension. This bug is also tracked at https://github.com/mozilla/pdf.js/issues/7395.

I created a reduced test case to reproduce the issue, please see the attachment and try the buttons.
The garbage collector seems to have trouble with freeing memory even though the canvases are clearly out of scope.

To avoid crashes I ran an ASan non-debug build of Chromium to measure the relative impact on memory, by running canvas's createPattern method 1000x in a tight loop.
Initial state: 200 MB
1. (global context).createPattern(same global canvas), 1000x     -- 50MB memory used
2. (global context).createPattern(temporary canvas), 1000x       -- 15.7 G memory used.
3. (global context).createPattern(another global canvas), 1000x  -- 15.7 G memory used.
4. (temporary context).createPattern(same temporary canvas),1000x-- 114 G spike memory usage, GC within a second and 200 MB retained.
5. (temporary context).createPattern(global canvas), 1000x       -- 50MB usage

It seems that a CanvasRenderingContext is keeping a reference to the created pattern, even if the pattern (or the source canvas) has gone out of scope.
If I run a regular build of Chrome, test cases 2, 3 and 4 cause the renderer to crash.

When I use a microtask, idle callback or requestAnimationFrame, or 0ms timeouts the memory usage statistics are the same.
When 50ms timeout, the test takes much longer and ends up around 9 GB.
With 10ms timeouts, the test sometimes grows from 200 MB to 13 GB in about 17 seconds, then drops to 1.4 and ends up at 3 GB.

When I launch Chrome with --js-flags=--expose-gc and execute gc() in Chrome's developer tools' console after test cases 2 and 3, the memory is released after about 3 seconds (with 200MB of memory not freed, just like test case 4).


Stack trace of renderer crash with test cases 2 and 3:
Received signal 11 SEGV_MAPERR 000000000028
#0 0x55cbabb4b88e base::debug::StackTrace::StackTrace()
#1 0x55cbabb4b3cf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7fef22f6a080 <unknown>
#3 0x55cbac754554 SkSurface_Base::getCachedCanvas()
#4 0x55cbac7541dd SkSurface::getCanvas()
#5 0x55cbaed8e393 blink::(anonymous namespace)::createTransparentImage()
#6 0x55cbaed8bbf6 blink::HTMLCanvasElement::getSourceImageForCanvas()
#7 0x55cbaed8e7ac blink::HTMLCanvasElement::getSourceImageForCanvas()
#8 0x55cbae890107 blink::BaseRenderingContext2D::createPattern()
#9 0x55cbae739197 blink::CanvasRenderingContext2DV8Internal::createPatternMethod()
#10 0x55cbae734645 blink::CanvasRenderingContext2DV8Internal::createPatternMethodCallback()

Stack trace of renderer crash with test case 4:
Received signal 11 SEGV_MAPERR 000000000028
#0 0x55cbabb4b88e base::debug::StackTrace::StackTrace()
#1 0x55cbabb4b3cf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7fef22f6a080 <unknown>
#3 0x55cbac754554 SkSurface_Base::getCachedCanvas()
#4 0x55cbac7541dd SkSurface::getCanvas()
#5 0x55cbb4236101 blink::UnacceleratedImageBufferSurface::canvas()
#6 0x55cbb4233451 blink::RecordingImageBufferSurface::fallBackToRasterCanvas()
#7 0x55cbb4233544 blink::RecordingImageBufferSurface::newImageSnapshot()
#8 0x55cbb4224c51 blink::ImageBuffer::newSkImageSnapshot()
#9 0x55cbaed8bc74 blink::HTMLCanvasElement::getSourceImageForCanvas()
#10 0x55cbaed8e7ac blink::HTMLCanvasElement::getSourceImageForCanvas()
#11 0x55cbae890107 blink::BaseRenderingContext2D::createPattern()
#12 0x55cbae739197 blink::CanvasRenderingContext2DV8Internal::createPatternMethod()
#13 0x55cbae734645 blink::CanvasRenderingContext2DV8Internal::createPatternMethodCallback()




I hope that the reduction is representative and useful.
Just in case, I have also attached the PDF viewer extension and a smaller PDF with the relevant pages from the bug report. To reproduce the original report:
1. Unpack the zip file in some directory
2. Visit chrome://extensions
3. Enable developer mode
4. Load unpacked extension, select the directory from 1.
5. Allow the extension to access local file URLs via the checkbox at chrome://extensions.
6. Open the attached PDF file, the extension will try to display it.
7. Scroll to page 2, crash.

Deleted: crashy-canvas.html 4.6 KB

crashy-canvas.html 4.6 KB View Download

Deleted: pdfjs-extension-1.5.294.zip 1.8 MB

pdfjs-extension-1.5.294.zip 1.8 MB Download

Deleted: page177-180.pdf 537 KB

page177-180.pdf 537 KB Download

#29: Thank you so much for your test cases. I created a tiny test case based on your test cases, and the file is attached.

This really feels like the bug that we have here:
https://bugs.chromium.org/p/chromium/issues/detail?id=626082

Where this script:
for (var i = 0; i < 20; i++) {
    var image = new ImageData(5000, 5000);
}
consumes 2GB of memory. And if I change 20-->200, it uses 20GB.

Deleted: tiny-testCase.html 379 bytes

tiny-testCase.html 379 bytes View Download

Also, another bug related to this one:
https://bugs.chromium.org/p/chromium/issues/detail?id=624718

In the above bug, it creates a big canvas (aCanvas), and use another canvas (bCanvas) to do this:
for (var i = 0; i < 2000; i++) {
   bCanvas.drawImage(aCanvas)
}
that causes OOM.

This may be tangential, but we also have this bug, https://bugs.chromium.org/p/chromium/issues/detail?id=448150, related to Blink's failure to report the size of large Skia objects to Javascript, so that JS knows to prioritize GC for such objects and it can track its memory footprint.

 Issue 630394  has been merged into this issue.

Any updates on this issue?

imtonyjin@: I believe the fix for this issue will be on the garbage collection side, instead of canvas side. I mark this issue blocked on:
https://bugs.chromium.org/p/chromium/issues/detail?id=626082

So once the blocking issue is resolved, this issue will be automatically resolved.

I just did some check and I believe there are some progress made. About 6-8 weeks ago I did memory trace for this issue, and I believe the peak memory goes up to 4.2GB, right now it is about 1.5GB.

Still happens on Version 59.0.3071.0 canary (64-bit)
And there have been no updates on the blocking issue https://bugs.chromium.org/p/chromium/issues/detail?id=626082 since autumn 2016, eventhough that issue is at priority 1.

The current status after GC improvement is that:

32b version (e.g., Installed Version 61.0.3141.8 (Official Build) dev (32-bit) works CORRECTLY
64b version (e.g., Version 61.0.3141.7 (Official Build) dev (64-bit)) works INCORRECTLY 

on pdf test file on a 8GB machine w/ Win 10 64b.

Hope this helps.

I can testify that we the latest concurrent GC e.g. in Version 63.0.3225.0 (Official Build) canary (64-bit) the problem is solved for both 32b and 64b versions. Tested in Windows 10 64b with 8GB RAM.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The case from comment #30 still crashes.

Even if the case from #30 still crashes, it sounds like the original issue has been addressed (and https://github.com/mozilla/pdf.js/issues/7395 is also now closed).  Is this now fixed enough to close, or is there more work to do here?

I don't really want to close when we still OOM on something that seems like it shouldn't. But if it's a hard situation to prevent (i.e. the user is mistreating the system) then I think we can close it. I don't know enough to make that call.