The thread name is often more meaningful than a number or pointer.
[ChangeLog][QtCore][Logging framework] QMessagePattern /
QT_MESSAGE_PATTERN now support the %{threadname} placeholder.
Change-Id: I7ad8821c8b887e428023144d6e93e20c53bf757e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Making it qt_maybe_message_fatal(). Thus we're less likely to forget to
do the right thing.
Change-Id: Ie3c344d9f64527fc755ffffdd3c97cf8fa3fcc90
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends commit df2e07549e6edd1d271cce1d86cadd4a33dfd8fc which removed
this file from the bootstrap build.
Drive-by remove pre-thread_local content, which isn't needed in 2025.
Change-Id: I406c748a5f0aedb5a846fffde5a2f5eb5f875f14
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
By moving one of the #if, we can remove the other.
Change-Id: I167cf466ef965758e5e8fffd94f8f8169599e3c6
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
All modern compilers implement divisions and modulus via multiplications
and shift, so the codegen is practically the same (three multiplications
in total). But the new code allows more than 136 years of uptime (49710
days).
Drive-by fix indentation in nearby line.
Pick-to: 6.9
Change-Id: Iea806bd7dfac1f852c66fffd41c2ac6660e7cc65
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
There's nothing wrong with those two, but we don't need the middle men
to the monotonic clock. This also reduces the sizeof QMessagePattern by
one quint64 (QElapsedTimer is 16 bytes in Qt 6).
Pick-to: 6.9
Change-Id: I0eb171f03ee8f3a7148bfffd5534a7f3daba3a01
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Amends commit e04f109456bbcb184963b8ed71944b958b35c201.
This function does not free the pointers stored in literals, so add a
couple of assertions to indicate that it's only safe to call from the
constructor. And that being the case, we can update the tokens
unique_ptr in two steps, which makes the compiler not attempt to call
delete[] on the previous pointer.
Pick-to: 6.9
Change-Id: Ibe76a7df795e9c6d6191fffdf45e3b3ef6f0f344
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
So we don't have to parse it on first use if it isn't set. This should
be a small performance gain for everyone who uses the default, which is
usually the majority of people.
Pick-to: 6.9
Change-Id: I10c471715457dcfa3a1dfffd2768ce605e4f7e30
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The extra information is already stored in the journal metadata anyway,
so there's no need to duplicate it. This matches the Apple Unified
Logger output now.
For most people, the visible difference will be that the category name
is not included in the plain "journalctl" output.
Aug 22 21:25:43 tjmaciei-mobl5 akonadi_imap_resource[4948]: org.kde.pim.kimap: Connection to server lost QAbstractSocket::HostNotFoundError
Aug 22 21:27:17 tjmaciei-mobl5 kwin_x11[3376]: kwin_core: XCB error: 3 (BadWindow), sequence: 41165, resource id: 29363347, major code: 129 (SHAPE), minor code:>
journalctl does not make it easy to show extra fields, but it's there
and can be retrieved with -o verbose.
[ChangeLog][QtCore][Logging] The Qt logging framework (qDebug/qWarning/etc)
will now only send the plain, unformatted message to systemd's journald,
if this backend is enabled. The category and other fields are sent via
metadata to journald, so they can be filtered on and retrieved using
journalctl. This matches what Qt does for the Apple Logging support and
does not apply when Qt is using syslog or stderr to communicate with
journald.
Change-Id: Ifa1111900d6945ea8e05fffd177de8f47d74ba60
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
87d8ee755bfdef8e72a122789c2e3ed382881a12 changed the logging behavior
on Android to use the category as tag. But it was missed that
`formatLogMessage` only fills the fields given in the messagePattern.
Our default messagePattern includes the category but on Android it
is never filled since this change.
So we change the default messagePattern on Android to omit the category
and only use the category as tag when the category is not given in the
messagePattern.
Pick-to: 6.8 6.5
Task-number: QTBUG-94708
Change-Id: I80f65d0f7f8c0ca9c2fff2dcd63d4599848b6e2b
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The <QtLogging> documentation page is easily found, and from there it's
not easy to see that categorized logging is a feature. Add more links.
Pick-to: 6.8
Task-number: QTBUG-125589
Change-Id: I214b9a561d6fc6b4c8600bc1b1eca04d856678d6
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When Marc introduced them way back in 2012 in commit
c856e37c5fddec64d8635f3dae57b9cbea1aada4 ("Logging: mark qt_assert()/
qt_assert_x()/qFatal() as nothrow"), he said:
> QT_TERMINATE_ON_EXCEPTION, which expands to something like
> try { expr; } catch(...) { std::terminate(); }
> if the compiler doesn't support Q_DECL_NOEXCEPT
Well, all compilers now support noexcept, so we always had the plain do
{ } while (0) expansion instead.
Change-Id: If3345151ddf84c43a4f1fffd17d27dbc0f100ec7
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
You could get the idea that the underlying int value is indicative
of the severity. Make it more explicit that the order in the text
is the correct one, and reorder for Qt 7.
While at it, remove mentioning of Qt 5.5.
Pick-to: 6.7
Fixes: QTBUG-102347
Change-Id: I5d1b46afb37e50baa209a06c192a943980ca774b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
C++23 gave us a standardized way to gather backtraces,
so we can use it to add cross-platform support for
%{backtrace}.
Guard the feature via a compile test; at the moment,
this is enabled it on MSVC only. GCC has experimental
support (requires linking against libstdc++exp), so it
will still fail the test.
[ChangeLog][QtCore][QDebug] Support for the %{backtrace}
expansion has been extended to the platforms supporting C++23's
<stacktrace> header (such as MSVC 2022 >= 17.4).
Change-Id: I04d58a193384a61e4f8e6fef78286d4bad98a025
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Log using emscripten_log by default, unless
QT_FORCE_STDERR_LOGGING has been set.
It is now possible to log at different levels:
qDebug() -> Info
qWarning() -> Warning
qCritical() -> Error
#ifdef out functions which are now no longer in use
on Q_OS_WASM
Change-Id: I0485e5c070069998a8dfc6759c02bc3b7d6a8a4b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
"Just in case" -- as the comment says,
QInternalMessageLogContext's constructor is usually inlined, but
we can't be sure if it has been.
Change-Id: I4da2f0875d9fd9f7bd6d79447b4761fda329c7fd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of deep inside the processing of the message pattern tokens.
This reduces the number of uninlineable functions in release builds to
2. Experimentation shows that even in debug mode our overhead to
backtrace() is just 2, despite the debugger's backtrace showing 3 frames
-- the debugger is using QtCore's debug symbols and does know about the
inlined function.
As a nice side-effect, we capture the backtrace only once per message,
not once per %{backtrace} token in the QT_MESSAGE_PATTERN.
Change-Id: I01ec3c774d9943adb903fffd17b7d6de09167620
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QMessageLogContext is a primitive type that may be extended in the
future with more fields (it has been at version 2 since commit
6d166c88220ee09821b65fb2b711fa77a5312971, though that did not extend the
struct's size). This introduces a QInternalMessageLogContext which is
used in before all our calls to qt_message_output().
Currently there's no difference and no way to tell that the internal
version is used.
Change-Id: I01ec3c774d9943adb903fffd17b7d5abc0052207
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The name says it's a warning, it's pretty unexpected that it should
lead to a critical message.
One case where this is a problem is QTBUG-48488
where merely printing with "Microsoft Print To PDF" and canceling
the file dialog leads to "QWin32PrintEngine::begin: StartDoc failed"
as a *critical* message. Some Windows applications have a message
handler that shows a msgbox in case of a critical message,
and getting such a msgbox after canceling the file dialog seems very
wrong.
Task-number: QTBUG-48488
Pick-to: 6.7
Change-Id: I1c842340dd2faf2be6e64e0522f9e2b33547d3cf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The ones in qlogging.cpp were copied to it from qglobal.cpp in commit
23688d8942895507f4bc1517dd3c161134f4f9d0. They existed in qglobal.cpp
like in qdebug.cpp since the beginning of the public history. The one in
qdebug.cpp already made no sense in Qt 4 times, because qdebug.cpp was a
documentation-only source (no actual C++ code).
The #undefs from qglobal.cpp hadn't been necessary since commit
d394ca7f27197cfbfc28eb9a08eb0db261dd9d3d, the global functions qDebug(),
qWarning(), qCritical(), etc. were replaced by member functions in
QMessageLogger whose names did not match the macros.
Pick-to: 6.7
Change-Id: I50e2158aeade4256ad1dfffd17b1c62f23eca4db
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Neither win_outputDebugString_helper() nor OutputDebugString() add a
newline at the end of the message, so one needs to be added before being
passed to the output handler.
A newline was previously present but removed when deduplicating calls to
qFormatLogMessage().
Fixes: QTBUG-121947
Pick-to: 6.7
Change-Id: I9f1c1d8726e4234f24999f47c52340140d5a4614
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We only have two tools that use the Bootstrap lib and neither of them
need nor want the message pattern functionality.
Change-Id: Ifa1111900d6945ea8e05fffd177e191ebb6afc4f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Instead of the exported qFormatLogMessage() that users can use. Because
it's a local symbol (static function), neither dladdr() nor
backtrace_symbols() functions should be able to see them, making their
exclusion from the list a simpler check.
This doesn't apply when the user calls qFormatLogMessage() in their own
handler, unless the compiler either inlines or tail-calls the new,
internal function. The latter case is very likely.
Change-Id: Ifa1111900d6945ea8e05fffd177e187f55512725
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Instead of only printing to stderr or the Windows debug buffer. I guess
this wasn't done before because the code could recurse back and cause
stack overflows. We can do it now without recursion problems.
Change-Id: Ifa1111900d6945ea8e05fffd177e14e2f86ae482
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Instead of duplicating its stderr handling.
Change-Id: Ifa1111900d6945ea8e05fffd177e149dfa9afff9
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Lift it up from inside of each of the message sinks and instead perform
the formatting in qDefaultMessageHandler(). This necessitated having a
trait indicating whether the sink takes formatted output or not
(currently, only the Apple backend is unformatted).
Change-Id: Ifa1111900d6945ea8e05fffd177e155db9a599cc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Namely, a function pointer to the actual sink function.
This doesn't remove the future ability to iterate over multiple sinks,
but I removed the comment anyway because it doesn't look like we'll ever
implement that.
Change-Id: Ifa1111900d6945ea8e05fffd177de7fa46230259
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Mention that QtMessageHandler needs to be reentrant,
as well as other caveats. Mention QLoggingCategory,
so people do know that they don't have to necessarily
implement their own handler to filter messages (and that
not all messages reach the handler). Also mention
qFormatLogMessage().
Finally, give a more useful example for a custom
message handler that logs to a file. Note that the example
leaks a file handle at exit, but that is arguably not that
bad.
Pick-to: 6.5 6.6
Change-Id: I5be44167b266c9bbdbb0e94806bb024c9b352a32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Just so memory leak checkers won't complain.
Pick-to: 6.6
Change-Id: I2b24e1d3cad44897906efffd177fb9ddf0eb0a2a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Just roll everything up into qt_message().
Pick-to: 6.6
Change-Id: I2b24e1d3cad44897906efffd177fb9867131b795
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Also while touching code, replace arg usage with QSB to prevent temp allocation
Change-Id: I3573266dbee8a00ae917773c107b5df7774acb79
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
EM_LOG_DEMANGLE does nothing from emscripten 3.1.44 and is marked
deprecated. Also, it doesn't work for strict mode functions as
described in PR 19820, and needs the deprecated arguments.callee.
Change-Id: I4d71f50caa75373253881c4153acbc6ab38fcf18
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Rewritten to be a bit simpler, added a few more yield/YieldProcessor
alternatives, added RISC-V support.
[ChangeLog][QtCore] Added qYieldCpu() function.
Fixes: QTBUG-103014
Change-Id: I53335f845a1345299031fffd176f59032e7400f5
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QtSystemMsg has been an alias to QtCriticalMsg since Qt 4 times,
probably because of the misleading name. Let's formally deprecate
the enum now, so that it at one point (Qt 7?) can be finally removed.
Change-Id: I385b62a77ceb66f75f318a00a73ea5e7333bf4f1
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
ASSERT: "size_t(i) < size_t(size())" in file qbytearray.h, line 492
due to info being emptied out completely and then the code does
while ((info.at(0) == '*')
info was empty because the recent fix "that wasn't the function argument
list" would exit the loop with pos at end.
Incidentally, this change fixes the fact that qCleanupFuncInfo was
removing lambdas:
main(int, char**)::<lambda()>
became
main(int, char**)::
which was, well, shorted, but weird.
Pick-to: 6.6 6.5
Change-Id: Ic7e8f21ea0df7ef96a3f25c4136a727dc0def207
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Much like QT_FATAL_WARNINGS, QT_FATAL_CRITICALS also is
interpreted as a counter. Revamp both function descriptions
to make scope and purpose clearer.
Also, mention logging rules as a way to surpress output,
in addition to a custom message hander.
Pick-to: 6.5 6.6
Change-Id: I44767abb067a6accd81f13dc549c9787ef9a4729
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CAS failures should result in PAUSE/YIELD, cf. qYieldCpu() docs.
qYieldCpu() is only available since Qt 6.3, though, so adding it as a
follow-up with limited pick-to.
Task-number: QTBUG-115062
Pick-to: 6.6 6.5
Change-Id: Ibcc73881875a47935940015e30b9a27a282054d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code first checked for == 0, then, if false, executed a
fetchAndAdd(-1), both with relaxed memory ordering. This can lead to
executions that, counter to what the code comment states, can count
down past 0:
// T1 T2
loadRelaxed() // true
loadRelaxed() // true
fetchAndAddRelaxed(-1) // e.g. 1 → 0
fetchAndAddRelaxed(-1) // 0 → -1
while fatality is detected exactly once, this execution doesn't stop
at 0 and causes further calls to isFatal() to count down further, with
the (very) remote spectre of underflow past INT_MIN.
Fix by using a CAS loop instead, so each count-down uses only one
step, not two, which therefore can no longer interleave.
Fixes: QTBUG-115062
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: If77b906c94cb4b9fa91bfad84fe63bc8d9103b0a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Extract Method on the count-down algorithm of fatalCriticals and
fatalWarnings, so we don't have the repeat the calculation and the
comment.
Task-number: QTBUG-115062
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I4bcbc2f5a21b999e7f301085581677b437a889e9
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Avoids -Wsometimes-uninitialized warnings with clang-cl.
Also do not allow to return qt_message_fatal() if built with other
compiler than MSVC.
Amends 97b32fa0b661c5dd89d525122427496132abb54a
Fixes: QTBUG-113351
Change-Id: I9ce87057e764af1e25de93388ae983891df66d2e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ioctl call for FIONREAD takes an int arg, it won't work correctly
otherwise. Cast the return of the read() call to int, because it won't
read more than buffSize (which is an int).
Change-Id: I130202a732684257bbb0e79c9358b60a61010c46
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Saw this on my FreeBSD VM. The backtrace() function thought the nearest
symbol to something was "_ZTSNSt3__110__function6__baseIFbPvS2_EEE",
which decoded to
typeinfo name for std::__1::__function::__base<bool (void*, void*)>
The function pointer type inside parameter threw the decoder for a loop
and caused it to crash with the failed assertion in qbytearray.h:
inline char QByteArray::at(qsizetype i) const
{ Q_ASSERT(size_t(i) < size_t(size())); return d.data()[i]; }
I noticed this
- because tst_qtimer hung
- because qFormatLogMessage deadlocked acquiring QMessagePattern::mutex
- because the logging recursed
- because qCleanupFuncinfo failed an assertion while formatting the
backtrace (my QT_MESSAGE_PATTERN has %{backtrace})
- because QTimer::~QTimer -> QObject::killTimer printed a warning
- because tst_QTimer::moveToThread produces warnings
Pick-to: 5.15 6.2 6.4 6.5
Change-Id: Ieec322d73c1e40ad95c8fffd17464f86e9725991
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
When Qt is configured to return nullptr from isNull() QStrings
(QT5_NULL_STRINGS != 1), then we'd be feeding a nullptr src into
strncpy(), which is UB. I couldn't rule the case of a null QString
lexeme out with local reasoning, seeing as the code is in the else
branch of an if (lexeme.startsWith(~~~) && lexeme.endsWith(~~~)), so
it might be null.
Instead of porting to qstrncpy(), which can deal with a nullptr src
(albeit up to recently, badly), note that the strncpy + the char[]
allocation is a qstrdup(), so use that instead. This also does away
with the queasiness of taking the size() of a UTF-16 string to limit
strncpy() for the L1-recoded version (which, in this instance is safe,
as toLatin1().constData() is NUL-terminated, but in some other
instances was not).
As a drive-by, make sure we don't leak the strdup()'ed string if the
emplace_back() fails.
Amends be98fa32c7d56ea91359b647a329356fa44eca04.
Qt 5 is not affected, as constData() never returns nullptr there.
Pick-to: 6.5 6.4 6.2
Change-Id: I178d356e560d2749cd6ce0b9364c710a2d117304
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
