http://www.bay12forums.com/smf/index.php?topic=168411.msg8256867#msg8256867

what you're describing makes sense to me, at least in principle. I would want to see examples in the pull request, but I can easily see merging it.

if possible make sure that there is clear usage demonstrated in the PR.

I was able to reproduce the issue on another computer. So I got what I wanted and you don't have to do it yourself. I am writing the instructions anyway.

Glad I could help. Btw cheers for all the efforts with Therapist. It makes the Dwarf Fortress micromanagement so much better experience for me!

Maybe not from NotifierWidget constructor, statusBar is only called if there are NotificationWidget children which are only added by add_notification. New guess: the absence of internet connection makes the updater fail fast and it tries to add a notification before the end of MainWindows constructor (check_for_updates is called near the end). This is a better explanation for

When I turn Auto-update off in Settings it works fine offline.

During MainWindow constructor m_main_window is not set but get_main_window may still be called.

fix #237

I was able to reproduce the issue on another computer. So I got what I wanted and you don't have to do it yourself. I am writing the instructions anyway.

• Download Windows 10 SDK (I downloaded the iso version from another computer to keep it offline)
• Only install "Debugging tools"
• Run WinDbg (X64)
• File → Open Executable... then select Dwarf Therapist.exe
• Debug → Go Unhandled Exception
• Either:
  • type k in the command prompt (easier for copy/pasting)
  • open View → Call Stack

Result:

 # Child-SP          RetAddr           Call Site
