Opened 16 months ago

Last modified 15 months ago

#1123 new defect

ESS_GUI branch - no logs appear in console or in sasview.log

Reported by: tcbennun Owned by:
Priority: major Milestone: SasView Next Release +1
Component: SasView Keywords:
Cc: wojciech, piotr Work Package: SasView Bug Fixing

Description

I'm finding that all the app's logs are directed solely to the QT GUI (the Log Explorer dock), despite the specification at src/sas/logging.ini to also use the console and log file (this config is the same as that in the master branch).

Initially I thought usage of the XStream class in src/sas/qtgui/Utilities/SasviewLogger.py was preventing logs from being processed by the other handlers, but having commented out all reference to that file and removed the Log Explorer dock entirely, there is still no output to the console or log file (which is created, but not written to).

I've never seen PyQT break the logging module before, so I'm at a loss for now.

Change History (4)

comment:1 Changed 16 months ago by piotr

This must have broken when moving from py2/qt4 to py3/qt5 as serialization to the file was present there.
I didn't create any unit tests for this functionality, which is why we didn't notice the issue before.

comment:2 follow-up: Changed 16 months ago by tcbennun

SetupLogger._update_all_logs_to_debug had been temporarily changed at some point so all handlers only handled warning messages and above, rather than debug. Reverting this seemed to fix the issue. Strangely though, I wasn't even seeing error messages before this change.

comment:3 in reply to: ↑ 2 Changed 16 months ago by tcbennun

Replying to tcbennun:

SetupLogger._update_all_logs_to_debug had been temporarily changed at some point so all handlers only handled warning messages and above, rather than debug. Reverting this seemed to fix the issue. Strangely though, I wasn't even seeing error messages before this change.

In fact, this hasn't fixed the issue. The vast majority of logs are not appearing (those sent from within signal handlers are disappearing, as far as I can tell). It's a major hassle when it comes to debugging!

comment:4 Changed 15 months ago by tcbennun

JIRA: Torin Cooper-Bennun, 11 Jul 2018 13:59

Multiple issues surfaced here:

  1. The XStream class completely redirects stdout and stderr output to its messageWritten signal (caused logs to disappear from console)
  2. In multiple places, the logging level was variously set to WARNING or INFO (caused logs to disappear from log file)
  3. The log configuration (in logging.ini) was being totally overwritten in sas.qtgui.Utilities.SasviewLogger, whereas it was only necessary to add a QtHandler to the existing configuration (may have caused logs to disappear from log file)

The solution for 1 is to have XStream instances save the original text stream object (e.g. sys.stdout) and both write to it, and emit the messageWrittensignal.

For 2 and 3, all log configuration should happen in sas.logger_config using the logger.ini file as a basis, with the exception of the QtHandler set-up; if QtHandler is set up at that stage, then signals are not emitted (probably because Qt has not been initialised yet). Therefore QtHandler set-up should remain in sas.qtgui.Utilities.SasviewLogger.

The changes made so far are in branch ESS_GUI_iss957 in the following commit: https://github.com/SasView/sasview/commit/5dba493865ca4dde5a4220a06e044a33a56ae211


Summary of email conversation with Piotr:

The behaviour of the stdout/stderr redirection is highly platform-dependent, and the Python logging module seems to interfere. Currently no stdout/stderr redirection occurs any more, but logs themselves are directed to the QT GUI through a custom logging handler.


A pull request has been opened: https://github.com/SasView/sasview/pull/158

Last edited 15 months ago by tcbennun (previous) (diff)
Note: See TracTickets for help on using tickets.