【Qt教程31】GCC 9.3.1 ARM64 下含 QString 结构体的隐式拷贝构造崩溃故障概况触发条件经实际验证验证过程最简复现无效的尝试有效的修复二选一根因修复建议复现 Demodemo_bug.hdemo_fix_a.h —— 方案 AQString 置顶demo_fix_b.h —— 方案 B显式拷贝构造demo_fix_b.cpp —— 方案 B 实现main.cppCMakeLists.txt排查经验总结参考原创作者郑同学的笔记原文链接https://zhengjunxue.blog.csdn.net/article/details/161613304故障概况项值OS中标麒麟 V10基于 Ubuntu 20.04架构ARM64 / aarch64编译器GCC 9.3.1Qt5.12.x崩溃位置QVariant::fromValue()→ 结构体隐式拷贝 →QString拷贝 →atomic_base::load同代码 x86_64正常触发条件经实际验证结构体中同时包含QString非平凡类型和int/double平凡类型且交错排列使用隐式拷贝构造函数编译器自动生成GCC 9.3.1 ARM64验证过程以下是在目标 ARM64 机器上的实测结果sizeof(QString) 8 alignof(QString) 8 alignof(DeviceConfig) 8 各 QString 偏移均为 8 字节对齐但夹在 int/double 之间: name offset 24 location offset 56 remark offset 80注意到各个 QString 偏移量本身都是 8 字节对齐的所以不是简单的未对齐导致原子操作崩溃。最简复现脱离 QTableWidget直接测 QVariant 拷贝即崩溃DeviceConfig cfg;cfg.freqHopRangeQStringLiteral(test);QVariant vQVariant::fromValue(cfg);// ← 崩溃在这里无效的尝试尝试结果参数从按值改为const传递无效添加alignas(16)无效添加Q_DECLARE_TYPEINFO(X, Q_COMPLEX_TYPE)无效添加qRegisterMetaTypeT()无效有效的修复二选一方案 A将所有 QString 移到结构体最前面structDeviceConfig{// 4 个 QString 集中放在最前面QString freqHopRange;QString freqShake;QString priShakeRange;QString priSequence;// 以下全是 int/double 等平凡类型intdeviceId;doublefreqCenter;doublefreqBandwidth;// ...};方案 B添加显式拷贝构造函数和赋值运算符放到 .cpp 文件中逐成员实现// .h 文件structDeviceConfig{// 成员保持原有顺序不需调整intdeviceId;doublefreqCenter;// ...QString freqHopRange;// ...DeviceConfig();DeviceConfig(constDeviceConfig);// 显式声明DeviceConfigoperator(constDeviceConfig);// 显式声明};// .cpp 文件 —— 逐成员拷贝不使用编译器隐式生成的版本DeviceConfig::DeviceConfig(constDeviceConfigother):deviceId(other.deviceId),freqCenter(other.freqCenter),freqBandwidth(other.freqBandwidth)// ... 每个成员逐一列出 ...,freqHopRange(other.freqHopRange){}DeviceConfigDeviceConfig::operator(constDeviceConfigother){if(this!other){deviceIdother.deviceId;freqCenterother.freqCenter;// ... 逐成员赋值 ...freqHopRangeother.freqHopRange;}return*this;}根因GCC 9.3.1 在 ARM64 上为大型结构体生成隐式拷贝构造函数时存在代码生成 bug。具体表现当QString含原子引用计数与int/double交错排列时GCC 9.3.1 在 ARM64 上生成的隐式拷贝代码在拷贝含原子操作的成员时产生了非法的指令序列导致atomic_base::load崩溃。触发条件与结构体的成员排列方式有关而非结构体大小的简单函数——同样的成员数、同样的大小QString 置顶就不崩交错就崩。这个 bug 的两个特征已被验证与 Qt 无关—— 同代码在 x86_64 的 GCC 9.3.1 下正常说明是 ARM64 后端的问题Qt5 的QString使用写时复制内部通过QAtomicInt管理引用计数。拷贝QString时会对引用计数做原子自增QString::QString(constQStringother):d(other.d){d-ref.ref();// atomic fetch_add}GCC 9.3.1 ARM64 在为大型结构体生成隐式拷贝构造函数时对这段QString拷贝的代码生成有问题导致 ARM64 原子操作指令在运行时触发异常。两个修复方案的原理方案 AQString 置顶改变结构体内存布局使 GCC 的隐式拷贝生成走不同的代码路径避开了 bug方案 B显式拷贝构造完全绕过 GCC 的隐式拷贝生成由开发者逐成员编写编译器的代码生成不会触发 bug修复建议二选一即可推荐方案 B方案 A 风险改变成员顺序属于 ABI 变更如果有序列化/反序列化、与旧版本数据文件兼容等需求需要验证方案 B 风险新增成员时容易忘记在拷贝构造/赋值中追加需要维护纪律。但成员顺序和二进制布局不变复现 Demo以下 demo 结构体模拟了崩溃场景QString 与 int/double 交错排列使用隐式拷贝构造。demo_bug.h#ifndefDEMO_BUG_H#defineDEMO_BUG_H#includeQString#includeQVariant#includeQMetaType// QString 与 int/double 交错排列——触发 GCC 9.3.1 ARM64 隐式拷贝构造 bugstructDeviceConfig{intid;doublefreq;intmode;QString name;// 夹在 int 之间intchannel;doublegain;QString location;// 夹在 double/int 之间intstatus;QString remark;// 夹在 int 之间DeviceConfig(){id0;freq0.0;mode0;nameQStringLiteral(default);channel0;gain0.0;locationQStringLiteral(default);status0;remarkQStringLiteral(default);}};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_a.h —— 方案 AQString 置顶#ifndefDEMO_FIX_A_H#defineDEMO_FIX_A_H#includeQString#includeQVariant#includeQMetaTypestructDeviceConfig{// ★ 3 个 QString 集中放在最前面QString name;QString location;QString remark;// 以下全是平凡类型intid;doublefreq;intmode;intchannel;doublegain;intstatus;DeviceConfig(){nameQStringLiteral(default);locationQStringLiteral(default);remarkQStringLiteral(default);id0;freq0.0;mode0;channel0;gain0.0;status0;}};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_b.h —— 方案 B显式拷贝构造#ifndefDEMO_FIX_B_H#defineDEMO_FIX_B_H#includeQString#includeQVariant#includeQMetaType// 成员顺序与崩溃版完全一致不改布局structDeviceConfig{intid;doublefreq;intmode;QString name;intchannel;doublegain;QString location;intstatus;QString remark;DeviceConfig();DeviceConfig(constDeviceConfig);// ★ 显式声明DeviceConfigoperator(constDeviceConfig);// ★ 显式声明};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_b.cpp —— 方案 B 实现#includedemo_fix_b.hDeviceConfig::DeviceConfig(){id0;freq0.0;mode0;nameQStringLiteral(default);channel0;gain0.0;locationQStringLiteral(default);status0;remarkQStringLiteral(default);}DeviceConfig::DeviceConfig(constDeviceConfigother):id(other.id),freq(other.freq),mode(other.mode),name(other.name),channel(other.channel),gain(other.gain),location(other.location),status(other.status),remark(other.remark){}DeviceConfigDeviceConfig::operator(constDeviceConfigother){if(this!other){idother.id;freqother.freq;modeother.mode;nameother.name;channelother.channel;gainother.gain;locationother.location;statusother.status;remarkother.remark;}return*this;}main.cpp#includeQApplication#includeQDebug// 测试时替换为 demo_bug.h / demo_fix_a.h / demo_fix_b.h#includedemo_bug.hintmain(intargc,char*argv[]){QApplicationapp(argc,argv);DeviceConfig cfg;cfg.id1001;cfg.freq150.0;cfg.nameQStringLiteral(sensor-A);cfg.locationQStringLiteral(building-3);qDebug()Testing QVariant::fromValue...;QVariant vQVariant::fromValue(cfg);// ← 崩溃在这里bug 版qDebug()QVariant::fromValue OK;DeviceConfig restoredv.valueDeviceConfig();qDebug()ID:restored.idName:restored.nameLocation:restored.location;return0;}CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(DemoBug) set(CMAKE_CXX_STANDARD 14) set(CMAKE_AUTOMOC ON) find_package(Qt5 REQUIRED COMPONENTS Core Widgets) add_executable(demo_bug main.cpp demo_fix_b.cpp ) target_link_libraries(demo_bug Qt5::Core Qt5::Widgets)排查经验总结不要过早下结论—— 最初的memcpy越界理论在 demo 上无法复现说明分析是错误的。只有通过对比实验显式 vs 隐式拷贝构造才能锁定根因在 GCC 的隐式代码生成Demo 复现—— 复现可能不触发编译器的特定优化路径复现 demo 无法接近真实场景最小化复现—— 脱离 QTableWidget 直接用QVariant::fromValue()测试排除了 UI 层的干扰参考GCC 9.x ARM64 代码生成相关 bug 可在 GCC Bugzilla 搜索 “aarch64 implicit copy constructor atomic”Qt5 QString Copy-on-WriteImplicit SharingARM64 原子操作指令LDXRB/STXRB系列要求地址自然对齐 【Qt教程31】GCC 9.3.1 ARM64 下含 QString 结构体的隐式拷贝构造崩溃
【Qt教程31】GCC 9.3.1 ARM64 下含 QString 结构体的隐式拷贝构造崩溃故障概况触发条件经实际验证验证过程最简复现无效的尝试有效的修复二选一根因修复建议复现 Demodemo_bug.hdemo_fix_a.h —— 方案 AQString 置顶demo_fix_b.h —— 方案 B显式拷贝构造demo_fix_b.cpp —— 方案 B 实现main.cppCMakeLists.txt排查经验总结参考原创作者郑同学的笔记原文链接https://zhengjunxue.blog.csdn.net/article/details/161613304故障概况项值OS中标麒麟 V10基于 Ubuntu 20.04架构ARM64 / aarch64编译器GCC 9.3.1Qt5.12.x崩溃位置QVariant::fromValue()→ 结构体隐式拷贝 →QString拷贝 →atomic_base::load同代码 x86_64正常触发条件经实际验证结构体中同时包含QString非平凡类型和int/double平凡类型且交错排列使用隐式拷贝构造函数编译器自动生成GCC 9.3.1 ARM64验证过程以下是在目标 ARM64 机器上的实测结果sizeof(QString) 8 alignof(QString) 8 alignof(DeviceConfig) 8 各 QString 偏移均为 8 字节对齐但夹在 int/double 之间: name offset 24 location offset 56 remark offset 80注意到各个 QString 偏移量本身都是 8 字节对齐的所以不是简单的未对齐导致原子操作崩溃。最简复现脱离 QTableWidget直接测 QVariant 拷贝即崩溃DeviceConfig cfg;cfg.freqHopRangeQStringLiteral(test);QVariant vQVariant::fromValue(cfg);// ← 崩溃在这里无效的尝试尝试结果参数从按值改为const传递无效添加alignas(16)无效添加Q_DECLARE_TYPEINFO(X, Q_COMPLEX_TYPE)无效添加qRegisterMetaTypeT()无效有效的修复二选一方案 A将所有 QString 移到结构体最前面structDeviceConfig{// 4 个 QString 集中放在最前面QString freqHopRange;QString freqShake;QString priShakeRange;QString priSequence;// 以下全是 int/double 等平凡类型intdeviceId;doublefreqCenter;doublefreqBandwidth;// ...};方案 B添加显式拷贝构造函数和赋值运算符放到 .cpp 文件中逐成员实现// .h 文件structDeviceConfig{// 成员保持原有顺序不需调整intdeviceId;doublefreqCenter;// ...QString freqHopRange;// ...DeviceConfig();DeviceConfig(constDeviceConfig);// 显式声明DeviceConfigoperator(constDeviceConfig);// 显式声明};// .cpp 文件 —— 逐成员拷贝不使用编译器隐式生成的版本DeviceConfig::DeviceConfig(constDeviceConfigother):deviceId(other.deviceId),freqCenter(other.freqCenter),freqBandwidth(other.freqBandwidth)// ... 每个成员逐一列出 ...,freqHopRange(other.freqHopRange){}DeviceConfigDeviceConfig::operator(constDeviceConfigother){if(this!other){deviceIdother.deviceId;freqCenterother.freqCenter;// ... 逐成员赋值 ...freqHopRangeother.freqHopRange;}return*this;}根因GCC 9.3.1 在 ARM64 上为大型结构体生成隐式拷贝构造函数时存在代码生成 bug。具体表现当QString含原子引用计数与int/double交错排列时GCC 9.3.1 在 ARM64 上生成的隐式拷贝代码在拷贝含原子操作的成员时产生了非法的指令序列导致atomic_base::load崩溃。触发条件与结构体的成员排列方式有关而非结构体大小的简单函数——同样的成员数、同样的大小QString 置顶就不崩交错就崩。这个 bug 的两个特征已被验证与 Qt 无关—— 同代码在 x86_64 的 GCC 9.3.1 下正常说明是 ARM64 后端的问题Qt5 的QString使用写时复制内部通过QAtomicInt管理引用计数。拷贝QString时会对引用计数做原子自增QString::QString(constQStringother):d(other.d){d-ref.ref();// atomic fetch_add}GCC 9.3.1 ARM64 在为大型结构体生成隐式拷贝构造函数时对这段QString拷贝的代码生成有问题导致 ARM64 原子操作指令在运行时触发异常。两个修复方案的原理方案 AQString 置顶改变结构体内存布局使 GCC 的隐式拷贝生成走不同的代码路径避开了 bug方案 B显式拷贝构造完全绕过 GCC 的隐式拷贝生成由开发者逐成员编写编译器的代码生成不会触发 bug修复建议二选一即可推荐方案 B方案 A 风险改变成员顺序属于 ABI 变更如果有序列化/反序列化、与旧版本数据文件兼容等需求需要验证方案 B 风险新增成员时容易忘记在拷贝构造/赋值中追加需要维护纪律。但成员顺序和二进制布局不变复现 Demo以下 demo 结构体模拟了崩溃场景QString 与 int/double 交错排列使用隐式拷贝构造。demo_bug.h#ifndefDEMO_BUG_H#defineDEMO_BUG_H#includeQString#includeQVariant#includeQMetaType// QString 与 int/double 交错排列——触发 GCC 9.3.1 ARM64 隐式拷贝构造 bugstructDeviceConfig{intid;doublefreq;intmode;QString name;// 夹在 int 之间intchannel;doublegain;QString location;// 夹在 double/int 之间intstatus;QString remark;// 夹在 int 之间DeviceConfig(){id0;freq0.0;mode0;nameQStringLiteral(default);channel0;gain0.0;locationQStringLiteral(default);status0;remarkQStringLiteral(default);}};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_a.h —— 方案 AQString 置顶#ifndefDEMO_FIX_A_H#defineDEMO_FIX_A_H#includeQString#includeQVariant#includeQMetaTypestructDeviceConfig{// ★ 3 个 QString 集中放在最前面QString name;QString location;QString remark;// 以下全是平凡类型intid;doublefreq;intmode;intchannel;doublegain;intstatus;DeviceConfig(){nameQStringLiteral(default);locationQStringLiteral(default);remarkQStringLiteral(default);id0;freq0.0;mode0;channel0;gain0.0;status0;}};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_b.h —— 方案 B显式拷贝构造#ifndefDEMO_FIX_B_H#defineDEMO_FIX_B_H#includeQString#includeQVariant#includeQMetaType// 成员顺序与崩溃版完全一致不改布局structDeviceConfig{intid;doublefreq;intmode;QString name;intchannel;doublegain;QString location;intstatus;QString remark;DeviceConfig();DeviceConfig(constDeviceConfig);// ★ 显式声明DeviceConfigoperator(constDeviceConfig);// ★ 显式声明};Q_DECLARE_METATYPE(DeviceConfig)#endifdemo_fix_b.cpp —— 方案 B 实现#includedemo_fix_b.hDeviceConfig::DeviceConfig(){id0;freq0.0;mode0;nameQStringLiteral(default);channel0;gain0.0;locationQStringLiteral(default);status0;remarkQStringLiteral(default);}DeviceConfig::DeviceConfig(constDeviceConfigother):id(other.id),freq(other.freq),mode(other.mode),name(other.name),channel(other.channel),gain(other.gain),location(other.location),status(other.status),remark(other.remark){}DeviceConfigDeviceConfig::operator(constDeviceConfigother){if(this!other){idother.id;freqother.freq;modeother.mode;nameother.name;channelother.channel;gainother.gain;locationother.location;statusother.status;remarkother.remark;}return*this;}main.cpp#includeQApplication#includeQDebug// 测试时替换为 demo_bug.h / demo_fix_a.h / demo_fix_b.h#includedemo_bug.hintmain(intargc,char*argv[]){QApplicationapp(argc,argv);DeviceConfig cfg;cfg.id1001;cfg.freq150.0;cfg.nameQStringLiteral(sensor-A);cfg.locationQStringLiteral(building-3);qDebug()Testing QVariant::fromValue...;QVariant vQVariant::fromValue(cfg);// ← 崩溃在这里bug 版qDebug()QVariant::fromValue OK;DeviceConfig restoredv.valueDeviceConfig();qDebug()ID:restored.idName:restored.nameLocation:restored.location;return0;}CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(DemoBug) set(CMAKE_CXX_STANDARD 14) set(CMAKE_AUTOMOC ON) find_package(Qt5 REQUIRED COMPONENTS Core Widgets) add_executable(demo_bug main.cpp demo_fix_b.cpp ) target_link_libraries(demo_bug Qt5::Core Qt5::Widgets)排查经验总结不要过早下结论—— 最初的memcpy越界理论在 demo 上无法复现说明分析是错误的。只有通过对比实验显式 vs 隐式拷贝构造才能锁定根因在 GCC 的隐式代码生成Demo 复现—— 复现可能不触发编译器的特定优化路径复现 demo 无法接近真实场景最小化复现—— 脱离 QTableWidget 直接用QVariant::fromValue()测试排除了 UI 层的干扰参考GCC 9.x ARM64 代码生成相关 bug 可在 GCC Bugzilla 搜索 “aarch64 implicit copy constructor atomic”Qt5 QString Copy-on-WriteImplicit SharingARM64 原子操作指令LDXRB/STXRB系列要求地址自然对齐