tree 8cc1a0be90ed0198757a042819563c969cc3eeb9
parent 40a0e3430442c7ec72e84063ea4b679700d4c3d8
author Jeremy Day <jeremy@thebrowser.company> 1743636902 -0700
committer GitHub <noreply@github.com> 1743636902 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJn7cmmCRC1aQ7uu5UhlAAAe38QAAwSBLLN8716PtR/oJ3h6w3b
 6CZ8t5o9l1h3SGjqCpmZZsC+0cBqFeVQbFYusGtUoaAolW0Gm97/dbxmaxNf3Sdd
 S2/MxJmrJkvGEOtOqOsVdyLFjS0EhhuKOkQ9SH2bOy9a3nUoYbqOuqJ9sUf2p4+w
 DRbkUmcc7ajDj1dvmHq4JnNeTBbyiDlaIC6JIr2lJ569XOYdBTm6PL7fYBlF71If
 QJJ/ejcR2eGhxHHLjnV5fyZ0Ejr9c5JqGmMwU8N26ECxXTH0Q6HpuyWSpPaUK6Xy
 xud5mvnUWzPFOXTWfQEAgM493gMkvkLo0IMaHFJbXLQyku/QrqQga+1jqN3PgzWE
 KciA6BeYjq1ALzq8nPI7TSzK2l7157Joh0IYMnxqpz2SgK7qa92t2G9+8c+/L3Sh
 xM02JacRkPNlt15p0tahnxNU1S5zWo7x/Fpb8wtEe63xEdM1kUREkNeNMVykjIFV
 9VE79ClCr1uYIjEg1ucwFH6Hvi9nQ0HKjKuZa3DusUrBApP4pbvjgiZ5x3hkFyRb
 d/JiNaDSOahHfO4gDcFBNkhoHOkKoX5lf92vhAEs/YRAtW9gVhhjIspEzzjkLYd9
 k0g7C2NFYjZRioFefKmpU2MwuwzbRa0N5f6XIlgoMPJgjL++1lmvo0DQoY54q/ue
 iuf1lql5TspS0eaq4Nk8
 =L9Ov
 -----END PGP SIGNATURE-----
 

[lldb] Clear thread name container before writing UTF8 bytes (#134150)

`llvm::convertUTF16ToUTF8String` opens with an assertion that the output
container is empty:
https://github.com/llvm/llvm-project/blob/3bdf9a08804a5b424fd32fef3b0089f3a6db839d/llvm/lib/Support/ConvertUTFWrapper.cpp#L83-L84

It's not clear to me why this function requires the output container to
be empty instead of just overwriting it, but the callsite in
`TargetThreadWindows::GetName` may reuse the container without clearing
it out first, resulting in an assertion failure:
```
 # Child-SP          RetAddr               Call Site
00 000000d2`44b8ea48 00007ff8`beefc12e     ntdll!NtTerminateProcess+0x14
01 000000d2`44b8ea50 00007ff8`bcf518ab     ntdll!RtlExitUserProcess+0x11e
02 000000d2`44b8ea80 00007ff8`bc0e0143     KERNEL32!ExitProcessImplementation+0xb
03 000000d2`44b8eab0 00007ff8`bc0e4c49     ucrtbase!common_exit+0xc7
04 000000d2`44b8eb10 00007ff8`bc102ae6     ucrtbase!abort+0x69
05 000000d2`44b8eb40 00007ff8`bc102cc1     ucrtbase!common_assert_to_stderr<wchar_t>+0x6e
06 000000d2`44b8eb80 00007fff`b8e27a80     ucrtbase!wassert+0x71
07 000000d2`44b8ebb0 00007fff`b8b821e1     liblldb!llvm::convertUTF16ToUTF8String+0x30 [D:\r\_work\swift-build\swift-build\SourceCache\llvm-project\llvm\lib\Support\ConvertUTFWrapper.cpp @ 88] 
08 000000d2`44b8ec30 00007fff`b83e9aa2     liblldb!lldb_private::TargetThreadWindows::GetName+0x1b1 [D:\r\_work\swift-build\swift-build\SourceCache\llvm-project\lldb\source\Plugins\Process\Windows\Common\TargetThreadWindows.cpp @ 198] 
09 000000d2`44b8eca0 00007ff7`2a3c3c14     liblldb!lldb::SBThread::GetName+0x102 [D:\r\_work\swift-build\swift-build\SourceCache\llvm-project\lldb\source\API\SBThread.cpp @ 432] 
0a 000000d2`44b8ed70 00007ff7`2a3a5ac6     lldb_dap!lldb_dap::CreateThread+0x1f4 [S:\SourceCache\llvm-project\lldb\tools\lldb-dap\JSONUtils.cpp @ 877] 
0b 000000d2`44b8ef10 00007ff7`2a3b0ab5     lldb_dap!`anonymous namespace'::request_threads+0xa6 [S:\SourceCache\llvm-project\lldb\tools\lldb-dap\lldb-dap.cpp @ 3906] 
0c 000000d2`44b8f010 00007ff7`2a3b0fe8     lldb_dap!lldb_dap::DAP::HandleObject+0x1c5 [S:\SourceCache\llvm-project\lldb\tools\lldb-dap\DAP.cpp @ 796] 
0d 000000d2`44b8f130 00007ff7`2a3a8b96     lldb_dap!lldb_dap::DAP::Loop+0x78 [S:\SourceCache\llvm-project\lldb\tools\lldb-dap\DAP.cpp @ 812] 
0e 000000d2`44b8f1d0 00007ff7`2a4b5fbc     lldb_dap!main+0x1096 [S:\SourceCache\llvm-project\lldb\tools\lldb-dap\lldb-dap.cpp @ 5319] 
0f (Inline Function) --------`--------     lldb_dap!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 
10 000000d2`44b8fb80 00007ff8`bcf3e8d7     lldb_dap!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
11 000000d2`44b8fbc0 00007ff8`beefbf6c     KERNEL32!BaseThreadInitThunk+0x17
12 000000d2`44b8fbf0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c
```

This stack trace was captured from the lldb distributed in the Swift
toolchain. The issue is easy to reproduce by resuming from a breakpoint
twice in VS Code.

I've verified that clearing out the container here fixes the assertion
failure.