Daniel P. Berrangé <[email protected]> writes: > This series is a tangent that came out of discussion in > > https://lists.nongnu.org/archive/html/qemu-devel/2025-08/msg00903.html
This was about error messages providing sufficient information both for users and for developers. Manos proposed to print a stack backtrace on programming errors and fatal errors (&error_abort and &error_fatal), enabled at configure time. He found this useful for debugging a use-after-free. Daniel pointed out that GDB shows better stack backtraces, and that we could not enable this feature in distro builds. He wondered whether showing just thread names would do. > In thinking about adding thread info to error_report, I understand why that can be useful for developers in certain scenarios, but I feel it results in error reporting that is overly vebose and unwieldy for users. I'd prefer optional, default off. > I > came to realize we should likely make qemu_log behave > consistently with error_report & friends. We already > honour '-msg timestamp=on', but don't honour 'guest-name=on' > and also don't include the binary name. I'm willing to accept a message format common to error reporting and log if that's useful. Backed by shared code, obviously. Why could it be useful, and to whom? Error messages are both for users and developers. Both need them to be clear and detailed enough to figure out what's gone wrong, and what to do about it. Developers can use additional detail. Lots and lots of it at times. No excuse for dumping it all on users. Carefully designed logs can also be for both. Much of what QEMU can log is just for developers, and that's *fine*. Sometimes developers want to log lots of detail per message, sometimes they don't, to keep the logs managable, as Peter pointed out. When the error message needs of users and developers conflict, I put users first. When the logging needs of users and developers conflict, I put developers first. > As an example of the current state, consider mixing error and > log output today: Having the errors in the log can clearly be useful. The easiest way to have them in the log is --- wait for it --- logging them. We don't do that now. Instead, you can log to stderr, or you can piece together log file contents and error messages. The format differences can be inconvenient either way. Could we log errors? > - Default context: > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ > -d 'trace:qcrypto*' > qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55ac6d97f700 > dir=fish > qcrypto_tls_creds_get_path TLS creds path creds=0x55ac6d97f700 > filename=ca-cert.pem path=<none> > qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such > file or directory > > - Full context: > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ > -d 'trace:qcrypto*' \ > -msg guest-name=on,timestamp=on \ > -name "fish food" > 2025-08-19T20:14:16.791413Z qcrypto_tls_creds_x509_load TLS creds x509 load > creds=0x55e9a3458d10 dir=fish > 2025-08-19T20:14:16.791429Z qcrypto_tls_creds_get_path TLS creds path > creds=0x55e9a3458d10 filename=ca-cert.pem path=<none> > 2025-08-19T20:14:16.791433Z fish food qemu-system-x86_64: Unable to access > credentials fish/ca-cert.pem: No such file or directory > > And after this series is complete: > > - Default context: > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ > -d 'trace:qcrypto*' > qemu-system-x86_64(1184284:main): qcrypto_tls_creds_x509_load TLS creds > x509 load creds=0x55a24ad5cb30 dir=fish > qemu-system-x86_64(1184284:main): qcrypto_tls_creds_get_path TLS creds path > creds=0x55a24ad5cb30 filename=ca-cert.pem path=<none> > qemu-system-x86_64(1184284:main): Unable to access credentials > fish/ca-cert.pem: No such file or directory > > - Full context: > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ > -d 'trace:qcrypto*' \ > -msg guest-name=on,timestamp=on \ > -name "fish food" > 2025-08-19T20:12:50.211823Z [fish food] qemu-system-x86_64(1168876:main): > qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x5582183d8760 dir=fish > 2025-08-19T20:12:50.211842Z [fish food] qemu-system-x86_64(1168876:main): > qcrypto_tls_creds_get_path TLS creds path creds=0x5582183d8760 > filename=ca-cert.pem > +path=<none> > 2025-08-19T20:12:50.211846Z [fish food] qemu-system-x86_64(1168876:main): > Unable to access credentials fish/ca-cert.pem: No such file or directory > > The main things to note: > > * error_report/warn_report/qemu_log share the same > output format and -msg applies to both I fear this is a bad idea. I apologize for being so late with this. I didn't think hard enough until now. Unified format with separate configuration controls and defaults could be okay. > * -msg debug-threads=on is now unconditionally enabled > and thus the param is deprecated & ignored This part just makes sense. > * Thread ID and name are unconditionally enabled > > * Guest name is surrounded in [...] brackets > > * The default output lines are typically 15 chars > wider given that we always include the thread > ID + name now > > * This takes the liberty of assigning the new file > to the existing error-report.c maintainer (Markus) > Since splitting it off into message.c instead of > putting it all in error-report.c felt slightly > nicer. > > One thing I didn't tackle is making the location > info get reported for qemu_log. This is used to > give context for error messages when parsing some > CLI args, and could be interesting for log messages > associated with those same CLI args.
