为何MinGW-W64编译的64位Windows EXE加字符串赋值崩溃，32位正常？

问题根源 #

你这个操作本身就是非法的，和64位/32位架构没有直接关系，只是64位编译环境下的运行时库暴露了这个错误：

• 代码中fontname一开始接收read_setting_s的返回值，PuTTY的这套工具函数返回的是堆上动态分配的内存指针，后续所有分支逻辑都会调用sfree(fontname)释放这块内存
• 你直接将fontname赋值为字符串常量"Consolas"，这个字符串存储在程序的只读数据段，不属于堆内存范畴，sfree尝试释放不属于动态分配的内存地址，属于典型的非法内存操作。

为什么32位编译下没有崩溃 #

不同架构、不同编译器的C运行时库对free类函数的非法输入容错逻辑不同：

• 32位MinGW、MSVC 2008的运行时库，对传入free的非法指针校验比较宽松，遇到非堆地址可能直接跳过释放操作，不会主动触发崩溃
• 64位MinGW-W64的运行时库增加了更严格的内存校验，检测到释放非法地址时直接触发访问错误，也就是你遇到的APPCRASH。

修复方法 #

不要直接给指针赋值字符串常量，要把常量内容复制到堆内存中，适配原代码的内存管理逻辑，把你修改的那行替换为：

fontname = sstrdup("Consolas");

PuTTY内置的sstrdup会在堆上分配对应大小的内存、复制字符串内容，后续sfree释放这块内存就完全合法。

内容的提问来源于stack exchange，提问作者Oso B