fix(windows): fix double free (STATUS_HEAP_CORRUPTION) of resizing handler's userdata

[s5bug]

Using WM_NCDESTROY instead of WM_DESTROY is more correct for freeing userdata, as windows can receive multiple WM_DESTROY events if they're parented. WM_NCDESTROY is the last message a window can ever receive, whereas we were experiencing behavior where our application would crash due to a Tauri window receiving multiple WM_DESTROY events.

We tracked this down with ASAN (which reports a double-free almost immediately in our application) and this change fixes the issue.

[github-actions]

Package Changes Through 5e1d54f

There are 8 changes which include tauri-utils with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-bundler with patch, tauri-runtime-wry with patch, tauri with minor, @tauri-apps/api with minor, tauri-plugin with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.7.0	2.8.0
tauri-utils	2.6.0	2.7.0
tauri-bundler	2.5.2	2.5.3
tauri-runtime	2.7.1	2.7.2
tauri-runtime-wry	2.7.2	2.7.3
tauri-codegen	2.3.1	2.3.2
tauri-macros	2.3.2	2.3.3
tauri-plugin	2.3.1	2.4.0
tauri-build	2.3.1	2.3.2
tauri	2.7.0	2.8.0
@tauri-apps/cli	2.7.1	2.8.0
tauri-cli	2.7.1	2.8.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[Legend-Master]

Thanks, could you also add a change file?

https://github.com/tauri-apps/tauri/blob/dev/.changes/README.md

as windows can receive multiple WM_DESTROY events if they're parented

I still want to know how/why is it receiving multiple WM_DESTROY events though, I don't think that should normally happen, and we might have another bug to fix

[s5bug]

I wouldn't be surprised if it's due to some weird behavior with cross-parenting and not Tauri's fault at all? Google didn't help at all in that regard (I started off writing this trying to just prevent the double-free rather than seeing if the logic being in WM_DESTROY was the root issue). I'll go ahead and add a changes file!

[s5bug]

Reading online says WM_DESTROY can be received multiple times if one sends WM_DESTROY manually instead of calling DestroyWindow... haven't checked if this happens in Tauri at all (and don't know how I would, as the few minutes it took me to write this today is the extent of my familiarity with the Tauri codebase)

For the record, without ASAN, the behavior in production Tauri as of right now means it still takes quite a while to receive a STATUS_HEAP_CORRUPTION. We had to create and destroy a bunch of windows to turn the double-free into a tangible error. It wouldn't shock me if there's issues elsewhere that nobody's caught just because they're so probabilistic, and getting ASAN to work on Windows is a chore (´・ω・`)

[Legend-Master]

Reading online says WM_DESTROY can be received multiple times if one sends WM_DESTROY manually instead of calling DestroyWindow

Yeah, also calling DestroyWindow multiple times I believe

haven't checked if this happens in Tauri at all

I don't think we have any code sending WM_DESTROY, but can't be certain about calling DestroyWindow multiple times (since we do call it but we don't send WM_DESTROY manually like ever)

For the record, without ASAN, the behavior in production Tauri as of right now means it still takes quite a while to receive a STATUS_HEAP_CORRUPTION. We had to create and destroy a bunch of windows to turn the double-free into a tangible error. It wouldn't shock me if there's issues elsewhere that nobody's caught just because they're so probabilistic, and getting ASAN to work on Windows is a chore (´・ω・`)

If it doesn't cause any other problems after this change, I guess we just call it a day 🙃

[Legend-Master]

Thanks again 🙃