-
Notifications
You must be signed in to change notification settings - Fork 106
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
LaunchWrapper outputs a mile of error messages when legacy.debugClassLoading is enabled for WindowsAnsiOutputStream #22
Comments
Assuming by your mention of the PR that you're using a custom compiled version, have you tried adding |
That does seem to solve it (I added |
Can you send the full mile? I thought I found something useful but it was cut off by your “skipping several hundred lines”. |
It should be in the outlong.zip I linked before the bit, but I'm not 100% sure (it's been a while). |
I found the problem, I will fix it soon. |
What problem? the "mile long" log is caused by it trying to classload a Log4J related class through the LaunchClassLoader while its trying to use it itself, which just won't work. The fix for it is commented in this thread & linked via a commit on a branch |
(n.b. the "mile" part isn't an exaggeration -- the output is 282602 lines long, and assuming 4 lines per inch, we have 5888 feet or 1.115 miles)
If
legacy.debugClassLoading
is enabled, a HUGE number of errors are output. This makes it very hard to use to actually find real errors. Here's my log:outlong.zip
The class that is failing is
org.fusesource.jansi.WindowsAnsiOutputStream
, and when it fails, it generated a VERY long error:The following ones are all
NullPointerException
s, but I'm not sure whether it's actually an NPE or just a stack overflow in disguise. They're for the same class, though.Granted, these issues do not happen when the property is disabled. However, I still think 30 megabytes of error message is a bit excessive, even if the user normally cannot see it. Also, these errors probably negatively impact start times (although they aren't logged, they still happen).
These errors do go away if the system property
log4j.skipJansi
is set totrue
(mentioned on https://stackoverflow.com/a/29879464/3991344).It's worth noting that these errors are not captured into the game output log — but that's to be expected, as it's while log4j is loading. In this case I captured it using my test case from here with
systemProperty 'legacy.debugClassLoading', 'true'
in thetest
block of the buildscript and./gradlew test --info
, but it can also happen in the actual launcher with-Dlegacy.debugClassLoading=true
. As a second note, this is with the fix from #16; otherwise the actual class is obscured.The text was updated successfully, but these errors were encountered: