Predicting Program Termination: A

Comprehensive Guide
This guide explores program termination from theory to practice, combining formal concepts with machine
learning techniques. We begin with fundamentals (the halting problem and decidability), then describe how
to generate synthetic programs and label them by termination (with censoring). We discuss how to
extract features (static code patterns and dynamic execution signals) that hint at termination. We then
cover statistical models (logistic regression, ROC/AUC, calibration and Brier score, survival analysis with
Kaplan–Meier curves, Cox regression). We describe a hybrid approach combining linear ranking-function
checkers (for simple loops) with ML signals. The implementation section sketches code for generating
programs, training models, and evaluating them; we explain data formats (e.g. CSV) and visualization (plots
of curves, feature importances). We discuss evaluation metrics (accuracy, AUC, Brier, concordance, etc.)
and interpretation methods (feature importance, SHAP values), and analyze errors (false pos/neg). We
frame risks and limitations of statistical termination prediction (no formal guarantees, calibration and
uncertainty), and potential use cases (embedded/mobile systems, energy-aware apps). We suggest
extensions (recursive programs, SMT integration, online learning) and provide a literature survey pointing
to key works on termination analysis, ranking functions, and ML in program analysis.

Each section uses clear language, formulas, and examples. Figures illustrate key ideas (for example, the
logistic sigmoid function and a Kaplan–Meier survival curve). Citations are provided for important concepts
and results.

1. Theoretical Background

1.1 The Halting Problem

In computability theory, the halting problem asks: given a description of an arbitrary program (say in a
Turing-complete language) and an input, can we decide whether the program will eventually halt or run
forever? Turing (1936) famously proved that no algorithm can solve the halting problem in general 1
2 . In other words, termination of arbitrary programs (even without resource limits) is undecidable: some

programs have behavior that no fixed algorithm can predict in all cases.

Example: Consider the simple pseudocode while(true) do nothing; . This loop clearly
never halts. In contrast print("Hello") halts immediately after printing. These trivial
cases are easy. But Turing’s proof shows there is no general procedure that always decides
correctly for every possible program and input 3 .

For a formal statement, one models programs as Turing machines: the question is whether the machine
eventually enters a halting state. Turing’s diagonalization argument constructs a “pathological” program
that will defeat any proposed decision algorithm 1 . Thus, the halting problem is undecidable, meaning
that termination is not a decidable property for general programs.

1
However, certain restrictions make termination decidable: for example, any program with finite state space
must eventually repeat a state or halt 4 . In practice, if a program has bounded memory (like a finite-state
machine or linear bounded automaton), one can algorithmically decide halting by exploring all possible
configurations 4 . But typical programming languages are Turing-complete with unbounded loops and
integer arithmetic, so the general problem remains unsolvable.

1.2 Decidability and Ranking Functions

Since general termination is undecidable, we look for useful sufficient conditions or semi-decision
methods. One classical approach is via ranking functions: if we can exhibit a function that maps program
states to a well-founded set (e.g. natural numbers) that strictly decreases on every loop iteration, then the
loop must terminate. Ranking function synthesis is central in termination analysis: it means assigning a
numeric measure that always goes down until a base case is reached.

• Theorem (informal): Every terminating loop has a ranking function 5 6 . In other words, if a loop
does terminate, then there is some function on its state that decreases to a lower bound each time.
For example, in a loop while(x>0) x := x-1; , the variable x itself is a linear ranking function.

However, finding a ranking function can be hard. Podelski & Rybalchenko (2004) gave a complete method
for synthesizing linear ranking functions for certain loops 7 . In general, one may need complex functions
or loop invariants. As a result, termination is not even semi-decidable in general: there is no algorithm that
lists all terminating programs 5 . Termination proofs often combine invariant generation with ranking
functions (sometimes via LP or SMT solvers).

Example (Ranking Function): Consider the loop:

while (2*x + 3*y > 0) {

x := x - 2;
y := y + 1;
}

One can try a linear ranking function like f(x,y) = 2*x + 3*y . Here each iteration changes (x,y)
such that f decreases by a fixed amount, ultimately reaching non-positive. If we can show f remains
non-negative and strictly decreases, then the loop terminates. Finding such f via linear programming is a
standard technique.

Ranking-function methods work well for affine loops (linear guards and updates). When loops are more
complex (nonlinear, or require lexicographic ranking), automated synthesis can fail. Recent work uses
machine learning to estimate termination: for example, Giacobbe et al. 6 train neural networks to
represent a ranking function, then formally verify it via SMT. More generally, any nontrivial program
property (by Rice’s Theorem) tends to be undecidable, so we resort to heuristics, approximations, and
probabilistic methods.

2
1.3 Resource-Bounded Termination

In practice, we often care about termination within some resource bound. For example, in real-time or
embedded systems, we may require that a task completes within a deadline. If we impose a time bound (e.g.
“does the program halt within 10⁶ steps?”), then we can decide that by simulation up to the
limit. Similarly, if we know a program has fixed memory or loop bounds, the state space is finite, making
termination decidable 4 .

However, limiting resources changes the problem: the “bounded halting problem” is decidable (just run for
that many steps), but if the program runs beyond the bound, it’s only censored information (we don’t know
what happens after). Thus, in empirical analysis we often label programs as terminating if they halt within
the given budget, and as censored/non-terminated if they hit the timeout without halting. This leads
naturally to survival analysis framing (see Section 4.3).

2. Data Generation Methodology

To build a machine-learning model of termination, we need a labeled dataset of programs. Since real-world
codebases with annotated termination status are rare, we create synthetic programs via random
generation. The goal is to cover a variety of loop constructs, arithmetic patterns, and control flows, so the
model can learn signals of (non-)termination.

• Grammar-based generation: One can define a small programming language grammar (e.g.
assignments, conditionals, loops) and randomly sample programs within it. For example, choose a
set of variables x,y,z , operations (+,−,*,/), and loop patterns ( while , for ). Control the
maximum size of programs (e.g. ≤50 lines).
• Guard and update rules: Focus on loop structures: e.g. while-loops with linear guards like
while(a*x + b*y + c > 0) and linear updates such as x := x + k . In generation we
enforce some simple patterns (e.g. one linear guard, one linear update) but varied coefficients. We
may require loops to have an evident loop counter or ensure some assignments to avoid trivially
non-terminating code.
• Constraints to ensure halting: In many generators we ensure the loop “would” terminate if
conditions allow. For example, restrict updates so that one variable strictly increases/decreases
towards making the guard false. In the L0-Bench generation example, loops are set to terminate
when a counter reaches ≤100 8 , and nested loops are initially disabled (max depth=1) 9 . These
heuristics make a challenging but mostly decidable dataset.

Figure: Example configuration from a synthetic program generator (L0-Bench) used for step-by-step execution
evaluation. It limits integer inputs and loop bounds to ensure most loops terminate within finite steps 10 .

Once programs are generated, we execute them under a timeout. For each program, we run it (for
example, in an interpreter or compiled environment) until it either halts or a fixed step/time limit is reached.
If it halts normally, we label it “terminating”; if it exceeds the limit without halting, we label it “censored” (i.e.
presumed non-terminating within our budget). Formally, this mimics a right-censoring scenario in survival

3
analysis 11 : we only know that the program “survived” (kept running) up to the timeout, without observing
termination.

• Labeling: The labels can be binary (terminated vs not within time) for classification, or we can record
the exact run time for those that do halt (time-to-event) and treat others as right-censored
observations 11 . This allows survival analysis methods to later estimate hazard rates.

• Example: Suppose we set a timeout of 1000 steps. Program A halts at step 500 → label as
terminating, survival time=500. Program B is still running at 1000 steps → label as censored at
time=1000. In survival notation, A has event indicator d=1 , B has d=0 .

Note: Because non-termination can occur after arbitrarily long runs, our dataset only approximates the
true halting problem. Programs labeled as non-terminating might in fact halt later; we treat them as
censored data points. This bias is inherent but manageable if the timeout is large relative to typical
runtimes.

3. Feature Engineering
We now convert each program into a set of numeric or categorical features that capture patterns correlated
with termination. Good features combine static code analysis and dynamic execution information.

• Static features: extract characteristics from the source code without running it. Examples include:
number of loops, nesting depth, number of variables, types of operations (add/subtract vs multiply/
divide), the coefficients in linear guards, presence of conditional branches, etc. For instance, the
count of loop guards with only non-negative updates might hint at infinite loops. Another static
feature could be a flag “linear ranking function exists?” if a fast checker can decide for simple loops.

• Dynamic features: capture behaviors observed during execution (for those that do run). This can
include: runtime until halt (for terminating ones), change in key variables per step, or statistics from
partial execution (e.g. the maximum variable value reached in first 100 steps). Dynamic features for
censored cases might be truncated or defaulted. For example, if we see that in the first 100 steps a
loop variable didn’t decrease, that is a red flag. In survival analysis, one might include time-dependent
covariates capturing behavior as time evolves.

• Heuristic indicators: some simple patterns are powerful. Examples:

• Monotonic counters: If a loop guard tests x > K and the update is x := x + c with c>0 ,
then x only increases, so if initially x <= K it halts, but if x > K it loops forever. A static rule can
detect such mismatches.
• Infinite resets: Loops that reset variables without approaching the guard (e.g. while(x>0)
{x:=x+1; if(x>100) x:=0;} ) likely do not terminate.
• Modular arithmetic: Guards like while (i % 2 == 0) ... i := i - 1; might terminate by
flipping parity.
• Polynomial growth: If updates increase variables faster than guards can limit, termination is
unlikely.

4
In practice, we include many simple features (e.g. numeric values of guard coefficients) and let the model
learn which combinations signal termination. We can also run lightweight static checks: for affine loops
(linear guard, constant updates), we might run a linear-programming ranking-function test. The result of
that test (a binary or confidence score) is then fed as a feature.

Example (Features): Consider a loop while (3*x - 2*y > 5) { x := x - 1; y := y + 2; } .

Possible features: guard-coeff-X=3, guard-coeff-Y=-2, guard-constant=5, num-updates=2, update-X change per
iter = -1, update-Y change per iter = +2, potential linear ranking (true if 3, -2 satisfy certain constraints), branch
count=0, depth=1, vars=2. We also could simulate a few steps: if (x,y)=(2,0) is initial, after one step we get
(1,2), two steps (0,4), etc. Those dynamics can be additional features or used in time-series form for survival
modeling.

4. Statistical Models
Given features and labels, we now apply statistical learning. We treat termination as a binary outcome
(terminates vs censored/doesn’t terminate in time). Two complementary viewpoints are useful:

• Binary classification (logistic regression): Predict the probability that a program terminates.
• Survival analysis: Model the “time to termination” using censored-data techniques (Kaplan–Meier
curves, Cox regression).

4.1 Logistic Regression for Termination Classification

A simple approach is logistic regression, a probabilistic linear classifier. Let $x$ be the feature vector of a
program. The model computes a score $z = w^T x + b$, then outputs a probability via the sigmoid (logistic)
function:

1
P (terminate ∣ x) = σ(wT x + b) = .
1+ e−(wT x+b)

12 13

Here $\sigma(z)$ is the S-shaped logistic function. The model is trained on labeled examples (feature
vectors $x_i$, labels $y_i=1$ if terminating, $0$ if censored). The training maximizes a likelihood or
minimizes log-loss. Logistic regression is interpretable: each feature’s weight $w_j$ indicates how strongly it
contributes to predicting termination.

Figure: The logistic (sigmoid) function $\sigma(z)=1/(1+e^{-z})$ used in logistic regression 12 13 . It maps the
linear score $z=w^T x$ to a probability between 0 and 1. Here the curve crosses 0.5 at $z=0$.

A threshold (e.g. 0.5) on the predicted probability yields a binary decision. More generally, one may adjust
the threshold to balance false positives/negatives. Logistic regression provides output probabilities, so we
can assess calibration (do predicted probabilities match actual frequencies?) and discrimination (can we
separate terminators from non-terminators well?).

5
4.2 ROC, Calibration, and Brier Score

We evaluate classification performance using several metrics:

