調研視窗：2026-10-26 08:00 ~ 2026-10-27 08:00（北京時間，24 小時）

信源：RT-Thread 官方新聞介面與社群文章介面、GitHub（主倉庫 commits / PR / Issue / releases / tags、RT-Thread/sdk、vscode-rt-smart、packages、pkgs-test、topic:rt-thread 生態檢索）、Google News 聚合（中英文六組查詢，走代理）、HN Algolia、行業媒體（電子工程專輯 RT-Thread 專欄）與廠商渠道核驗（詳見附錄信源清單）

本期索引

  • 一、核心與版本動態
    • 主線 24 小時零提交，最後一筆仍是 lwIP 迴環，組織內只有 VS Code 擴充套件在動（10-26）
    • 待合併佇列 13 個提案同日翻動，新增只有瑞薩 RA6W1 一筆（10-26）
  • 二、安全與穩定性跟進
    • signalfd 的全域性計數越界：第 11 次呼叫起把核心指標寫到堆塊之外（10-26）
    • musl 執行緒連結串列在併發退出下的釋放後使用：futex 鎖沒有起到互斥作用（10-26）
    • 時間子系統兩處修復轉為成熟版：settimeofday 去強轉、gmtime_r 處理負時間戳（10-26）
    • ESP-IDF v6.1 的 include 順序改由包側修：主倉提案關閉，esp-idf 包提案合入（10-26）
  • 三、工具鏈與開發體驗
    • vscode-rt-smart 0.4.14 合入：砍掉 4826 行，擴充套件從 IDE 收回成 Env 入口（10-26）
    • Eclipse 工程生成器漏傳核心宏：Studio 的 24 個隱式宣告警告有了解法（10-26）
  • 四、生態與廠商適配
    • 瑞薩 RA6W1 提交系統資源分配最佳化，BSP 進入二期完善（10-26）
    • STM32 乙太網補 ops 層與 SR8201F PHY，ADC 日誌等級下調（10-26）
  • 五、官方與社群
    • 官方新聞介面 24 小時無新增，最新一期停在 6 月 17 日（10-26）
    • 社群長文《rtthread啟動鏈路分析》：從 Reset_Handler 到 main 拆成三段（10-26）
    • 媒體側 24 小時無新稿，最近仍是 10-24 的 RISC-V 峰會報道（10-26）
  • 六、總結與趨勢觀察
    • 本期趨勢：合入停擺，缺陷報告與工具鏈改造接棒
    • 侷限性與去重說明

一、核心與版本動態

1.1 主線 24 小時零提交，最後一筆仍是 lwIP 迴環，組織內只有 VS Code 擴充套件在動（10-26）

日期：2026-10-26（核查時間）　來源：主倉庫提交記錄、組織倉庫列表

本視窗 master 沒有落任何提交。主倉庫最後一筆仍是 10-25 19:26 的 lwIP 迴環 netdev（#11893），再往前是 10-23 的 clang-format 規則收口（#11859），兩筆都已在上一期報告裡寫過。換句話說，10-26 一整天主線程式碼沒有前進，既沒有新合入，也沒有直接推送到 master 的維護性提交。

組織層面同樣安靜：35 個倉庫裡近 7 天有推送的只有 6 個，落在 24 小時視窗內的只有一個，即 vscode-rt-smart（10-26 22:35 的合併提交）。sdk 與 toolchains-ci 的最近一次動作停在 10-26 07:57 與 00:33，都在視窗起點之前，內容是上一期寫過的 TriCore 工具鏈與 QEMU 模擬器兩個包。packages 與 pkgs-test 的最後提交仍是 10-23。

版本側沒有變化：最新發布物與標籤還是 09-10 的 v5.3.0，沒有預釋出、沒有新標籤。

1.2 待合併佇列 13 個提案同日翻動，新增只有瑞薩 RA6W1 一筆（10-26）

日期：2026-10-26（最後更新）　來源：主倉庫提案列表

24 小時內共 13 個提案有新動作，其中 12 筆仍在審、1 筆關閉，沒有一筆合入——最近一次合入仍是 10-25 的 #11893。構成比較集中：修復類 6 筆（tmpfs 截斷 #11910、dlmodule 未初始化全域性量 #11915、串列埠 rx_indicate #11931、settimeofday #11928、gmtime_r #11929、NVMe 名稱空間洩漏 #11920），BSP 與驅動 3 筆（ESP32-S3 #11844、RA6W1 #11934、STM32 乙太網 #11819），工具類 3 筆（Eclipse 匯出 #11930、mkdist #11874、Keil/IAR 目標選擇 #11743），關閉的那筆是 #11926（見 2.4）。

當天新開只有 #11934 一筆。修復類佔比過半，說明評審側仍在推進，只是沒有形成合入。檢索結果裡另有兩筆 2018 與 2019 年的舊提案（#1956、#2461）因索引重新整理出現在更新列表中，不計入統計。

二、安全與穩定性跟進

2.1 signalfd 的全域性計數越界：第 11 次呼叫起把核心指標寫到堆塊之外（10-26）

日期：2026-10-26 16:13（建立時間）　來源：Issue #11933

這是本期分量最重的一條。研究者指出 components/libc/posix/io/signalfd/signalfd.c 裡用一個檔案作用域的全域性計數器 is_head_init 去索引每個檔案描述符私有的陣列 sfd->lwp[10]，而 signalfd_add_notify() 在使用前沒有任何邊界檢查。signalfd_close() 從不回退這個計數，所以它只增不減；新建上下文時又只清零 lwp[0 .. is_head_init-1]，同程序再次建立時永遠匹配不到自己，必然走寫入分支。

後果寫得很具體：lwp[] 是 struct rt_signalfd_ctx 的最後一個成員，整個結構在 arm32 上是 1536 位元組，陣列正好壓在堆塊末尾。第 11 次呼叫 signalfd(-1, ...) 時，寫入落在分配塊之外第一個字，即小記憶體分配器的下一個塊頭；此後每建立一次再向外推 4 位元組（64 位下 8 位元組步長），形成持續、由呼叫方控制節奏的核心堆越界寫，寫進去的值還是核心指標。

影響面按作者逐個標籤核對：引入點是 2023-09-11 的 7c3d966d（#8001），v5.0.2 / v5.1.0 / v5.2.0 / v5.2.1 / v5.2.2 / v5.3.0 與當前 master（5d1fb66d）全部命中。觸發前提只有 RT_USING_SMART=y——RT_USING_POSIX_SIGNALFD 在該配置下預設為 y，兩個官方 QEMU Smart BSP 的配置也都開著，因此預設的 RT-Smart 構建即可觸發。復現用 bsp/qemu-vexpress-a9（Cortex-A9、32 位、FAT sd 卡根檔案系統），PoC 以 /sbin/init 安裝。

目前該單無對應修復提案，也未打標籤。

2.2 musl 執行緒連結串列在併發退出下的釋放後使用：futex 鎖沒有起到互斥作用（10-26）

日期：2026-10-26 11:22（建立時間）　來源：Issue #11932

第二份缺陷單來自另一位報告者，環境是 RT-Thread 5.2.2 的 RT-Smart、SMP、aarch64、musl 1.2.5。現象是併發 pthread_create 與 pthread_exit 時使用者程序崩潰，崩點在 musl_pthread_exit：連結串列摘除時寫入的執行緒描述符已經被釋放或解除對映（Data Abort），或者執行緒的返回地址被改寫成 0（Instruction Abort）。

作者的定位結論是問題完全在使用者態：musl 用基於 futex 的 __tl_lock / __tl_sync 保護執行緒連結串列，但在 SMP 併發退出的場景下這組鎖沒有真正提供互斥，導致雙向連結串列被寫壞；核心側 futex 實現本身語義正確，不承擔這個缺陷。復現材料是一個 1000 輪、8 執行緒的 tl_race 程式，幾百輪內即崩。

該單帶 bug、Arch: ARM/AArch64、RT-Smart 三個標籤，附完整分析文件。與 2.1 一樣，落在 RT-Smart 這條線上，但層次不同：2.1 是核心堆，這一條是使用者態 libc。

2.3 時間子系統兩處修復轉為成熟版：settimeofday 去強轉、gmtime_r 處理負時間戳（10-26）

日期：2026-10-26 14:17 與 17:48（最後更新）　來源：PR #11928、PR #11929

上一期記錄的時間子系統四單，對應的兩筆修復在本視窗內推進了一步，且都勾選了「成熟版本，可合入」。

#11928 只改一個檔案，+185/-135：settimeofday() 原來先用 (long) 把 tv_sec 強轉再判斷正負，在 ILP32 且 time_t 為 64 位、long 為 32 位的配置下，2^31 到 2^32-1 之間的合法時間戳會被截成負數，函式在碰 RTC 裝置之前就以 EINVAL 拒絕——2208988800（2040-01-01）就是這樣被拒的。修法是按欄位自身型別校驗，不做強轉。

#11929 兩個檔案 +104/-9：gmtime_r() 用 C 的除法與取模拆時間戳，而 C 的除法向零截斷，負輸入下餘數為負，年份迴圈又只能往未來走，於是 -1 得到 1970-01-01 00:00:-1、-31536000 的年份欄位變成 1970-01--364。修法是把負數路徑規範化後再拆。

兩單都沒有合入。另兩筆（timer_gettime() 截斷 #11924、時間子系統工作項調研 #11927）本視窗內無新進展。

2.4 ESP-IDF v6.1 的 include 順序改由包側修：主倉提案關閉，esp-idf 包提案合入（10-26）

日期：2026-10-26 09:15 與 11:37（合入與關閉時間）　來源：RT-Thread-packages/esp-idf 提案 #19、主倉提案 #11926

上一期記錄的 #11926 想在主倉裡調整 ESP32 C3／C6 的 FreeRTOS 標頭檔案包含順序，以修掉 ESP-IDF v6.1 適配後 master 上的構建失敗。這輪討論給出了另一條路徑：維護者在評論裡提出「讓 AI 把 idf 改成 scons」，並指向包倉的提案 #19；另一維護者隨後追問是否要先合包倉那筆。

結果是包倉提案 #19（fix(scons): prioritize RT-Thread FreeRTOS headers）於 10-26 09:15 合入，主倉 #11926 於 11:37 關閉未合入。也就是說，標頭檔案優先順序問題在 SCons 構建指令碼層面解決，主倉不再改 include 順序。這條對 BSP 維護者的意義在於：esp-idf 相關構建問題今後優先在包倉處理，主倉只承擔核心與框架側改動。

三、工具鏈與開發體驗

3.1 vscode-rt-smart 0.4.14 合入：砍掉 4826 行，擴充套件從 IDE 收回成 Env 入口（10-26）

日期：2026-10-26 22:35（合入時間）　來源：vscode-rt-smart 提案 #38

組織內當天唯一的程式碼動作，是維護者本人提交併合併的擴充套件瘦身。49 個檔案 +883/-4826，版本號推到 0.4.14，產出的 vsix 為 1,296,751 位元組。

刪掉的東西比新增的多得多：Kconfig 檢視、SDK 管理器、工具鏈設定、符號分析（Symbolic Analysis）四塊功能整體移除，隨之退場的還有 ELF 與 DWARF 解析器（elf-parser.ts、dwarf-parser.ts、handleElf.ts 合計約 887 行）以及 291 行設定文件。RT-Thread Setting 檢視收窄到只做 Env 的安裝、更新與狀態顯示，同時保留工程根目錄配置。

新增的是一條編輯器內建瀏覽器命令與 code --open-url 的 URI 處理，並保留了原有的認證回撥；配套補了 140 行瀏覽器測試，作者給出的驗證口徑是 npm run compile、npm run lint、npm test（13 項透過）與 npm run package:vs 四步。

從產品定位看，這是一次明顯的退讓：擴充套件不再試圖在 VS Code 裡復刻 RT-Thread Studio 的配置與除錯能力，只保留「Env 入口＋內嵌瀏覽器」兩件事，把體量與維護面壓下來。

3.2 Eclipse 工程生成器漏傳核心宏：Studio 的 24 個隱式宣告警告有了解法（10-26）

日期：2026-10-26 23:33（最後更新）　來源：主倉提案 #11930

上一期收錄的社群長文記錄過「Studio 構建報 24 個 rt_sched_* 隱式宣告警告」，這輪有了對應提案：單檔案 +151/-2，從工程生成器一側修。

根因寫得很清楚：include/rtsched.h 裡的排程器介面由 __RT_KERNEL_SOURCE__ 與 __RT_IPC_SOURCE__ 兩個宏保護，gcc 與 armclang 分支在 src/SConscript 裡透過 LOCAL_CPPDEFINES 注入，命令列 scons 構建能識別，但 Studio 每次 make 之前呼叫的 tools/targets/eclipse.py 不收集這個組級定義，於是 dist 匯出工程出現 24 條 -Wimplicit-function-declaration：clock.c 1 條、ipc.c 7 條、thread.c 12 條、timer.c 1 條、scheduler_comm.c 3 條。

修法是把 __RT_KERNEL_SOURCE__ 提到 Kernel 組的全域性 CPPDEFINES，與既有的 msvc 分支保持一致。改動不涉及核心原始碼，只動工程生成指令碼。

四、生態與廠商適配

4.1 瑞薩 RA6W1 提交系統資源分配最佳化，BSP 進入二期完善（10-26）

日期：2026-10-26 18:22（建立時間）　來源：主倉提案 #11934

