https://bugs.documentfoundation.org/show_bug.cgi?id=161135
--- Comment #4 from V Stuart Foote <[email protected]> --- (In reply to Mike Kaganski from comment #3) > (In reply to V Stuart Foote from comment #0) > > Attached soffice.bin to WinDbg with symbols. Look to be hitting the OOM > > assert at vcl/skia/gdiimpl.cxx 485 that Mike K. put in with > > https://gerrit.libreoffice.org/c/core/+/161516 > > Please note that I didn't put any asserts there. I added code to *not* > assert in a specific case, hoping that these cases could get fixed - but > that code isn't run here. > > Given the description that developers made for the 'oomed()', I do not see > what I could do here. An expert is needed, not me. OK thanks, guess I misread the commit, and I'm certainly no expert either. But thought you were on the right track. After an initial skia GrDirectContext oomed() context return [1], you'd tested for > 10 Skia operations to flush with a default at 1000 ops, and then if still oomed() divide that by 2--and get context again just once? And only then fail if still OOM with oomed() context? If the flush is to work, maybe a factor of 10 on oomed() so if > 10 /= 10 --> and reduce the count of resize steps to carry before the flush? Or wishful thinking and I am way off track with being able to flush GPU memory... and maybe rather than the oomed() the Skia releaseResourcesAndAbandonContext() is another way to recover when OOM. =-ref-= [1] https://api.skia.org/classGrDirectContext.html -- You are receiving this mail because: You are the assignee for the bug.
