PDF OOM inside FPDF_LoadTableFromTT() |
|||
Issue descriptionChrome Version: 61.x OS: Windows 0x043cdff0 (chrome_child.dll -win_util.cc:70 ) base::win::`anonymous namespace'::ForceCrashOnSigAbort 0x0450517c (chrome_child.dll -signal.cpp:516 ) raise 0x044f3c6b (chrome_child.dll -abort.cpp:64 ) abort 0x04bed275 (chrome_child.dll -partition_alloc.cc:276 ) pdfium::base::PartitionOutOfMemory 0x04beca50 (chrome_child.dll -partition_alloc.cc:828 ) pdfium::base::PartitionAllocSlowPath(pdfium::base::PartitionRootBase *,int,unsigned int,pdfium::base::PartitionBucket *) 0x0563f7a2 (chrome_child.dll -cfx_string_data_template.h:38 ) CFX_StringDataTemplate<char>::Create(int) 0x0563fe3f (chrome_child.dll -cfx_bytestring.cpp:394 ) CFX_ByteString::GetBuffer(int) 0x0572ea19 (chrome_child.dll -cfx_folderfontinfo.cpp:40 ) `anonymous namespace'::FPDF_ReadStringFromFile 0x0572e9f8 (chrome_child.dll -cfx_folderfontinfo.cpp:56 ) `anonymous namespace'::FPDF_LoadTableFromTT 0x0572ee18 (chrome_child.dll -cfx_folderfontinfo.cpp:207 ) CFX_FolderFontInfo::ReportFace(CFX_ByteString const &,_iobuf *,unsigned int,unsigned int) 0x0572f863 (chrome_child.dll -cfx_folderfontinfo.cpp:187 ) CFX_FolderFontInfo::ScanFile(CFX_ByteString const &) 0x0572f979 (chrome_child.dll -cfx_folderfontinfo.cpp:145 ) CFX_FolderFontInfo::ScanPath(CFX_ByteString const &) 0x0572e949 (chrome_child.dll -cfx_folderfontinfo.cpp:115 ) CFX_FolderFontInfo::EnumFontList(CFX_FontMapper *) 0x05631e6d (chrome_child.dll -fpdf_sysfontinfo.cpp:136 ) DefaultEnumFonts 0x0561ba07 (chrome_child.dll -pdfium_engine.cc:358 ) chrome_pdf::`anonymous namespace'::EnumFontsW 0x05631f93 (chrome_child.dll -fpdf_sysfontinfo.cpp:43 ) CFX_ExternalFontInfo::EnumFontList(CFX_FontMapper *) 0x05719e99 (chrome_child.dll -cfx_fontmapper.cpp:359 ) CFX_FontMapper::LoadInstalledFonts() ... Bad font?
,
Oct 3 2017
This happens opening any PDF, right? I guess it's a bad font, I don't think that code has ever been changed. The only change is that now we use PartitionAlloc so it crashes instead of failing the alloc.
,
Oct 3 2017
I think this is only happening to some users, possibly only sometimes. It could be: - a bad font with a very large size, or just a large font, period. - maybe the PDF itself is also very large and using lots of memory?
,
Oct 5 2017
Do you have a link for the crashes, or what's the source of this bug report? The change to PartitionAlloc is older (from March) so if this is a new spike there has to be another cause.
,
Oct 5 2017
Oh, I forgot to include the crash report ID. 93d0a451663e5a6d
,
Oct 11 2017
,
Oct 12 2017
The following revision refers to this bug: https://pdfium.googlesource.com/pdfium/+/a112f85f6c11b171286ec54fca5e0dcf18f9be63 commit a112f85f6c11b171286ec54fca5e0dcf18f9be63 Author: Nicolas Pena <npm@chromium.org> Date: Thu Oct 12 15:18:28 2017 Add more checks to fseeks in CFX_FolderFontInfo Bug: chromium:770890 Change-Id: Iee532d76aabc0763a835c203344455ba07c6e82c Reviewed-on: https://pdfium-review.googlesource.com/15930 Reviewed-by: Ryan Harrison <rharrison@chromium.org> Commit-Queue: Nicolás Peña Moreno <npm@chromium.org> [modify] https://crrev.com/a112f85f6c11b171286ec54fca5e0dcf18f9be63/core/fxge/cfx_folderfontinfo.cpp
,
Oct 12 2017
How can we tell if this CL fixed the crashes? I only see crashes on 61 and below https://crash.corp.google.com/browse?q=OMIT%20RECORD%20IF%20SUM(CrashedStackTrace.StackFrame.FunctionName%3D%27%60anonymous%20namespace%5C%27%3A%3AFPDF_LoadTableFromTT%27)%20%3D%200&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=#-property-selector,+productversion:30
,
Oct 17 2017
It's rather infrequent. Let's just cross other fingers and call it a day. If we find it again in M63+, we can reopen. Otherwise, we'd hold this bug open for a while, wait, and then decide to close. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dsinclair@chromium.org
, Oct 3 2017