本視窗唯一新開的提案，來自瑞薩 RA6W1 方向的定期提交者，分支名 rcitach/sboot，5 個檔案 +191/-110，標題是「最佳化系統資源分配」。

RA6W1 的 BSP 走的是「先合骨架、後補驅動」的兩階段模式：首版在 8 月合入，之後由晶片原廠一側分批補充外設與電源管理。這筆落在第二階段，動的是啟動與資源分配相關的配置，不改外設驅動框架。提案模板裡的驗證 BSP 與 .config 兩欄尚未填寫，狀態仍是草稿口徑。

4.2 STM32 乙太網補 ops 層與 SR8201F PHY，ADC 日誌等級下調（10-26）

日期：2026-10-26 10:25（最後更新）　來源：主倉提案 #11819

一筆三合一的驅動提案，4 個檔案 +34/-3，覆蓋 STM32 側三處獨立問題。

一是 ADC 驅動預設日誌等級過高，正常使用時刷屏，改為 DBG_WARNING 並保留宏開關。二是 ETH 驅動缺少 ops 層適配，上層網路框架無法用統一介面操作裝置，本筆實現並註冊了 ops 回撥集。三是 PHY 驅動不支援 SR8201F，用該晶片的板卡無法起乙太網，本筆補了識別 ID、初始化流程與暫存器配置並加入 PHY 列表。驗證板是 stm32f429-atk-apollo，配置開了 RT_USING_DEVICE_OPS、BSP_USING_ETH 與 PHY_USING_SR8201F。

五、官方與社群

5.1 官方新聞介面 24 小時無新增，最新一期停在 6 月 17 日（10-26）

日期：2026-10-26（核查時間）　來源：官方新聞介面

組織分類的新聞列表仍返回 5 條，updatetime 分別為 2026-06-17（兩條）、06-11、06-09、06-02，涵蓋了阿布扎比投資論壇、第四屆軟體創新發展大會、臨港「滴水智匯」具身智慧活動、張江高科實驗小學的校外基地授牌與第五屆工業技術論壇。五條都是往期內容，本視窗無更新。

介面返回的欄位裡沒有釋出日期，只有 updatetime，正文中的事件時間也比 updatetime 更早（例如阿布扎比論壇正文寫的是 6 月 11 日、工業技術論壇寫的是 5 月 27 日），引用時以正文事件時間為準。

5.2 社群長文《rtthread啟動鏈路分析》：從 Reset_Handler 到 main 拆成三段（10-26）

日期：2026-10-26 08:59（釋出）　來源：社群文章：rtthread啟動鏈路分析

社群文章介面在視窗內只新增了這一篇，約 5700 字，作者自述環境是 STM32F103C8T6 + RT-Thread 4.0.3 + RT-Thread Studio 2.3.1（GCC），並宣告文中程式碼取自本工程實際構建，不是照抄手冊。

鏈路拆成三段：第一段是彙編，Reset_Handler 把 .data 初值從 Flash 搬到 SRAM、清零 .bss、調 SystemInit、跳 entry——作者特意點出一個常見誤解，SystemInit 並不把主頻配到 72MHz，它只是把 RCC 打回復位狀態並把 SCB->VTOR 設到 Flash 起始；第二段是 C 初始化，entry 進入 rtthread_startup()，rt_hw_board_init() 裡才配 72MHz 時鐘與堆，隨後建 main、timer、idle 三個執行緒；第三段是排程器啟動，rt_system_scheduler_start() 挑優先順序最高的就緒執行緒，預設先跑 timer 執行緒，main() 要等到 main_thread_entry() 裡 rt_components_init() 之後才出場。

文末還給了四個「容易記錯的點」與一節自驗方法，屬於讀核心程式碼時的常見困惑點彙總。

5.3 媒體側 24 小時無新稿，最近仍是 10-24 的 RISC-V 峰會報道（10-26）

日期：2026-10-26（核查時間）　來源：Google News 聚合（中文）

中英文六組查詢（精確串 3 天、睿賽德 7 天、睿擎 7 天、英文精確串 3 天、RTOS 3 天、作業系統 3 天）只回到兩條舊稿：10-24 電子工程專輯的《端側 AI 成 RISC-V 新戰場：RT-Thread 睿賽德全棧實踐亮相第六屆 RISC-V 中國峰會》，與 10-21 的《睿擎平臺 V1.8.4 釋出 編碼器、MIPI、GPIO 全方位升級》。兩篇分別已在 10-26 與更早的報告中收錄，本視窗無新增。

