It would be nice if PulseView provided a way for users to view the debug output from PulseView (and libserialport and libsigrok and libsigrokdecode) either via some GUI menu item ("Show log" or such), or better, PulseView could store all the debug output in a pv.log or similar file (in the current directory, or the application's install directory), so that it can still be viewed by the user, even after a crash. This is especially useful on Windows, where PulseView generally runs "independent", without any console attached that could receive the debug output. Right now, the user has no possibility to debug any Windows issues. Note: Even when lauched from a "cmd.exe", Pulseview detaches immediately and no log output will appear in the terminal (the detaching is a good thing though and not a bug, PulseView shouldn't keep an open "DOS box" around, of course). The PulseView output should be handleable easily, the debug output from the libs can also be gathered via callbacks like sr_log_callback_set(), srd_log_callback_set(), and sp_set_debug_handler().
IIRC the stdout data is shown in WinDbg - a free debugger for windows. Would this be adequate? If not maybe we can implement some command line option for this.
A command-line option to specify a log filename (and possibly loglevel for finer-grained control) would be best, yeah. This can default to no file and no logging, only if the option is supplied will PulseView make a logfile in the specified directory/file (or in the current directory or such, if none is specified).
My concern with logfiles is that a thrown exception won't be written to the log unless we catch it in Application::notify() and save the log there. With an incomplete log file however, saving a log for debugging purposes isn't entirely useful. On the other hand, a log window would also close when PV crashes, so that would be even less useful.
Logging is now implemented, so the cause for this bug report is solved. Crashes on Windows are still an issue and boost::stacktrace support was added for this use case. It's however not enabled yet, so I'm going to close this bug and open a new one to track the stack trace issue.