Reviving this 2012 thread, this still exists, for some reason – every Debug.Log sends a needless stacktrace to the Debug.Log() function itself – to the exact same, static copy+paste DebugBindings.
Bump! This is incredibly bloaty – I tried to Google some answers, but the keywords are too generic. I mostly find answers regarding how to eliminate logging completely: Stacktraces are nice, but not a stacktrace from a log:
Now that the class is sealed (well, now as in like 5 years ago :p), there seems to be no workarounds for these bloaty, unnecessary stacktracing of the logs themselves.
Yeah this is a bit annoying. System.Console.WriteLine will write to the editor/player log without the stacktrace, so I it seems like the best thing you can do is write your own logging function that just calls that instead.
If you’re on iOS or Android I would write a native function that does the logging using NSLog or whatever instead.
Thanks for the tip. It’s a shame that Unity couldn’t just check if the stacktrace startsWith() and poof that line of text if they’re going to seal off the class. There isn’t 1 person that would benefit from that in any form – Bleh, +so much unnecessary work to do basic things.
Thank you, but better to have it than not have it~ I still want stacktrace, but hell I’ve memorized the class and line where DebugBindings come from lol.
This is a prime example of no Unity developer taking a closer look at logs. All debugging done on Editor. No one collecting player logs from end users. THAT’S NOT EFFICIENT!
It’s SO TEDIOUS to find what you’re looking for and so distracting. So redundant and pointless. And boats the logs - imagine that 500k logs turn into 1mb. That’s like a Harry Potter book worth of redundant logs.
well, there’s my message at least. I looked through the C# part of the Unity’s source code that they released on the github, and I came to a conclusion that in order to fix this issue, I need access to the C++ code. Debug class is merely for binding with C++. The actual implementation that produces the line is in C++ code, not in C#. I couldn’t go further than that.
Well, maybe, someday, I’ll be wealthy enough to buy the source code to finally get rid of that line. Until then …
I wanted this problem to be fixed for two reasons: collecting logs from users and use of journald.
As for collecting logs: this is actually what some game developers(like Subnautica) encourages. This actually helps. There are simply so many types of hardware to test out, but testing all of them is close to impossible. I was able to solve some bugs related to graphics driver in this way.
Using Unity networking is not the one of the best practice out there, but I had to stick to it. So, I run Unity processes to host dedicated game servers. As you can see from the screenshot, that’s just messed up.
I made two things to mitigate the problem. This is a shell script that removes the abundant lines(“Filename”, empty lines):
#!/bin/bash
dos2unix |
sed -E '/^\(Filename:.*Line:[[:space:]]+[[:digit:]]+\)$/d' |
sed -E '/^([[:space:]]+)?$/d'
If you have the control over starting the Unity process on Unices,
some_unity_program -logFile "/dev/stdout" |
sed -u -E '/^\(Filename:.*Line:[[:space:]]+[[:digit:]]+\)$/d' |
sed -u -E '/^([[:space:]]+)?$/d'
Argh… I hate that “(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 43)” too. Hoped, that new Unity versions got rid of it… No success.
Amazing how the Unity “Ostrich” Developers can keep neglecting this one!, seems like no one at Unity are using their own engine for anything beside editor demos… Funny enough since they are planning to hit the stock-market, they hired spin-doctors to fix the forum reputation, instead of fixing their bugs…