00 00000094`d556e710 00007ff7`e35203e4 Qt5Widgets!QMainWindow::statusBar+0x9
01 00000094`d556e740 00007ff8`c083ee32 DwarfTherapist+0x1003e4
02 00000094`d556e7d0 00007ff8`c081906d Qt5Widgets!QWidget::event+0x682
03 00000094`d556e9b0 00007ff8`c0818007 Qt5Widgets!QApplicationPrivate::notify_helper+0x13d
04 00000094`d556e9e0 00007ff8`bf888b39 Qt5Widgets!QApplication::notify+0x1ac7
05 00000094`d556f0d0 00007ff8`c084a17d Qt5Core!QCoreApplication::notifyInternal2+0xb9
06 00000094`d556f150 00007ff8`c0851d9a Qt5Widgets!QWidgetPrivate::sendPendingMoveAndResizeEvents+0x11d
07 00000094`d556f1f0 00007ff8`c0850359 Qt5Widgets!QWidgetPrivate::show_helper+0x2a
08 00000094`d556f260 00007ff8`c09de2d2 Qt5Widgets!QWidgetPrivate::setVisible+0x279
09 00000094`d556f2c0 00007ff7`e352028a Qt5Widgets!QDialog::setVisible+0x92
0a 00000094`d556f3a0 00007ff7`e34fb699 DwarfTherapist+0x10028a
0b 00000094`d556f430 00007ff8`bf8a96b7 DwarfTherapist+0xdb699
0c 00000094`d556f4b0 00007ff7`e3425f19 Qt5Core!QMetaObject::activate+0x507
0d 00000094`d556f5d0 00007ff7`e35a77e6 DwarfTherapist+0x5f19
0e 00000094`d556f620 00007ff7`e34f7855 DwarfTherapist+0x1877e6
0f 00000094`d556f7d0 00007ff7`e34a7137 DwarfTherapist+0xd7855
10 00000094`d556fab0 00007ff7`e34f521a DwarfTherapist+0x87137
11 00000094`d556fc10 00007ff7`e35c0147 DwarfTherapist+0xd521a
12 00000094`d556fce0 00007ff7`e35bf69e DwarfTherapist+0x1a0147
13 00000094`d556fd70 00007ff9`163437e4 DwarfTherapist+0x19f69e
14 00000094`d556fdb0 00007ff9`16c8cb81 KERNEL32!BaseThreadInitThunk+0x14
15 00000094`d556fde0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

I guess the call to setVisible is this one https://github.com/Dwarf-Therapist/Dwarf-Therapist/blob/589da28282636792d96efdf6e5cf29bfcaa2ac1b/src/notifierwidget.cpp#L43 which triggers a resize and call statusBar there https://github.com/Dwarf-Therapist/Dwarf-Therapist/blob/589da28282636792d96efdf6e5cf29bfcaa2ac1b/src/notifierwidget.cpp#L79

The issue is that this is called from NotifierWidget constructor which is called from MainWindow constructor which is called before m_main_window is set in DwarfTherapist: https://github.com/Dwarf-Therapist/Dwarf-Therapist/blob/589da28282636792d96efdf6e5cf29bfcaa2ac1b/src/dwarftherapist.cpp#L126 making DT->get_main_window() fail.

Now that I understand it, the mystery is why it does not happens more often. Anyway, thanks for your report, I'll try to fix this mess now.

This weekend I will be renaming our master branch to main. No commits should be lost, but remotes will need to be updated.

Merged those, and the branch is changed.

Sorry, this is not the kind of trace I was talking about. I meant a call/stack backtrace you can get with a debugger (windbg, gdb, ...) when the crash happens. Sadly, I cannot give exact instructions for Windows as I am not used to Windows debugging myself. I'll try to use windbg and come back with instructions later if I can.

Oh, sorry about that. Here's the screenshot in question:

Oh, sorry about that. Here's the screenshot in question:

Your screenshot doesn't appear to have come through. I'd suggest leaving a comment through GitHub's web interface instead of over email.

Alright, I've had some spare time and done some reading. Downloaded Process Monitor (https://docs.microsoft.com/en-gb/sysinternals/downloads/procmon) and looked for the stack trace you mentioned.

This is what I've found as a screenshot attached. I couldn't find an option to save it as text.

This time I have turned off the Auto-update option in DT 41.2.1 and closed it. Disconnected from the internet, run DT twice (no change here) and filtered the results of Stack Summary window in Process Monitor.

That's all I could get now. Let me know how can I improve my report.

Regards, Marcin

On Fri, Mar 5, 2021 at 7:38 PM Ma Pa [email protected] wrote:

I've never done it. I'll try to educate myself during the weekend and get back.

On a side note, I haven't mentioned it before, but when I first discovered the log I tried to overwrite the Qt5Widgets.dll with the one from DT 41.1.7. The program didn't run, nothing changed here, but the log changed. It now complained about Qt5Core.dll and I stopped trying. That's something I just now remembered.

Anyway, I'll let you know when I have what you asking for.

Regards, Marcin

On Fri, 5 Mar 2021, 15:33 Clément Vuchener, [email protected] wrote:

It's a real issue even if it is uncommon. It is not a waste of time. It would be easier if I could reproduce the bug with a debug build, it is hard to know what is happening without that.

The only information from the Windows crash report is the location in QtWidgets.dll. If I read correctly that would be in QMainWindow::statusBar() when dereferencing the this pointer.

.text:0000000180143BC0 ; struct QStatusBar *__fastcall QMainWindow::statusBar(QMainWindow *this) .text:0000000180143BC0 public ?statusBar@QMainWindow@@QEBAPEAVQStatusBar@@XZ .text:0000000180143BC0 ?statusBar@QMainWindow@@QEBAPEAVQStatusBar@@XZ proc near .text:0000000180143BC0 ; DATA XREF: .rdata:00000001804371B0↓o .text:0000000180143BC0 ; .rdata:00000001804371C0↓o ... .text:0000000180143BC0 .text:0000000180143BC0 arg_0 = qword ptr 8 .text:0000000180143BC0 .text:0000000180143BC0 push rdi .text:0000000180143BC2 sub rsp, 20h .text:0000000180143BC6 mov rdi, rcx .text:0000000180143BC9 mov rcx, [rcx+8]

This function is called in several places, but I cannot guess why the pointer would be invalid in any of these calls.

If you managed to get a stack trace, it might be helpful.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dwarf-Therapist/Dwarf-Therapist/issues/237#issuecomment-791456249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFYMS7K467UNL4Z6HZIW53TCDTUFANCNFSM4YS6NXXQ .

I've never done it. I'll try to educate myself during the weekend and get back.

On a side note, I haven't mentioned it before, but when I first discovered the log I tried to overwrite the Qt5Widgets.dll with the one from DT 41.1.7. The program didn't run, nothing changed here, but the log changed. It now complained about Qt5Core.dll and I stopped trying. That's something I just now remembered.

Anyway, I'll let you know when I have what you asking for.

Regards, Marcin

On Fri, 5 Mar 2021, 15:33 Clément Vuchener, [email protected] wrote:

It's a real issue even if it is uncommon. It is not a waste of time. It would be easier if I could reproduce the bug with a debug build, it is hard to know what is happening without that.

The only information from the Windows crash report is the location in QtWidgets.dll. If I read correctly that would be in QMainWindow::statusBar() when dereferencing the this pointer.

.text:0000000180143BC0 ; struct QStatusBar *__fastcall QMainWindow::statusBar(QMainWindow *this) .text:0000000180143BC0 public ?statusBar@QMainWindow@@QEBAPEAVQStatusBar@@XZ .text:0000000180143BC0 ?statusBar@QMainWindow@@QEBAPEAVQStatusBar@@XZ proc near .text:0000000180143BC0 ; DATA XREF: .rdata:00000001804371B0↓o .text:0000000180143BC0 ; .rdata:00000001804371C0↓o ... .text:0000000180143BC0 .text:0000000180143BC0 arg_0 = qword ptr 8 .text:0000000180143BC0 .text:0000000180143BC0 push rdi .text:0000000180143BC2 sub rsp, 20h .text:0000000180143BC6 mov rdi, rcx .text:0000000180143BC9 mov rcx, [rcx+8]

This function is called in several places, but I cannot guess why the pointer would be invalid in any of these calls.

If you managed to get a stack trace, it might be helpful.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dwarf-Therapist/Dwarf-Therapist/issues/237#issuecomment-791456249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFYMS7K467UNL4Z6HZIW53TCDTUFANCNFSM4YS6NXXQ .

In addition to support Python 3.10, several other small cleanups:

• linting, manifest checking, typing, and docs are done in Python 3.9
• the dev tools now include tox-asdf, black, flake8, and tox-pyenv

#154 and #157 might be small enough to merge first. But then, I would say that, wouldn't I? 😉

Good news! I very much need to do the same on some of my repos.

This weekend I will be renaming our master branch to main. No commits should be lost, but remotes will need to be updated.

in BaseMatcher there are:

• describe_mismatch (often overriden)
• describe_match (seldom overriden) https://github.com/hamcrest/PyHamcrest/blob/9063031c1de6aa39c5f0ccc1314220915b31c599/src/hamcres/core/base_matcher.py

in custom matcher example https://github.com/hamcrest/PyHamcrest#writing-custom-matchers there is

• describe_to -- seems bit inconsistent -- as it describes failure, but usually describes matcher itself

I'd expect the example to have sth like this

    ...
    day_as_string = [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday",
        "Saturday",
        "Sunday",
    ]

    def describe_mismatch(self, description):
        description.append_text("calendar date falling on ").append_text(self.day_as_string[self.day])
   
    def describe_to(self, description):
        description.append_text("calendar date on ").append_text(self.day_as_string[self.day])
   

The README is, per Simon's comment, intentionally minimal and doesn't try to capture the custom matcher authoring case in detail.

The f-string case is definitely a "we will get around to that at some point" change :)