log4j's XMLLayout writes the event time in milliseconds since the epoch, but
parseAttributes() handed it to QDateTime::fromSecsSinceEpoch(). Every entry in
the Minecraft Log tab therefore carried an instant about 55000 years out, and
once rendered as HH:mm:ss it showed a clock time with no relation to when the
line was actually logged.
The launcher's own sample log shows it plainly: the first two events of
testdata/TestLogs/vanilla-1.21.5.xml.log are stamped 1745005148589 and
1745005150587, just under two seconds apart, which is also how far apart they
are in the plain text capture of the same startup sequence. Read as seconds
they land 33 minutes apart, in the year 57267.
The added test compares instants rather than rendered clock times, so it does
not depend on the time zone it runs in.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: umutcagand <237324081+c8dhjp4tyv-bit@users.noreply.github.com>
Lines reach LogParser one at a time and log4j's XMLLayout never breaks the
`<log4j:Event` start tag across lines. isPotentialLog4JStart() nevertheless
accepted any prefix of that tag, so a line ending in `<` - an emoticon such as
`>w<`, a truncated generic, a stray bracket - got torn in two: the text before
the bracket was flushed as plain text and the `<` was stashed as partial data,
only to reappear glued to the front of the following line.
Require the whole `<log4j:Event` token, and require the element name to end
there: a prefix can never be completed by later input, and `<log4j:Eventually`
names a different element that would be swallowed just the same way. Events
spread over several lines still carry the complete name on their first line, so
they keep parsing as before - including the case where the attributes follow on
the next line. As a side effect this drops a toString().toLower() allocation
from a path that runs for every `<` in every log line.
Four of the new test rows fail on the old parser - the first two lose text from
the end of the line, the other two swallow the line that follows - and the rows
covering real events pass either way, so they also pin down that the check has
not become too strict. parseLines() now uses a local parser, as a row that
leaves partial data behind would otherwise leak it into the next one.
Fixes#5825
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: umutcagand <237324081+c8dhjp4tyv-bit@users.noreply.github.com>
guessLevel() required the log line's timestamp bracket to contain only
digits and colons, so it never matched real log4j output that includes
a full date and milliseconds (e.g. "[23Jul2026 18:12:07.877] [main/WARN]
[...]"). Lines fell through to Unknown level and were left uncolored,
even with "Color lines" enabled. The live "Minecraft Log" console tab
wasn't affected since it gets levels from log4j's XML event stream
instead of this text heuristic.
Signed-off-by: desvaters <71886240+desvaters@users.noreply.github.com>
This sets our compiler requirements to gcc 11 and clang 13. If we
forgo the use of `using enum` we can drop to gcc 10 and clang 10 but
that means using `MessageLevel::Enum::Unknown` for direct enum access
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Trial97