Stack overflow when dropping a flat operator chain AST (parse succeeds)
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 58/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- rust
- Domaine
- backend-api-design
Piste de recherche
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).
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Rust
- Étoiles
- 3.5k
- Forks
- 805
- Merge moyen
- 2 j 3 h
- PR mergées (30 j)
- 116
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Aucun guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de apache/datafusion-sqlparser-rs
-
Redshift
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
apache/datafusion-sqlparser-rs#2959 ·
Les mainteneurs répondent en général sous 1 jour
-
Redshift
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
apache/datafusion-sqlparser-rs#2958 ·
Les mainteneurs répondent en général sous 1 jour
-
PostgreSQL
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
apache/datafusion-sqlparser-rs#2862 ·
Les mainteneurs répondent en général sous 1 jour
-
PostgreSQL
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
apache/datafusion-sqlparser-rs#2861 ·
Les mainteneurs répondent en général sous 1 jour
-
PostgreSQL
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
apache/datafusion-sqlparser-rs#2858 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de apache/datafusion-sqlparser-rs
Issues similaires
-
area:schema documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
ElectronicWave/Elemental#252 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
dekobon/big-code-analysis#1887 ·
Les mainteneurs répondent en général sous 1 jour
-
Shell中文符号输入异常Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour