Page MenuHomePhabricator

PDF fails to display for download
Closed, ResolvedPublic

Description

When trying to view a PDF in a git archive, the user gets an error.

To repeat:

  1. Try to download this file:

https://code.alephobjects.com/diffusion/OM/browse/master/AOOM.pdf

Public users get this error:

Unhandled Exception ("Exception")

No configured storage engine can store this file. See "Configuring File Storage" in the documentation for information on configuring storage engines.

Logged in users get this error, after 90 seconds (which is a default I bumped up, probably in php.ini):


UNRECOVERABLE FATAL ERROR <<<
Maximum execution time of 90 seconds exceeded

/var/www/libphutil/src/utils/utf8.php:0

During this time, the apache daemon is pegging the CPU. The system is 4G of CPU, 4G of RAM (free ram is available).

The filesystem store is the local filesystem at /var/repo (of 100G at present). It was migrated from the default MySQL, which is set to 0 for storing files now. Smaller PDFs and other files seem to work, but we haven't extensively tested.

Event Timeline

jebba assigned this task to epriestley.
jebba raised the priority of this task from to Needs Triage.
jebba updated the task description. (Show Details)
jebba added a project: Diffusion.
jebba added a subscriber: jebba.

Can you do this to get a stack trace?

  • Set debug.time-limit to 5 in your config (you can do this in the Config application).
  • Load the page which exhibits the problem.
  • If the stars align, it should exit after 5 seconds with a more useful stack trace.
  • Paste that here.
  • (Then, delete debug.time-limit from your config to disable this debug mode.)

That should help us hunt this down a little more quickly.

Request aborted by debug time limit after 5 seconds.

STACK TRACE
utf8.php:45 PhabricatorStartup->onDebugTick()
DarkConsoleCore.php:130 phutil_utf8ize()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:58 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:110 DarkConsoleCore->getKey()
PhabricatorStandardPageView.php:332 DarkConsoleCore->render()
AphrontPageView.php:76 PhabricatorStandardPageView->willSendResponse()
PhabricatorController.php:419 AphrontPageView->render()
AphrontApplicationConfiguration.php:234 PhabricatorController->didProcessRequest()
AphrontApplicationConfiguration.php:140 AphrontApplicationConfiguration->processRequest()
index.php:21 AphrontApplicationConfiguration->runHTTPRequest()

Actually, this doesn't look like a bug, but a settings issue. Though it should probably fail more gracefully.

"local-disk PhabricatorLocalDiskFileStorageEngine" is set to 8M.

I don't immediately see how to change that value, but it can be tracked down...

Two fixes here:

  • D13347: If we have a huge amount of data from a service call, we no longer try to display all of it in DarkConsole; doing so is useless and this was previously very slow because of utf8 sanitization.
  • D13348: We now fail more aggressively on large files, producing a reasonable error and a usable page.

These things could be improved, but are more involved:

  • We could determine the filesize of large files without downloading them, but currently do not. This would let us display a more specific message about the size of files ("This file is 215MB", instead of "This file is larger than 4MB").
  • We could support streaming large files out of the VCS, but currently do not. Pulling the file may involve a service call over the API, and the API doesn't currently support streaming. We could reframe the API call to have the server on the far end push the data into the filestore and give us back the PHID, which is reasonable, and would let us stream the file from the frontend, but this is a moderate amount of work and potentially a breaking API change. For now, use git from the CLI to access files larger than 4MB.

I'll note these specifically in T4474, but don't plan to pursue them in the near term.

I think this is now fixed (in the sense of "not broken anymore", not in the sense of "working as nicely as it possibly could"). Let me know if that's not the case.

Ok, so that definitely fixed the error. Now it presents the page correctly, but notes:

"This file is larger than 4194304 byte(s), and too large to display in the web UI."

It doesn't have a link for a raw download though. I understand it not displaying it/rendering it, but by "too large to display" does that mean it is too large for a raw file link?

So, in sum, the error is gone, and it looks better, but the raw file still can't be downloaded, afaict. Thx!