Availability to override or switch off Bluescreen rendering

5 years ago

finwe
Member | 54
+
0
-

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.

5 years ago

Filip Procházka
Moderator | 4693
+
-2
-

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

5 years ago

finwe
Member | 54
+
0
-

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

5 years ago

Filip Procházka
Moderator | 4693
+
0
-

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

5 years ago

iguana007
Member | 988
+
0
-

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#…

5 years ago

finwe
Member | 54
+
0
-

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)

5 years ago

Filip Procházka
Moderator | 4693
+
0
-

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.

5 years ago

finwe
Member | 54
+
0
-

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

5 years ago

iguana007
Member | 988
+
0
-

@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"

5 years ago

finwe
Member | 54
+
0
-

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.

5 years ago

David Grudl
Nette Core | 6827
+
0
-

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

5 years ago

finwe
Member | 54
+
0
-

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

5 years ago

David Grudl
Nette Core | 6827
+
0
-

Are they empty, without items?

5 years ago

finwe
Member | 54
+
0
-

No, they contain object dumps.

5 years ago

David Grudl
Nette Core | 6827
+
0
-

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

5 years ago

finwe
Member | 54
+
0
-

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

5 years ago

finwe
Member | 54
+
0
-

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!

4 years ago

LeonardoCA
Member | 297
+
+1
-

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:

  1. if debug bar has some fast options to turn on/off not only bluescreen but any panel separately when needed.
  2. 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)

4 years ago

Jan Tvrdík
Nette guru | 2550
+
0
-

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

4 years ago

LeonardoCA
Member | 297
+
0
-

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)