英文側三組查詢全部零命中。HN Algolia 的 19 條歷史命中最新停在 2025-05，視窗內四條候選均為 “threads” 字面誤匹配（Python 執行緒除錯工具、虛擬執行緒剖析、Threads 社交平臺 MCP），已全部剔除。

六、總結與趨勢觀察

6.1 本期趨勢：合入停擺，缺陷報告與工具鏈改造接棒（10-26）

日期：2026-10-26（本期）　來源：主倉庫提交記錄

四條線可以概括今天：

一是程式碼主線停擺。24 小時零提交、零合入，13 個提案在佇列裡翻動卻沒有一筆落地。上一期 72 小時視窗才落兩筆，今天的零提交是同一節奏的延續，開發側在等評審，評審側在等修復完善。

二是安全面繼續由外部研究者驅動。10-24 是時間子系統四單，今天換成 RT-Smart 的兩條：signalfd 的全域性計數越界（核心堆任意寫，v5.0.2 起全版本命中、預設配置可觸發）與 musl 執行緒連結串列的併發釋放後使用。兩條都不需要特殊硬體，QEMU 即可復現，且都指向「預設配置下的 Smart 構建」這一層。

三是工具鏈側由維護者本人動手。vscode-rt-smart 一次砍掉 4826 行，把擴充套件從「大而全的 IDE 替身」收回成 Env 入口加編輯器內瀏覽器；同一時間 Eclipse 匯出漏傳核心宏的問題也提了補丁，直指 Studio 下 24 條隱式宣告警告。

四是廠商側仍以 BSP 為主。瑞薩 RA6W1 進入二期資源分配最佳化，ST 補乙太網 ops 與 SR8201F PHY，樂鑫的 ESP32-S3 BSP 提案仍在 55 個檔案規模上等待評審，沒有晶片新品或架構級動作。

6.2 侷限性與去重說明

日期：2026-10-27（本期）　來源：主倉庫提交記錄

其一，官方新聞介面與社群文章介面均已核查，前者自 6 月起未更新，本期官方口徑無新內容。

其二，本期與 10-26 期不重疊：上一期視窗終點為 10-26 08:00，本期從該時點起算。#11910、#11915、#11920、#11901 等提案上一期已作為「待合併缺陷」彙總，本期不再重複展開，只在佇列統計中出現。

其三，未收錄 #2461、#1956、#2467、#5096 四條舊提案：檢索結果裡它們的更新時間落在本視窗，但關閉與合併時間分別是 2019、2018、2019、2021 年，屬於索引重新整理而非新事件。

其四，GitHub 匿名介面限額本輪接近上限，組織級核查用單次 sort=pushed 請求完成，未逐倉拉取全部事件；主倉庫提交以 commits 介面返回的前 100 條為準，已足以覆蓋 24 小時視窗。

附錄：信源核查表

信源 核查結果
RT-Thread 官方新聞介面（組織分類） 無新增，仍返回 5 條，最新 updatetime 停在 06-17
社群文章介面（article） 視窗內新增 1 篇：rtthread啟動鏈路分析（10-26 08:59）
GitHub 主倉庫 commits 視窗內 0 筆，最後一筆為 10-25 19:26 的 lwIP 迴環
GitHub 主倉庫 PR 13 筆更新，合入 0 筆，新開 1 筆（#11934），關閉 1 筆（#11926）
GitHub 主倉庫 Issue 新開 2 筆：#11933 signalfd 越界、#11932 musl 執行緒連結串列 UAF
GitHub 主倉庫 releases / tags 無新發布，最新仍為 09-10 的 v5.3.0
GitHub org 倉庫推送 35 倉中近 7 天 6 倉有推送，24 小時視窗內僅 vscode-rt-smart
GitHub RT-Thread/sdk 無視窗內動作（最近一次 10-26 07:57，TriCore 兩包，上期已收錄）
GitHub RT-Thread/packages 無視窗內動作（最後提交 10-23）
GitHub RT-Thread-packages/esp-idf 合入 1 筆：#19 標頭檔案優先順序修復
GitHub RT-Thread/pkgs-test 無視窗內動作（最後提交 10-23）
GitHub topic:rt-thread 2 倉推送（AKP05E 韌體、AWTK），均為生態參考，未收錄
Google News 聚合（中英文，走代理） 六組查詢，中文 2 條均為舊稿，英文 0 條
HN Algolia 四條候選均為 threads 字面誤匹配，已剔除
行業媒體（EET-China 專欄） 視窗內無新稿，最近一篇為 10-24 峰會報道

完整信源清單

com/RT-Thread/rt-thread/pull/11743>