• Accuracy/Confusion matrix: the fraction of programs correctly classified. But with imbalanced data
or different costs, we also look at precision, recall, F1, etc.
• ROC curve and AUC: Plot true positive rate vs false positive rate as the decision threshold varies 14 .
The Area Under the ROC Curve (AUC) measures how well the model ranks positive examples above
negatives, independent of threshold 14 . A perfect classifier has AUC=1.0, random guessing yields
~0.5. ROC analysis helps select operating points and compare models. For termination, a good AUC
(close to 1) means the model reliably distinguishes likely-terminating programs from likely-non-
terminating ones.
• Calibration and Brier score: Since logistic regression outputs probabilities, we check if these
probabilities are calibrated. The Brier score is the mean squared error between predicted
probabilities and actual outcomes 15 . Lower Brier means better calibration. For example, if we
predict 0.8 chance of termination for 100 programs, and indeed about 80 of them terminate,
calibration is good. Brier score is a proper scoring rule 16 : it combines both calibration and accuracy
aspects. A perfectly calibrated, perfectly discriminating classifier would achieve Brier=0.

Calibration can be visualized via a reliability diagram (plot predicted vs observed probability). If our model is
overconfident, calibration plots deviate from the diagonal. We may apply Platt scaling or isotonic regression
to recalibrate the logistic outputs 17 . In safety-critical uses, calibration is important: we want probability
estimates that truly reflect uncertainty.

4.3 Survival Analysis (Kaplan–Meier Curves)

Instead of ignoring run time, we can use survival analysis to model time-to-termination. Each program
yields a “survival time” $T$: the number of steps until termination or until censoring. We have event
indicator $d=1$ if it terminated (event observed) and $d=0$ if censored by timeout. We can then estimate
the survival function $S(t) = P(T > t)$.

The Kaplan–Meier estimator is a non-parametric way to estimate $S(t)$ accounting for censoring 18 . It
produces a stepwise curve that shows the fraction of programs surviving (still running) past each time. For
example, at time $t=0$ everyone “survives” (no one has terminated yet), so $S(0)=1$. As $t$ increases, $S(t)$
decreases at each observed termination event, adjusted for the number at risk.

Figure: Kaplan–Meier survival curve (red) with 95% confidence bands (grey) for a sample of programs 19 18 . The
vertical axis $S(t)$ is the probability a program runs longer than time $t$. Marks indicate censored observations.
K-M curves handle censoring naturally: each drop occurs only when an actual termination happens, and censored
runs do not count as events 18 .

We can also stratify by groups (e.g. programs with a certain feature vs without) and compare their survival
curves. A log-rank test can check if the difference is significant. In the context of termination, a survival
curve tells us what fraction of programs terminate by time $t$. A steep drop early means many programs
terminate quickly; a long right tail means some programs (or loops) take very long or never terminate
within the bound.

6
4.4 Cox Proportional Hazards Model

To relate features to survival time, we use the Cox proportional hazards model 20 21 . This is a semi-
parametric regression:

h(t ∣ x) = h0 (t) exp(β T x),

where $h(t\mid x)$ is the hazard rate (instantaneous termination rate at time $t$ given survival up to $t$),
$h_0(t)$ is an unspecified baseline hazard, and $\beta$ are coefficients for features $x$. In practice, one fits
$\beta$ so that $\exp(\beta_j)$ are hazard ratios (HR) for each feature. An HR > 1 means the feature
increases the hazard (makes termination more likely sooner), while HR < 1 means it decreases hazard (slows
termination) 22 .

For example, if feature $x_1$ is “loop has a decreasing counter”, we expect $\beta_1>0$ (HR>1), indicating
faster halting. Conversely, a feature “loop counter increases” might have HR<1. The Cox model provides
confidence intervals for each HR, letting us gauge statistical significance 23 . If the 95% CI of $
\exp(\beta_j)$ includes 1, the effect may be negligible.

Because Cox regression uses partial likelihood, it naturally handles censoring. We can include both static
and dynamic features. The model can predict the hazard function or median survival time for a new
program. However, Cox assumes proportional hazards over time, which should be checked.

A useful interpretation: a hazard ratio $\exp(\beta)$ for feature $x_j$ means “holding other factors constant,
a unit increase in $x_j$ multiplies the risk of termination by $\exp(\beta)$”. For example, $\exp(\beta)=2$
means the loop is twice as likely to terminate at any given time if that feature is present. We must provide
confidence intervals for these HRs to understand uncertainty 23 .

Equation (Cox model): We fit $\beta$ by maximizing the Cox partial likelihood. The model’s hazard is $$ h(t)
= h_0(t)\exp(\beta_1 x_1 + \cdots + \beta_p x_p)\quad{\rm with}\quad \exp(\beta_j)\ {\rm = hazard\ ratio}\,. $
$ 21 22 .

By combining logistic regression (probability of eventual termination) with survival methods (timing of
termination), we gain a richer understanding. The logistic model is simple and interpretable; the survival
model directly uses timing information and handles censoring gracefully.

5. Hybrid Approach: Ranking Functions + ML

A hybrid model leverages both formal methods and statistical learning. The idea is to use an automated
ranking-function checker for the easy cases (affine loops) and use its result as an additional feature for the
ML model.

• Linear ranking-function checker: For programs that consist solely of an affine loop (one linear
guard, linear updates), we can apply an LP-based solver (e.g. Podelski-Rybalchenko algorithm) to
decide if a linear ranking function exists 7 . This can often prove termination or non-termination for
simple loops. We run this checker on each loop in the program. If it finds a valid ranking, we mark
“proved terminating by linear RF = yes” (binary feature). If it fails or times out, mark “no/unknown”.

7
 • LP-based signal: Even if the checker fails to prove, it may return partial information (e.g. “no linear
RF of degree 1 exists”). We can encode this as a feature (“no linear RF found” = 1). Alternatively, one
could use the objective gap of the LP as a feature. In practice, a boolean flag from the solver (exists/
does-not-exist) is simplest.

• Integrating with logistic/Cox: The ML model then has features like hasLinearRF . This strongly
biases the model: if a linear ranking function was found, likely the program terminates, so the model
learns to assign high $P(\text{terminate})$ in those cases. If not found, the model relies on other
heuristics. This combination often improves accuracy over pure ML or pure symbolic methods alone.

• Example: Consider two loops with similar guards and updates. The checker proves the first
terminates by finding $f(x,y)=x+2y$ decreases. We set feature LinearRF=1 . The second loop,
maybe slightly more complex, fails the LP check; LinearRF=0 . The logistic model will learn from
data that LinearRF=1 is a strong positive sign, effectively mixing formal and statistical evidence.

This hybrid design is motivated by systems like Syndicate 24 25 , which coordinate ranking-function
synthesis with invariant inference. Here we simply treat it as feature engineering. Empirically, one can show
(ablation studies) that including the LP-check feature boosts predictive performance, especially on affine
loops.

6. Implementation

6.1 Program Generator

We implement the synthetic program generator in a language like Python, using random choice of
grammar rules. A simplified pseudocode:

def generate_program(max_lines=50, max_loops=3):

prog = []
for i in range(random_int(10, max_lines)):
if random_chance(loop_prob):
# create a while loop
x, y = random_vars(), random_vars()
a, b, c = random_coeff(), random_coeff(), random_const()
guard = f"{a}*{x} + {b}*{y} > {c}"
dx, dy = random_update(), random_update()
body = []
body.append(f"{x} := {x} + {dx}")
body.append(f"{y} := {y} + {dy}")
prog.append(f"while ({guard}) {{")
prog.extend(indent(body))
prog.append("}")
else:
# simple assignment or if

8
 prog.append(random_assignment())
return "\n".join(prog)

Key points: - We cap coefficients and constants to small ranges (e.g. [-10,10]) to keep numbers manageable.
- We ensure loops have at least one variable that changes so they are not trivially infinite (e.g. avoid
while(x>0) {} with no updates).
- We can post-process to ensure no nested loops (e.g. max_loops=1 ) for simplicity.

6.2 Model Training and Evaluation

After generating a dataset of programs and labeling them by execution, we extract features as described in
Section 3. In Python (e.g. with Pandas), we store features in a matrix $X$ and labels in arrays $y$
(terminates or not) and $T,d$ (survival times and event indicators).

For logistic regression, we might use scikit-learn:

from sklearn.linear_model import LogisticRegression

model = LogisticRegression()
model.fit(X_train, y_train)
pred_prob = model.predict_proba(X_test)[:,1] # probability of termination
pred_labels = (pred_prob > 0.5).astype(int)

For survival/Cox, we can use the lifelines or scikit-survival library. For example, lifelines :

from lifelines import CoxPHFitter

data = pandas.DataFrame(X_train, columns=feature_names)
data['T'] = T_train
data['E'] = event_train
cph = CoxPHFitter()
cph.fit(data, duration_col='T', event_col='E')
cph.print_summary() # show hazard ratios and CIs

Evaluation code would compute metrics (accuracy, ROC AUC, Brier, calibration curve) and survival estimates
(KM plot, concordance-index). One would also check calibration of logistic probabilities (with
calibration_curve from scikit-learn, for example 26 ).

6.3 Data Structure and CSV Layout

A convenient format is CSV, where each row is a program instance. Columns may include:

• program_id (identifier)
• Static features: e.g. num_loops , num_branches , coeff_x_in_guard , coeff_y_in_guard ,
update_x , update_y , linearRF_exists (0/1), etc.
• Dynamic features: e.g. init_value_x , init_value_y , max_steps_observed , etc.

9
 • Label: terminated (0 or 1) and possibly run_time (censored at timeout if not terminated).
• Cox data: For survival, T = time (if terminated) or censoring time, E = event (1 if terminated, 0 if
censored).
• Logistic label: terminates (1 or 0).

For example, a CSV row might look like:

id,num_loops,coeff_x,coeff_y,update_x,update_y,linearRF,terminated,T
1,1,3,-2,-1,2,1,1,500
2,1,1,0,1,0,0,0,1000

Here program 1 has one loop 3*x - 2*y > 0 with updates x:=x-1, y:=y+2 , and linearRF=1
(solver found ranking). It terminated (terminated=1) after T=500 steps. Program 2 did not terminate within
1000 steps (terminated=0, censored at T=1000).

6.4 Figures and Visualizations

In analyzing results, we produce figures like:

• ROC Curve: Plot of TPR vs FPR for the logistic model.

• Calibration Plot: Predicted probability vs observed frequency (reliability diagram).
• Kaplan–Meier curve: plot(survival_func_) showing $S(t)$ vs $t$ for the cohort. We may
overlay curves for subgroups (e.g. linearRF=1 vs 0 ).
• Cox coefficients: Bar chart of hazard ratios with confidence bars.
• Feature importances: If using a tree-based classifier as an alternative, show importances; for
logistic, show magnitude of weights or SHAP values.
• Sample programs: Possibly list a few program code snippets (as text) with their features and true
label to illustrate.

Because this is a text guide, we will not embed actual plots here (but in practice one would generate these
with matplotlib, etc.). Instead, we rely on the above two embedded figures to illustrate a logistic function
and a Kaplan–Meier curve.

7. Evaluation and Interpretability

7.1 Statistical Evaluation Metrics

We measure predictive performance thoroughly:

• Classification metrics: Accuracy, precision, recall, F1-score. If classes are imbalanced (e.g. more
terminating than non-terminating programs), consider balanced accuracy or ROC AUC.
• ROC AUC: As mentioned, gives overall discrimination ability 14 .
• Calibration metrics: Brier score (mean squared error of probabilities) 15 and calibration plots. A
model may have high AUC but poor calibration; we aim for both.

10
 • Survival metrics: Concordance index (C-index) measures how well the Cox model’s risk scores
concord with actual survival times. A C-index of 1.0 is perfect, 0.5 is random. We also compare
Kaplan–Meier curves between predicted-high-risk and predicted-low-risk groups.

7.2 Feature Importance and SHAP

To interpret the model, we assess feature importance. For logistic regression, we can examine the learned
weights $w_j$: larger magnitude means more influence. Alternatively, use model-agnostic methods:

• Permutation importance: Randomly shuffle each feature across the dataset and see how much the
model’s performance degrades 27 .
• SHAP values: SHapley Additive exPlanations assign to each feature the contribution to a specific
prediction. A SHAP summary plot shows which features tend to increase vs decrease the predicted
probability of termination 28 . For example, a positive SHAP for “linearRF_exists” would confirm that
when a linear ranking function exists, it strongly drives the model towards “terminating”.

These analyses help us understand which program patterns are most predictive. For instance, we might
find features like “loop decrement coefficient” or “guard constant small” have high importance.

7.3 Error Analysis

