Hi Tom and community members,

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_pipermail_gdb-2Dpatches_2026-2DOctober_231148.html&d=DwIBAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=f-oUQ8ByG1nZ71OI9p76qywCPh7mxzU69hBYnkP9Nis&m=ZqvNQdHjpMR8NN0gN2DAY-Qg76biG9X9nreFY45JXKG87ov0rUCcoCBwwm5e-m0d&s=mhF7tPz7DruvE3dGutyrsOFzFxdxwhNnTl7BB8s8a40&e=

>> Please see the stack in the mailing list link above I shared with
>> Simon. It has the backtrace plus core dump backtrace stack.

>Ok.  It's kind of hard to read that message for me (there's no
>line-wrapping in the web browser); but I tend to think the bug is in
>wchar_iterator.  I think it shouldn't be possible for it to read too
>much, or for m_bytes to wrap.


Thanks for the review. You were right that the bug is in wchar_iterator; the backtrace confirms it. On 64-bit AIX, wchar_t is 4 bytes wide, so the iterator is constructed with m_width = 4. When the target-wide charset is UTF-16, set_be_le_names resolves it to UTF-16BE, which uses 2-byte code units. In this case, iconv returns EILSEQ after consuming only 2 bytes, but the existing code still does:

m_input += m_width;   /* advances by 4 */

m_bytes -= m_width;   /* m_bytes was 4, wraps to a huge size_t */

The subsequent while (m_bytes > 0) loop then continues past the end of the buffer, eventually corrupting the stack and crashing inside libiconv's qsort. I will send a v3 that addresses this issue directly.

Regards,
Aditya.