Potential memory leak
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 25/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 停滯
- 技術堆疊
- c, javascript
- 領域
- tooling
研究方向
從 tools/gen_lib.js 中第 52 行附近的配置，以及第 63 行附近的清理開始。追蹤配置超過 FRAME_ALLOC_SIZE 時會發生什麼，然後判斷專案應該在達到限制時發出警告，還是移除固定配置方式。完成的標準是：超額配置的情況不再靜默洩漏，且所選擇的行為已記錄或驗證。
由索引模型根據 Issue 內容生成。
描述
It seems memory will be leaked if you allocate more pointers than FRAME_ALLOC_SIZE, or 1024*512, or 524,288.
https://github.com/konsumer/raylib-pointers/blob/7f2340c4b82fd13e4f00fe682c8b234e3b043ae9/tools/gen_lib.js#L52
Here's where you free only up to _frame_alloc_counter.
https://github.com/konsumer/raylib-pointers/blob/7f2340c4b82fd13e4f00fe682c8b234e3b043ae9/tools/gen_lib.js#L63
A few solutions off the top of my head:
- Show some warning when reaching the limit to make the memory leak obvious.
- Remove
FRAME_ALLOC_SIZEaltogether. I think a good way to do that is to only ever have one pointer allocated that'll be used to carry the result, but is freed on the next raylib-function call. Then the receiving/duping/allocating can be done by JS on the JS side, instead of the C side.
- 主要語言
- C
- 星號
- 0
- 分支
- 1
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
konsumer/raylib-pointers 的其他 Issue
-
enhancement parent
難度 5/5 一週以上 新手友好度 25/100
-
C enhancement todo
難度 4/5 3-5 天 新手友好度 28/100
-
defines (bun)未關閉bunjs enhancement todo
難度 2/5 1-3 小時 新手友好度 48/100
-
bunjs enhancement todo
難度 4/5 3-5 天 新手友好度 35/100
-
bunjs enhancement todo
難度 3/5 1-2 天 新手友好度 45/100
查看 konsumer/raylib-pointers 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
area: test kind: bug preview-effort: small priority: low
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
libsdl-org/SDL#16684 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
-
Issue-Bug Needs-Triage
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 2 天內回覆