Debug.Log Stacktrace Spam

https://forum.unity3d.com/threads/debug-log-and-needless-spam.38720/

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

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.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

The last guy posted some editor code -- is that still valid in 2017?

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Any idea why Debug.Log() stacktrace (of the Log() itself) is on by default, anyway? O__o we know we used Debug.Log() lol no need to tell us each line

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Thanks

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

(EDIT: Someone says they get an err: cannot derive from sealed type `UnityEngine.Debug')

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

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:

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

That's as if I need to say "THIS WAS A SENTENCE" after every sentence that comes out of my mouth lol -- well, much like my example in OP.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Now that the class is sealed (well, now as in like 5 years ago ), there seems to be no workarounds for these bloaty, unnecessary stacktracing of the logs themselves.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

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.

-sam

 

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.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

bump

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

it's a bit stressful to diagnose bugs

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

I can probably CTRL+H this

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

but we view a lot of logs, so, still ... this really shouldn't be here at all. It's something that the dev team can probably fix in 1 line of code.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Cheers

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

EDIT:

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Heck, I'd upgrade to 2017 JUST for this

 

If you want to disable the stack trace for Debug.Log entirely, you can do that in Player Settings under the "Other Settings" category as shown below.

 

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.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Friendly bump for great justice ~

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

So many years of redundant log spam

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

When will it end?

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

We know, Unity - we know where the log is generated from. DebugBindings:51. We know..... and we'll never, ever look there for anything useful.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

This would take a single developer and about 3 minutes. Come on, Unity. We need this!

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

While this is only a few lines long, look how difficult and bloated this has become to read?

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Or...

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Does anyone know of a workaround to stop this spam?

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Application.logMessageReceived
You cannot override what shows in the Console but you could write a stripped down log to your own file.

Use Application.logMessageReceivedThreaded if your handler is thread-safe.

 

Oh, don't we all love Unity?

(Filename: /home/builduser/buildslave/unity/build/Runtime/Export/Debug.bindings.h Line: 43)

 

That's worth noting, but some poorly written modules use Console.Error to print debug info. We can't handle that there.

 

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!

 

Not helping. The question was how to remove that meaningless line. Changing 'Logging' setting makes no difference.

 

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.

 

https://fogbugz.unity3d.com/default.asp?1045122_0dip9f6q185stknn

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):

Code (csharp):

1.  
2. #!/bin/bash
3. dos2unix |
4.   sed -E '/^\(Filename:.*Line:[[:space:]]+[[:digit:]]+\)$/d' |
5.   sed -E '/^([[:space:]]+)?$/d'
6.  

If you have the control over starting the Unity process on Unices,

Code (csharp):

1.  
2. some_unity_program  -logFile "/dev/stdout" |
3.         sed -u -E '/^\(Filename:.*Line:[[:space:]]+[[:digit:]]+\)$/d' |
4.         sed -u -E '/^([[:space:]]+)?$/d'
5.  

Hope this could be of any help. Unity sucks.

Thanks.

 

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.

 

Did you know the first person to post about this annoyance was in 2010?

 

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...

 

https://fogbugz.unity3d.com/default.asp?1045122_0dip9f6q185stknn

Looks like it's being dealt with. No need to explode the issue.

 

Oh, don't worry. It was officially a feature request in 2011 and marked completed in 2015.

https://feedback.unity3d.com/suggestions/console-toggle-for-stacktrace-o

We have this feature (bug fix, really -- no company would ever purposely implement such redundant logs), apparently. Although it's not here. Or if they accidentally marked it as completed -- don't worry, it'll only take 4 years to get accidentally marked as complete again~ Standard procedure.

 

Any workaround for this these days? Still haven't found a way :/

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Hi,

I am also at same point.I am getting this type of issue while making build on Hololens device.
Please advice how to solve it.

 

I tossed an email to bugs to raise awareness beyond this post. It would truly benefit us all - and seems like it would be such a simple fix to an 8-year-old bug allegedly fixed 4 years ago. I bet it would take a Unity dev 15 minutes to resolve the problem. Heck, I'll pitch in $20 to make it happen.

 

As shamefur of a dispray as this is on Unity's part, I'm glad to see that you've kept this thread up @i42-Xblade .

I find this particularly frustrating with Linux builds of my dedicated server. I've tried everything to get it to just print ORIGINAL stack traces to no avail. It seems to work just fine with Windows deployments if you turn development mode on for the build, but unfortunately Linux builds don't seem to work with that flag.

 

The difference it makes to legibility is insane. CTRL+H is a ghetto workaround, but it also shows how easily it can be fixed by Unity staff.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Look at the difference that how Unity is impacting hundreds of thousands of users debugging (when debugging is already enough of a job as it is).

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)



(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Now, also notice that the stacktrace to debug log is roughly twice or even three times the length of my average output in the picture above.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

This means that this redundant bloat contributes to up to 2/3 the entire client's log size! This is wild to think about.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

This bug has been here long enough -- Even this thread was posted over 1 year ago. after so many bug reports over so many years, including this thread, pls, for the love of anyone, pls show some love.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Thank you.

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Moving this post to Beta feedback -- the only chance this has to get fixed:

https://forum.unity.com/threads/rid-of-debug-log-stacktrace-spam.591562/

 

Hey, guys!!! Hurrrraaay!

I've managed to completely get rid of these lines!

Code (CSharp):

1. #if !UNITY_EDITOR
2. Application.SetStackTraceLogType(LogType.Log, StackTraceLogType.None);
3. Application.SetStackTraceLogType(LogType.Warning, StackTraceLogType.None);
4. #endif

 

This sort of looks like it gets rid of ALL stack traces, though (although let me know if wrong). Stack traces are good: Just not this one ;D

 

There are no stacktraces in the build version for Log/Warning types of messages anyway.

There are full stacktraces for errors and exceptions, which will remain.

 

Makes sense, but my top post was explicitly talking about Debug.Log()

This entire topic is about the build version, mate~

Also, it's not about the stacktrace to the function WE called at all -- Hmm, I don't think you read beyond the header respectfully~

This
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)
is
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)
in
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)
between
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)
every
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)
Debug.Log()
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 45)

The spam is slightly less with IL2CPP builds. Imagine if I talk away that redundant line in between. It's so difficult to read above. However, without them?

This
is
in
between
every
Debug.Log()

Clean! Readable! Relevant!

 

Still happening in 2019.1.8f1 although the line number has moved to 48:

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 48)

Something is happening in that header file... just not what we are hoping for!

 

Welp
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Seems like this is never going to go away.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Easily one of the most annoying bugs (why do we need a stacktrace to the debug.log bloating up 1/2 the file?) in Unity that could likely be fixed in a single line of code.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
I suppose....
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
that we can only hope.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Well, that is....
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
If they can even read between these lines.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Because this is what it looks like when 100's of logs are coming through and we Unity devs need to look at them, reading between the lines, or being ghetto with a CTRL+H to remove them all.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
1000's*
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Originally reported in 2011
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
And again in 2017
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
And again just now (late 2019)
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
I believe waiting 2 years was enough for a new bug report bump after 6 years before that.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Since Unity is growing,
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
This looks a bit amateur.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Even for face/reputation, alone, this should be fixed.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Could it be that this is why Debug.Log() takes up so much juice?
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)
Because it writes twice (in a completely separate call) for each Debug.Log() with a 2nd, unnecessary stacktrace via Reflection?
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)

 

I agree this is super annoying. For those of us working on consoles we have to stare at this mess non-stop. Please fix this Unity!

 

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48)

 

2019.2.0f1
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

 

i find solution guys :

Application.SetStackTraceLogType(LogType.Log,StackTraceLogType.None);

 

Doesn't that just set ALL traces to none instead of just this redundant one?

 

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

In 2019.2.6f1 is in line 35!

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

They have been doing something, just nothing related to this.

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

So annoying makes reading logs a pain.

 

!! ITS HAPPENING!! Best dev <3

 

Don't take this wrong, but we've heard that before...at least 3 times since 2011.

 

Hmmmm... he's right. Any chance of an ETA @Rarepops to show this is real this time? This should be a simple fix, shouldn't it? :raises-eyebrow:

 

As of 2019.1 LogFormat has LogOption of NoStackTrace
https://docs.unity3d.com/2019.1/Documentation/ScriptReference/Debug.LogFormat.html

 

This was already mentioned before and is not the same. We WANT stack trace - just not an additional one from the Debug.Log(), itself.

Debug.Log("Foo") => Results in this two lines:

Foo@Some()@Func() Stacktrace // WE WANT this!
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 48) // This is spammy/bloaty, redundant, and useless

 

I've found that a simple way to make the messages in the Console view way easier to read is to just add an empty line (message + "\n") at the end of every log message.


It doesn't get rid of the UnityEngine.Debug:Log stack trace, but at least it hides it from the main list.

I also like how it more clearly separates the message itself from the stack trace in the detail area.


An alternative way to achieve a similar outcome is to increase the font size of messages to exactly 22 (23 in Unity 2019.3 and later) using rich text tags ("<size=22>" + message + "</size>").

This also causes the stack trace to get pushed off from the main list, resulting in a cleaner look.

 

Do you know that you could just switch to 1 Line here, right?

 

@andrewpey Actually no, somehow I didn't have any recollection of that option being there - thanks for letting me know about it! Maybe because the name "Log Entry" is so generic it had somehow managed to slip into my mental ignore zone.

I'm not sure yet whether I prefer the 1 Line or the 2 Lines style though.
Displaying two lines has the benefit that you can see at a glance if an entry consists of more than one line of text.
Also I've kind of gotten used to being able to use the second row for displaying secondary information at times.



Would be cool if there was an auto-expand option, with the 1 Line style only being used for entries consisting of a single line.

 

Thanks for working on this, @Rarepops!

If you're still working on it, might I make a suggestion? First a little background:

Background
If we want to overwrite the default Debug.Log behaviour, we end up with an additional line in the stack trace:

Code (CSharp):

1. [13:00:00] My message
2. UnityEngine.Debug:Log(Object)
3. MyCode.Debug:Log(Object)
4. [Actual stack trace starts here]

I've been working on getting around this. At the end of the day, DebugLogHandler.Internal_Log() is what actually calls the C# code to do the logging. You can call this yourself, or call Debug.LogFormat() (which eventually calls Internal_Log) and as others have pointed out, you can set LogOption.NoStacktrace.

What I've discovered is: you can actually provide your own stack trace using StackTraceUtility.ExtractFormattedStackTrace(). If you use LogOption.NoStacktrace and instead append the result of ExtractFormattedStackTrace, it almost does exactly what you would want. It allows you to click on any line in the stack trace and go to that line of code in your IDE of choice. Yay!

However, what it doesn't do is allow you to double click on the log entry itself and go to the code. That's all we need for this to be a complete workaround. I have some ideas of how to make this work:

My Suggestion (1)
Can you add LogOption.DontPrintStacktrace or something similar? Basically, can you make it so Unity doesn't print the stack trace to the console, but still goes to the associate line of code when double clicking the log entry?

My Suggestion (2)
Can you allow us to pass in an optional StackTrace that Unity will use for debugging instead of determining the stack trace itself?

My Suggestion (3)
Can you allow an extra parameter for DebugLogHandler.Internal_Log() or to DebugLogHandler.LogFormat() that allows us to pass in a skipFrames parameter? Here's how this would work:

(Unity does this somewhere internally)

Code (CSharp):

1. public static string ExtractStackTrace(int skipFrames)
2. {
3.     StackTrace stackTrace = new StackTrace(skipFrames, fNeedFileInfo: true);
4.     return ExtractFormattedStackTrace(stackTrace).ToString();
5. }

Thanks again! Looking forward to your eventual solution