Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(152)

Side by Side Diff: third_party/WebKit/Source/core/fileapi/FileReader.cpp

Issue 1414553002: Fix out-of-memory crashes related to ArrayBuffer allocation Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Reverting some behavior changes Created 5 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
1 /* 1 /*
2 * Copyright (C) 2010 Google Inc. All rights reserved. 2 * Copyright (C) 2010 Google Inc. All rights reserved.
3 * 3 *
4 * Redistribution and use in source and binary forms, with or without 4 * Redistribution and use in source and binary forms, with or without
5 * modification, are permitted provided that the following conditions are 5 * modification, are permitted provided that the following conditions are
6 * met: 6 * met:
7 * 7 *
8 * * Redistributions of source code must retain the above copyright 8 * * Redistributions of source code must retain the above copyright
9 * notice, this list of conditions and the following disclaimer. 9 * notice, this list of conditions and the following disclaimer.
10 * * Redistributions in binary form must reproduce the above 10 * * Redistributions in binary form must reproduce the above
(...skipping 352 matching lines...) Expand 10 before | Expand all | Expand 10 after
363 363
364 // All possible events have fired and we're done, no more pending activity. 364 // All possible events have fired and we're done, no more pending activity.
365 ThrottlingController::finishReader(executionContext(), this, finalStep); 365 ThrottlingController::finishReader(executionContext(), this, finalStep);
366 } 366 }
367 367
368 void FileReader::result(StringOrArrayBuffer& resultAttribute) const 368 void FileReader::result(StringOrArrayBuffer& resultAttribute) const
369 { 369 {
370 if (!m_loader || m_error) 370 if (!m_loader || m_error)
371 return; 371 return;
372 372
373 if (m_readType == FileReaderLoader::ReadAsArrayBuffer) 373 if (m_readType == FileReaderLoader::ReadAsArrayBuffer) {
374 resultAttribute.setArrayBuffer(m_loader->arrayBufferResult()); 374 // FIXME(crbug.com/536816):
375 else 375 // In on-going work for crbug.com/536816 the code was left in this state
376 // to avoid changing pre-existing behavior, but we may want to revisit
377 // this code to determine the proper course of action for cases where
378 // arrayBufferResultOrNull() returns a nullptr, presumably due to a
379 // memory allocation failure. Would it be aprropriate to throw a
380 // RangeError DOM exception from here? Should we cancel the setting
381 // of resultAttribute instead of setting it to null?
382 resultAttribute.setArrayBuffer(m_loader->arrayBufferResultOrNull());
383 } else {
376 resultAttribute.setString(m_loader->stringResult()); 384 resultAttribute.setString(m_loader->stringResult());
385 }
377 } 386 }
378 387
379 void FileReader::terminate() 388 void FileReader::terminate()
380 { 389 {
381 if (m_loader) { 390 if (m_loader) {
382 m_loader->cancel(); 391 m_loader->cancel();
383 m_loader = nullptr; 392 m_loader = nullptr;
384 } 393 }
385 m_state = DONE; 394 m_state = DONE;
386 m_loadingState = LoadingStateNone; 395 m_loadingState = LoadingStateNone;
(...skipping 82 matching lines...) Expand 10 before | Expand all | Expand 10 after
469 } 478 }
470 479
471 DEFINE_TRACE(FileReader) 480 DEFINE_TRACE(FileReader)
472 { 481 {
473 visitor->trace(m_error); 482 visitor->trace(m_error);
474 RefCountedGarbageCollectedEventTargetWithInlineData<FileReader>::trace(visit or); 483 RefCountedGarbageCollectedEventTargetWithInlineData<FileReader>::trace(visit or);
475 ActiveDOMObject::trace(visitor); 484 ActiveDOMObject::trace(visitor);
476 } 485 }
477 486
478 } // namespace blink 487 } // namespace blink
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698