Finally, examine false positives/negatives. A false positive here means the model predicted “terminates”
but the program did not terminate within timeout. A false negative means it predicted “does not terminate”
but it actually did halt. Analyze examples of each:

• False positives: These are risky: the model gave unwarranted confidence. We check if these
programs were long-running but eventually halted after the timeout, or if some dynamic feature
misled the model.
• False negatives: The model was overly pessimistic, possibly due to atypical features (maybe an
unusual loop pattern not seen in training). In critical applications, false negatives mean wasted
resources if we erroneously handle safe code as unsafe.

Discussing errors highlights the limits of the approach and guides improvement (e.g. adding more diverse
training examples).

8. Risk, Feasibility, and Ethical Considerations

Statistical termination prediction has inherent limitations. Most critically, no model can guarantee
termination; it only gives probabilistic estimates. One must be cautious:

• No formal guarantee: Unlike theorem-proving, a machine learning predictor can never be fully
relied upon. There may always be a pathologically coded program that misleads the model. Users
must treat predictions as suggestions, not proofs.
• Calibration and uncertainty: Probabilities should be well-calibrated. In high-risk contexts (e.g.
safety-critical systems), even a 90% predicted chance of halting means 1 in 10 programs could still
loop. Overconfidence can be dangerous. We emphasize uncertainty, e.g. providing confidence
intervals or treating near-0.5 predictions with skepticism. Using Brier score and calibration curves
15 26 can help ensure we know how reliable our probabilities are.

11
Use Cases: These methods are most appropriate as assistive tools rather than decision-makers. For
example:

• Embedded/mobile systems: Here, programmers write loops with energy/time budgets. A

termination classifier could flag probable infinite loops (so they can be fixed) or help schedule tasks.
But one should not fully trust it in isolation.
• Energy-aware scheduling: In battery-powered devices, tasks predicted to run too long might be
deferred. A well-calibrated model helps manage energy use, but mispredictions risk either wasted
power or unnecessary delays.
• Testing and debugging: The model could automatically classify large codebases to find suspicious
loops, aiding developers. Erroneous classifications lead to false alarms, which is less critical than
missing a true infinite loop.

Ethical framing: The main ethical principle is responsibility. Developers using such tools must understand
that statistical models can err. Claims like “this code is safe because our classifier says so” are misleading.
We should always cross-check ML predictions with human judgment or formal tools when possible.
Transparency (e.g. highlighting why a model flagged a loop as non-terminating via interpretability
techniques) builds trust. Fairness/bias is less relevant here, since the “individuals” are code samples, not
people. Privacy also does not apply directly.

However, there is an ethical consideration in engineering practice: relying on ML models in safety-critical

code (like medical devices, autonomous vehicles) could be risky without safeguards. It is the engineer’s duty
to quantify risk (e.g. via confidence bounds) and to fail-safe (e.g. never interrupt a critical loop solely on a
ML verdict).

In summary, probabilistic termination prediction is best seen as augmenting human analysis, not
replacing it. We should clearly communicate uncertainty and limitations to users.

9. Suggested Extensions
We conclude with some ideas for future work:

• Recursive programs: Extend the approach to handle recursion. Features might include depth of
recursion, presence of base cases, and dynamic call-stack growth. Termination of recursive functions
could be learned similarly, though formal methods (e.g. well-founded orders on arguments) are
trickier.
• Integration with SMT solvers: Use Satisfiability Modulo Theories to pre-check complex conditions.
For instance, feed program constraints into an SMT solver to see if there is a model where the loop
guard always holds. This could produce features (e.g.
SMT_check: always_true/false/unknown ) that help the ML model.
• Online learning from execution traces: In a deployed system, we could gather real execution data
of new programs. Online learning could update the model: if a program ran much longer (or
finished) differently than predicted, we adjust weights. This continual learning would help adapt the
model to new programming patterns.

These extensions would further bridge formal methods and data-driven learning, potentially improving
accuracy and scope.

12
10. Literature Survey
The problem of program termination has a long history:

• Classical results: Turing’s 1936 paper established undecidability of halting 1 . Theoretical

foundations are covered in textbooks (e.g. Rogers 1967) and by Church 1936 for lambda calculus.
• Ranking function synthesis: Podelski & Rybalchenko (VMCAI 2004) gave a complete linear ranking
method 7 . Cook, Podelski, and Rybalchenko (PLDI 2006) applied termination proofs to systems
code. Bradley, Manna, and Sipma (2005) introduced the notion of transition invariants for
termination. Recent work (Giesl et al. 2017; Unno et al. 2021) continues to improve automated
termination tools.
• Hybrid approaches: Synergistic frameworks like Syndicate (Sarita et al. 2025) combine ranking
inference with guidance 24 25 .
• Machine learning and termination: Giacobbe et al. (FSE 2022) propose neural ranking functions:
train a network to decrease along traces, then verify it formally 6 . Alon & David (ESEC/FSE 2022)
use Graph Neural Networks on source-code graphs to predict termination as a classification
problem 29 . Others have applied SVMs or decision trees to loop termination examples. These ML
approaches emphasize empirical estimation over proofs.
• Statistical modeling: Survival analysis for software (e.g. “time-to-failure”) is well studied in empirical
software engineering. Techniques like Kaplan–Meier and Cox models are standard for time-to-event
data 20 18 . In our context, they are novel applications to program termination. The use of metrics
like ROC and Brier comes from predictive modeling best practices 15 14 . Calibration methods (Platt
scaling, isotonic) are standard for probabilistic classifiers 26 .
• Explainable AI: For interpretability, we draw on Shapley-based feature attribution (e.g. Lundberg &
Lee’s SHAP) to explain model decisions in a fair way. Feature importance via permutation is
described in standard ML resources 27 .

Key references: Church 1936; Turing 1937; Podelski & Rybalchenko 2004; Bradley et al. 2005; Cook et al.
2006; Giacobbe et al. 2022 6 ; Alon & David 2022 29 ; lifelines documentation; scikit-learn docs on ROC/
Brier; Wikipedia on ROC 14 , Brier 15 , Kaplan–Meier 20 , Cox model 21 22 .

By combining these sources with our methodology, we provide a clear, thorough guide for students and
practitioners interested in the intersection of program analysis and statistical learning.

1 3 4 Halting problem - Wikipedia

https://en.wikipedia.org/wiki/Halting_problem

2 29 Using Graph Neural Networks for Program Termination

https://arxiv.org/pdf/2207.14648

5 theory.stanford.edu
http://theory.stanford.edu/~arbrad/slides/termination.pdf

6 [2102.03824] Neural Termination Analysis

https://arxiv.org/abs/2102.03824

7 24 25 Efficient Ranking Function-Based Termination Analysis with Bi-Directional Feedback

https://arxiv.org/html/2404.05951v3

13
 8 9 10 arxiv.org
https://arxiv.org/pdf/2503.22832

11 The Basics of Survival Analysis

https://tinyheero.github.io/2016/05/12/survival-analysis.html

12 Sigmoid function - Wikipedia

https://en.wikipedia.org/wiki/Sigmoid_function

13 web.stanford.edu
https://web.stanford.edu/~jurafsky/slp3/5.pdf

14 Receiver operating characteristic - Wikipedia

https://en.wikipedia.org/wiki/Receiver_operating_characteristic

15 16 Brier score - Wikipedia

https://en.wikipedia.org/wiki/Brier_score

17 26 Brier Score: Understanding Model Calibration

https://neptune.ai/blog/brier-score-and-model-calibration

18 20 An Introduction to Survival Statistics: Kaplan-Meier Analysis - PMC

https://pmc.ncbi.nlm.nih.gov/articles/PMC5045282/

19 File:Kaplan-Meier-sample-plot.svg - Wikimedia Commons

https://commons.wikimedia.org/wiki/File:Kaplan-Meier-sample-plot.svg

21 22 23 Cox Proportional-Hazards Model - Easy Guides - Wiki - STHDA

https://www.sthda.com/english/wiki/cox-proportional-hazards-model

27 23 Permutation Feature Importance – Interpretable Machine Learning

https://christophm.github.io/interpretable-ml-book/feature-importance.html

28 SHAP Values vs Feature Importance | by Amit Yadav - Medium

https://medium.com/biased-algorithms/shap-values-vs-feature-importance-ba6b91c16319

14