[1.12] Crash when persisting a defterm window #11354
Labels
Area-Settings
Issues related to settings and customizability, for console or terminal
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Needs-Tag-Fix
Doesn't match tag requirements
Priority-1
A description (P1)
Product-Terminal
The new Windows Terminal.
Resolution-No-Repro
We couldn't get this to happen, or it stopped happening entirely.
Severity-Crash
Crashes are real bad news.
Milestone
Comments
zadjii-msft
added
Issue-Bug
ghost
added
the
Needs-Triage
|
I'm also seeing a crash on exit sometimes, but my machine's running Windows 10 (so don't have defterm enabled) and I don't have window persisting enabled either. I'm on commit 2be394f. The stacktrace looks similar (it's difficult to compare as the one above isn't formatted - you need to put a blank line between the |
|
@ianjoneill Yea I'd file a new issue for that, that looks like a different stack to me. If they do come down to the same root cause then we can re-dup them later but my gut says they aren't. FWIW I had a similar crash to the OP one this morning, and that was not persisting a defterm window, that was just closing a couple tabs, so maybe that element of the repro isn't necessary. |
|
I don't have a W11 install so I can't help with any defterm issues, but if there are consistent repro steps for the other crash on close I can try to fix that. Although crashing on trying to revoke an event handler seems unrelated to my changes 🤷 |
|
Another day, another crash. No defterm in this one. Defterm might not be the root cause, but it did trigger it for me 2/2 times during the bug bash. DetailsThis is a slightly different stack, and I'm working off d053f6c so it's possible this is just in the local branch. Wanted to post somewhere for posterity before I close the debugger. |
|
Any information about what the actual exception is, in addition to the call stack? My best guess is that there are places where I am capturing I haven't seen an exception thrown on that get logged while closing the |
|
In that part of the call stack, I have no idea. I have yet to hit this with VS with "break on RoOriginate exceptions" on, but I haven't been trying too hard at that. But I do get breaks into the post-mortem debugger pretty frequently, so this is a "definitely gotta figure this out" for 1.12 |
|
Another day, another crash DetailsNo defterm involved, and this one was on #11404, which is a little behind main but not enough that I'd write it off. I'm not sure more stacks like this are actually going to help me figure this out at all 😕 |
|
Is this something that you can reproduce on W10 as well? Can you get the error still if persisting windows is turned off? I'm still struggling to reproduce that error. |
|
Does this happen when you use the |
|
Unfortunately, I don't have a Win10 laying around easy ;__; That one was definitely through just a close with the X. I still haven't really debugged too thoroughly. Thought I'd leave the stack here in case it was relevant in the future, but it almost certainly isn't. I still need to find some time to put this through the wringer |
|
Oh many it did happen again, on 1.12.2781.0 which is todays bugbash build. Not totally sure what happened again:
I think there were defterms in the monarch but can't be sure. Wasn't expecting it - we went through the whole bash without running into this, until I was signing out of the meeting. VERY possible that this is just a different manifestation of #11366 |
|
INTERESTING. This morning, I hit the crash here: DetailsIn the AppHost dtor, trying to read the Very interesting. I forget why tearing the |
|
Perhaps something like this would help with that last stack trace, but I don't know if it is sufficient to actually solve the problem generally. |
|
You know, that's probably right, because I hit the following this morning with a breakpoint on the DetailsSo yea, cleaning those up early is probably a good idea. EDIT 10/7/21Hit it again in a peasant window that wasn't under a debugger or anything. Just wanted to close the window. No SUI in that window ever. At the very least we should prvent the persist from doing something after the |
DHowett
removed
the
Needs-Triage
PankajBhojwani
pushed a commit
that referenced
this issue
Oct 20, 2021
Don't crash if we try to save the window layout while we are closing, and try to avoid saving at all. Might impact #11354 ## Detailed Description of the Pull Request / Additional comments - Revoke the event handler/save throttler so we don't even try to get the window layout when we are closing - Try to check for nullptrs, but then apply `try {} CATCH_LOG()` liberally ## Validation Steps Performed The happy path of saving normally is still fine, but I haven't been unlucky enough to trigger the crash myself.
PankajBhojwani
pushed a commit
that referenced
this issue
Oct 20, 2021
Don't crash if we try to save the window layout while we are closing, and try to avoid saving at all. Might impact #11354 ## Detailed Description of the Pull Request / Additional comments - Revoke the event handler/save throttler so we don't even try to get the window layout when we are closing - Try to check for nullptrs, but then apply `try {} CATCH_LOG()` liberally ## Validation Steps Performed The happy path of saving normally is still fine, but I haven't been unlucky enough to trigger the crash myself.
|
I'm clearing the Blocking tag, as this is (1) a Preview feature and (2) not reproing ?? |
DHowett
removed
the
Severity-Blocking
|
I'll do you one better - I haven't seen this in months. I'm not leaving a no repro bug open like this. I'll know where to find it if I see it again. |
zadjii-msft
added
the
Resolution-No-Repro
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
discovered in the 1.12 bug bash on 9/28
pwshso that it opens as a new defterm window.Details
See also: #11083, #9800
The text was updated successfully, but these errors were encountered: