Stack overflow when dropping a flat operator chain AST (parse succeeds)
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
- 58/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Start with src/ast/mod.rs and the parse_subexpr precedence loop mentioned in the issue; trace how operator chains are folded and how recursion limits are counted. Reproduce with the supplied Rust example, then check the existing recursion-limit tests. Done means dropping a long flat operator chain no longer overflows and the behavior respects the recursion limit (or safely drops the AST).
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
Parser::parse_sql accepts a flat left-associative operator chain and returns successfully, but dropping the returned Vec<Statement> then overflows the stack: the derived drop glue for the left-deep Box<Expr> tree recurses once per level with no guard. The process aborts (rc=134), and abort cannot be caught by the caller.
On a 2 MB stack (the default for spawned threads, including tokio workers) roughly 35,000 + operators — about 70 KB of input — is enough:
| stack | operators | input | result |
|---|---|---|---|
| 8 MB (main) | 130,625 | 261,258 B | parses and drops, rc=0 |
| 8 MB (main) | 132,000 | 264,008 B | prints parsed 1 statement(s) then aborts |
| 2 MB (thread) | 30,000 | 60,008 B | parses and drops, rc=0 |
| 2 MB (thread) | 35,000 | 70,008 B | prints parsed 1 statement(s) then aborts |
The parsed ... line is printed before the abort, so the overflow is in drop, not in parsing.
thread 'main' has overflowed its stack
fatal runtime error: stack overflow, aborting
Root cause
Expr and the rest of the AST derive Drop (src/ast/mod.rs). The only recursion guard on these types is
#[cfg_attr(feature = "recursive-protection", recursive::recursive)]
impl Display for Expr
at src/ast/mod.rs:1795; there is no impl Drop and no ManuallyDrop.
A flat chain such as SELECT 1+1+1... is built by the iterative precedence-climbing loop in parse_subexpr, so the recursion counter never fires, and the result is a left-deep BinaryOp { left: Box<Expr>, .. } spine. Dropping it walks that spine recursively, one stack frame per operator. Parser::with_recursion_limit does not help because parsing never recursed.
Reproduction
[dependencies]
sqlparser = "=0.63.0"
fn main() {
let n: usize = std::env::args().nth(1).and_then(|s| s.parse().ok()).unwrap_or(132_000);
let mut sql = String::from("SELECT 1");
for _ in 0..n { sql.push_str("+1"); }
let dialect = sqlparser::dialect::GenericDialect {};
let stmts = sqlparser::parser::Parser::parse_sql(&dialect, &sql).expect("parse");
println!("parsed {} statement(s), {} bytes", stmts.len(), sql.len());
drop(stmts);
println!("dropped ok");
}
$ cargo run --release -- 130625
parsed 1 statement(s), 261258 bytes
dropped ok
$ cargo run --release -- 132000
parsed 1 statement(s), 264008 bytes
thread 'main' has overflowed its stack
fatal runtime error: stack overflow, aborting # rc=134
SELECT 1=1 AND 1=1 ... shows the same behaviour.
Suggested fix
Count the chain length against the existing recursion accounting: when the precedence loop folds another operator onto the same chain, add it to RecursionCounter and return RecursionLimitExceeded past the limit, matching what deeply nested parentheses already do. Alternatively, implement an iterative Drop for Expr with an explicit work stack, which also covers trees built programmatically.
- Ngôn ngữ chính
- Rust
- Star
- 3.5k
- Fork
- 805
- Merge trung bình
- 2 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 116
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
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 apache/datafusion-sqlparser-rs
-
Redshift
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
apache/datafusion-sqlparser-rs#2959 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Redshift
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
apache/datafusion-sqlparser-rs#2958 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
PostgreSQL
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
apache/datafusion-sqlparser-rs#2862 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
PostgreSQL
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
apache/datafusion-sqlparser-rs#2861 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
PostgreSQL
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
apache/datafusion-sqlparser-rs#2858 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của apache/datafusion-sqlparser-rs
Issue tương tự
-
area:schema documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/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 82/100
ElectronicWave/Elemental#252 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
dekobon/big-code-analysis#1887 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Shell中文符号输入异常Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một 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