Availability to override or switch off Bluescreen rendering

finwe

On larger projects, rendering full Bluescreen output can be all time, memory and disc space consuming. On multiple occasions, scripts with an error ended on time/memory limits without actual possibility to read what happened from logs.

That is especially annoying in production environments and often happens with errors in templates.

I'd like to have a possibility to override Bluescreen with some basic version – maybe without all code coloring and toggles, just a plain stack trace.

All other Tracy's features should of course remain functional.

Filip Procházka

As a hotfix, you should get a better hardware :)

finwe

Given that all BlueScreen functionality is contained in its template, maybe it would be sufficient to be able to replace the template.

Filip Procházka

Lower the Debugger::$maxDepth, that should make Tracy a lot smaller and faster to render.

iguana007

Examples of usage are listed in this czech thread (actually it is a copy of this thread with same problem): https://forum.nette.org/…pomocou-dibi#…

finwe

All of those are more or less hacks, I would care for a systematic solution.

A possibility not to render error HTML files at all. No rendering of source dumps (which can be — and often is — disk space/memory/time consuming all by itself)…

Last edited by finwe (2014-08-29 15:06)

Filip Procházka

Debugger::$maxDepth is not a hack.

Disable Tracy and register your own error_handler and exception_handler. There is no point in enabling Tracy, if you don't want to see the bluescreens.

finwe

Sure it is a hack in this particular case – it does not solve my problem, only offers a very partial solution.

Sure, I could write my own error handler and stay away from tracy. I would surely end up with implementing my own error mailing, my own debugger bar and other useful Tracy features :-P

iguana007

@finwe 2 days ago has been released new optimised version of tracy, so give it a try, maybe it will solve your issue.

Composer setup for standalone Tracy:

"require": {
    "nette/nette": "~2.2@dev",
    "tracy/tracy": "~2.3@dev"
},

… or for whole Nette:

"require": {
    "nette/nette": "~2.2"
},
"minimum-stability": "dev"

finwe

Not really. Size of the most common HTML dump decreased, yes, but “only” from 600kB to 450kB. With alternate template, I was able to reduce the size to 40–60kB: no source file dumps, only simple argument dumps, but still nicely readable and with known-to-all Bluescreen dump appearance. Moreover, loading the file in browser increased significantly from obvious reasons. I have no memory benchmarks, though.

Still, I do not see any reason why not to allow at least switching HTML dumps to log directory off entirely.

Will prepare some PRs to include with the feature request, when I have some spare time.

David Grudl

Does your dump (created with new Tracy) contain any spans with class tracy-dump-object? And where?

finwe

It does – in arguments dump of some items in the call stack.

David Grudl

Are they empty, without items?

finwe

No, they contain object dumps.

David Grudl

It seems like a bug. Arguments in callstack should be always dumped with flag LIVE. Can you send me it to email?

finwe

I'd have to create some from a disclosable source code. It will take some time, thanks for patience.

finwe

I see now in the repo master branch, that my problem can be solved entirely by replacing Logger with my own implementation. That is great and thanks for that, looking forward for it to reach a stable version!

LeonardoCA

To put in my 2 cents, I had experienced similar issues in the past, at least on 2 projects and it was always extremlly annoying. Usually while working on processing some huge sets of data – imports/exports, etc. Even with Debugger::$maxDepth set to 1 or 2 the blue screen often had > 5MB.

I think best and universal solution for this would be:

if debug bar has some fast options to turn on/off not only bluescreen but any panel separately when needed.
Implement somehow yet other way to limit amount of dumped data than $maxDepth. Not sure how, maybe $maxNumber of Variables/Objects dumped.

This is not very common issue, but on bigger projects, which are not just about web, but include some integrations such things happen and are practically unavoidable.

Last edited by LeonardoCA (2014-09-21 19:41)

Jan Tvrdík

@LeonardoCA Have you tried the latest Tracy (2.3-dev)? Does it solve your problem?

LeonardoCA

I noticed David made some changes improving drastically rendering speed, but from the description I don't think it would solve that problem completely.

I don't have this problem now (I had it like 1–3 years ago) and I am not sure if I would be able to remember what exactly happened to simulate it. I guess I will test it on some next project in future.

Last edited by LeonardoCA (2014-09-22 16:48)