Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catching memory exhaustion #272

elieux opened this issue Oct 26, 2017 · 3 comments

Catching memory exhaustion #272

elieux opened this issue Oct 26, 2017 · 3 comments


Copy link

@elieux elieux commented Oct 26, 2017

  • bug report? maybe
  • feature request? no
  • version: 2.4.8

Steps to Reproduce

while (true) $a[] = str_repeat('x', 1024);

Shows the default PHP error output:

Fatal error: Allowed memory size of [...] bytes exhausted (tried to allocate 1025 bytes) in [...] on line [...]

Call Stack: [...]

Even worse, it shows nothing with ini_set('display_errors', false).


The code that's supposed to make Tracy work even in case of reaching the memory limit doesn't seem to help when the limit is reached by a small allocation.

Is there anything we can do to fix this and let Tracy show the SoD even in this case?

Copy link

@elieux elieux commented Jun 13, 2019

#369 made an effort to solve this, but the issue persists. The problem here is architectural, IMHO it can't be solved by increasing a number. I tried the with reserved memory of 500'000 B as per the pull request, and it made the red screen appear for the above testcase. Splitting the allocations in half made Tracy fail again though:

while (true) $a[] = str_repeat('x', 512);

Copy link

@smuuf smuuf commented Jun 17, 2019

I think the problem with this is that any solution based on the amount of pre-allocated memory might never be universally good enough.

It's not going to always work because different apps - ultimately - will be needing very various amounts of memory to display the Tracy's blue(red)creen in its entirety; apps with small amount of variables (and other stuff) in them will need considerably less memory to render the bluescreen than huge apps with thousands of variables and instantiated classes.

One fixed number will not going to fit all. IMHO it's more about finding the good balance between:

  1. DO pre-allocate a very large amount of memory to match the needs of as many apps/usages as possible.
  2. DON'T pre-allocate such very large amount of memory, because most of the times the memory is allocated completely unnecessarily - it matters only when the memory exhaustion finally happens - which it most of the time does not.

The original value before my PR was 30 kB. My PR increased it to 500 kB. It might be a good thing to increase it further to, say, 1 MB of reserved memory. But this increasing might go on forever.

Somehow viable option for Tracy might be to allow clients to set the size of the memory that's going to be pre-allocated (presumably doing it prior to the \Tracy\Debugger::enable() call) - so everyone can reserve the amount of memory that will fit their needs (i.e. fit their specific app) ... while also having some sane default value (500 kB? 1000 kB?) ... 🤔

Copy link

@dg dg commented Jun 18, 2019

fixed by #369

@dg dg closed this Jun 18, 2019
@dg dg reopened this Jun 18, 2019
@dg dg closed this Apr 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants