LEAmDNS: _parseResponse keeps every answer record of a packet on the heap, so one large answer can abort with out of memory
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- arduino, cpp
- Lĩnh vực
- embedded-iot
Hướng nghiên cứu
Start in libraries/ESP8266mDNS/src/LEAmDNS_Control.cpp: trace _parseResponse through _readRRAnswer and _processAnswers, then compare with _parseQuery's record handling. The report proposes processing and freeing each response record before reading the next; done means response handling no longer retains all packet records at once while preserving probe and service query behavior. The reporter says they have a patched copy, but provides no test or captured packet.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happens
An ESP8266 (core 3.1.2, a GeekMagic SmallTV-Ultra with about 6 KB of free heap while running) restarted after
11.4 hours with an out-of-memory abort inside LEAmDNS. Our crash record, decoded with addr2line:
operator new (288 bytes) failed
<- MDNSResponder::_readRRAnswer
<- MDNSResponder::_parseResponse
<- MDNSResponder::_parseMessage
<- MDNSResponder::_process
free heap 952 bytes, largest free block 248 bytes
The lowest values recorded before, during those hours, were about 4.4 KB free and a 1.5 KB largest block. So
about 3.5 KB went within a moment. The sketch only advertises (MDNS.begin, addService, addServiceTxt, and
MDNS.update() in loop()); it sends no queries.
Why, from reading the code (master, libraries/ESP8266mDNS/src/LEAmDNS_Control.cpp)
_parseResponsereads answers only while a service query waits or a probe runs (line 742-743). Probing runs
afterMDNS.beginand again after every interface status change (LEAmDNS.cpp, thestatusChangeCBthat
calls_restart()), for example a Wi-Fi reconnect.- In that state, every record of the incoming packet (
ANCount + NSCount + ARCount, taken from the packet
header) is read with_readRRAnswerinto its own heap object and kept in a list (lines 764-775). - The list goes to
_processAnswersas a whole (line 794) and is freed only after that (lines 804-810).
So the heap needed grows with the number of records in someone else's answer. A phone, TV or speaker that
answers with many records during the probe window can take several KB at once. new aborts on failure in this
core, so the library's own checks for a failed allocation never run, and the result is a restart.
What we did not measure: we have not captured the packet, and we don't know for sure that a reconnect came just
before. That part is our reading of the code.
_parseQuery handles known answers differently: it frees each record right after reading it (so one record at a
time), which is why we think the same can work for responses.
Possible fix
Handle each answer record in _parseResponse as soon as it is read, and free it before reading the next, so the
peak is one record instead of the whole packet. That means splitting _processAnswers so it can take one record
at a time. A simpler, partial alternative: skip (read past without allocating) records whose names cannot
concern this responder.
We are trying the first approach in a patched copy for our own firmware and can open a PR if this direction is
welcome.
- Ngôn ngữ chính
- C++
- Star
- 16.7k
- Fork
- 13k
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 7
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của esp8266/Arduino
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
esp8266/Arduino#9342 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Typo in Scan Class DocumentationCó thể đã có người làm @MukundaKatta đã nhận 207 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
esp8266/Arduino#9203 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
esp8266/Arduino#9324 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của esp8266/Arduino
Issue tương tự
-
status:needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
PX4/PX4-Autopilot#29698 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
go perft exits when EvalFile is unavailableCó thể đã có người làm @Muawiya-contact đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
official-stockfish/Stockfish#7292 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
arvidn/libtorrent#9149 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Upstream report: MSVC rejects a designated initializer in a dependent template argument (C2131)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
rhalbersma/tabula#72 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày