PaperlayerView exact revision on arXiv

Source-linked AI summary

DeepLocalize: Fault Localization for Deep Neural Networks

Mohammad Wardat, Wei Le, Hridesh Rajan

arXiv:2103.03376v1cs.SE

TL;DR

Existing debugging techniques struggle to localize DNN bugs, in part because incorrect classifications do not necessarily indicate a bug. DeepLocalize collects and analyzes training-time traces to detect and localize faults. On 40 buggy models, it detected 34 faults versus Keras’s best 32 and localized 21 bugs where Keras localized none.

  • Problem

    Existing debugging techniques do not identify DNN bugs and faulty statements at a particular layer, while an incorrect classification during training does not necessarily mean the model is buggy.

    Source: §I · pp. 1–2

  • Method

    DeepLocalize collects training-time traces through imperative translation or callbacks and analyzes them to detect numerical errors and identify faulty layers or parameters.

    Source: §I · p. 2

  • Results

    34/40 faults were detected by DeepLocalize versus 32/40 by Keras’s best debugging approach; DeepLocalize localized 21/40 bugs while Keras localized none.

    Source: §I · p. 2

  • Takeaways & Limitations

    The authors offer a benchmark of 40 buggy models and patches as a resource for evaluating automated debugging and repair tools.

    Source: §I · p. 2

    The tool failed on cases involving wrong labels, training-data or setting problems, and does not support all Keras APIs.

    Source: 3) RQ3 (Limitation) · p. 9

Abstract

from arXiv · show

Deep neural networks (DNNs) are becoming an integral part of most software systems. Previous work has shown that DNNs have bugs. Unfortunately, existing debugging techniques do not support localizing DNN bugs because of the lack of understanding of model behaviors. The entire DNN model appears as a black box. To address these problems, we propose an approach that automatically determines whether the model is buggy or not, and identifies the root causes. Our key insight is that historic trends in values propagated between layers can be analyzed to identify faults, and localize faults. To that end, we first enable dynamic analysis of deep learning applications: by converting it into an imperative representation and alternatively using a callback mechanism. Both mechanisms allows us to insert probes that enable dynamic analysis over the traces produced by the DNN while it is being trained on the training data. We then conduct dynamic analysis over the traces to identify the faulty layer that causes the error. We propose an algorithm for identifying root causes by capturing any numerical error and monitoring the model during training and finding the relevance of every layer on the DNN outcome. We have collected a benchmark containing 40 buggy models and patches that contain real errors in deep learning applications from Stack Overflow and GitHub. Our benchmark can be used to evaluate automated debugging tools and repair techniques. We have evaluated our approach using this DNN bug-and-patch benchmark, and the results showed that our approach is much more effective than the existing debugging approach used in the state of the practice Keras library. For 34 out of 40 cases, our approach was able to detect faults whereas the best debugging approach provided by Keras detected 32 out of 40 faults. Our approach was able to localize 21 out of 40 bugs whereas Keras did not localize any faults.

I. INTRODUCTION

DNNs are difficult to debug because existing techniques do not identify faulty model statements or layers, and a wrong prediction does not necessarily mean the model is buggy. DeepLocalize uses dynamic traces to detect and localize faults, and the authors evaluate it on a benchmark of 40 buggy models.

I. INTRODUCTION

  • Existing debugging techniques cannot identify DNN bugs and faulty statements at a particular layer; incorrect classifications during training do not necessarily mean a model contains a bug.DNNs learn from training data and use weights and activation functions rather than the control-flow logic of regular programs.Source: §I · pp. 1–2
  • DeepLocalize offers a white-box approach that collects training-time traces through either imperative translation or callbacks, then analyzes numerical errors and layer or parameter relevance to locate faults.The approach requires the DNN source code and training data.Source: §I · p. 2
  • 34/40 faults were detected by DeepLocalize versus 32/40 by Keras’s best debugging approach; DeepLocalize localized 21/40 bugs while Keras localized none.The benchmark contains real errors from deep learning applications and is intended to support evaluation of debugging and repair tools.Source: §I · p. 2
  • The authors assembled a benchmark of 40 buggy models and patches from Stack Overflow and GitHub for evaluating debugging and repair tools.The benchmark is offered as ground truth for their evaluation and as a resource for other researchers.Source: §I · p. 2

II. A MOTIVATING EXAMPLE

A Stack Overflow example illustrates how a DNN can fail to learn because of a loss-function choice and missing activation functions. DeepLocalize reports a layer and training stage to help identify the source, whereas Keras callbacks provide stopping information without that localization.

II. A MOTIVATING EXAMPLE

  • The example DNN’s classification task used mean_squared_error instead of categorical_crossentropy and omitted activation functions in its first two layers.These were the two problems identified in the model that did not learn during training.Source: §II · p. 2
  • Keras’s TerminateOnNaN and EarlyStopping callbacks stopped training but did not identify which layer or hyperparameter prevented learning.The example’s callbacks stopped after 1.20, 12.21, and 34.90 seconds individually, and 1.16 seconds when combined.Source: §II · pp. 2–3
  • DeepLocalize reported the bug after 0.14 seconds with its tool and 2.14 seconds with its callback, locating it in layer 2’s back-propagation stage.The report pointed to the layer parameter and helped the developer trace the issue to the loss function.Source: §II · p. 3

A. An Overview

DeepLocalize makes DNN internals observable during training through imperative translation or callbacks, then analyzes collected values from both training phases.

A. An Overview

  • Dynamic traces from imperative translation or a custom callback capture model variables during training for online fault analysis.The imperative representation names layers for localization; the callback invokes analysis after each training batch.Source: A. An Overview · p. 3, B. Model Preparation · p. 3

B. Model Preparation

  • The imperative approach requires manual translation and currently supports Dense, Dropout, Maxpooling, Convolution, BatchNormalization, and Padding layers.Rapid Keras evolution and changing API signatures make compatibility difficult to maintain.Source: B. Model Preparation · pp. 3–4

C. Instrumentation

  • Instrumentation collects feedforward outputs, activations, loss, and accuracy, plus backpropagation weight, bias, and gradient updates during training.The instrumentation runs through the implemented fit() function during training.Source: C. Instrumentation · p. 4

D. Statistical Analysis to Detect Suspect Behavior

DeepLocalize analyzes training-time values and trends to detect suspect behavior, including learning-rate, input-data, and activation or loss problems, and localize faults.

1) Incorrect learning rate:

2) Incorrect input data:

  • For potentially unnormalized or NaN training inputs, the method checks first-layer outputs for NaN or Inf and frequent zero means to locate the affected layer and activation position.The paper gives MNIST pixels in [-1, 1], rather than [0, 255], as a normalization example.Source: 2) Incorrect input data · p. 4

3) Incorrect activation/loss functions:

E. DNN Fault Localization Algorithm

  • The algorithm analyzes training batches to identify bugs, report their layer and propagation phase, and indicate when training stops.Its output includes fault-location and failure information.Source: E. DNN Fault Localization Algorithm · pp. 4–5

D. Statistical Analysis to Detect Suspect Behavior

  • During training, analysis checks values from forward and backward propagation and tracks changes across iterations to flag numerical errors or suspect learning behavior.The ANA procedure returns true for detected numerical errors and otherwise returns false.Source: E. DNN Fault Localization Algorithm · p. 5

1) Feedforward phase:

The algorithm checks forward-pass values and training trends, then analyzes weight updates and weights during backpropagation to identify faults.

1) Feedforward phase:

  • In the feedforward phase, checks detect numerical errors before or after activation and in loss or accuracy, while monitoring loss and accuracy trends for stalled learning.A nondecreasing loss and nonincreasing accuracy over the specified interval trigger a message that the model does not learn.Source: 1) Feedforward phase · p. 5

2) Backpropagation phase:

  • During backpropagation, ANA checks each layer’s weight updates and weights for numerical errors and identifies the layer associated with a detected problem.The algorithm terminates with a correct-model message if no issue is found after training.Source: 2) Backpropagation phase · pp. 5–6
  • ANA also checks means for NaN, Inf, or excessive zeros and uses recent mean-value changes across iterations to assess numerical errors.The procedure stores means by layer and location and examines the last N values.Source: 2) Backpropagation phase · pp. 5–6

IV. EVALUATION

The evaluation is framed around whether the technique finds bugs, how its fault localization compares with Keras, and where it fails.

IV. EVALUATION

  • RQ1 asks whether the technique can find bugs in deep learning programs effectively.The evaluation includes Table III, labeled as a comparison of Keras and imperative results.Source: §IV · p. 6, Table III · p. 6
  • RQ2 asks how effectively and quickly the technique localizes faults compared with Keras library methodology.Table III is labeled as comparing Keras and imperative results, but the supplied caption does not state outcome values.Source: §IV · p. 6, Table III · p. 6
  • RQ3 asks in which cases the technique fails to report bugs or localize faults.The supplied evaluation passages state this as a research question, not as a finding.Source: §IV · p. 6

1) Implementation:

The implementation supports two trace-collection approaches with different layer coverage. The benchmark combines buggy Keras models mined from Stack Overflow and GitHub, and the imperative implementation has comparable accuracy and loss to Keras at higher runtime cost.

1) Implementation:

  • The callback-based tool supports all layers and optimization methods supported by Keras, while the translation-based tool supports a specified subset of common layers.The translation-based subset includes Dense, Dropout, Maxpooling, Convolution, BatchNormalization, and Padding.Source: 1) Implementation · p. 6
  • The analysis settings used threshold = 1/4 * No. Iteration and N = 50, selected based on empirical experience to help detect bugs during training.These settings were applied to both the tool and callback function.Source: 1) Implementation · p. 6

2) Benchmark construction:

  • The benchmark includes 30 Stack Overflow posts selected through filtering and manual review, with a fault location and patch derived for each.Posts had a score of at least 5, included buggy Keras code and training data, and were screened for complete code.Source: 2) Benchmark construction · p. 7
  • The GitHub mining process yielded 11 executable programs with training data, whose fault locations and patches were manually derived.The researchers searched Keras repositories and selected the last fix for commits identified through bug-related keywords.Source: 2) Benchmark construction · p. 7
  • The imperative implementation has accuracy and loss comparable to Keras, but takes around 5 times longer during training and testing because it performs additional bug and root-cause analysis.It can terminate early when it finds a bug.Source: 2) Benchmark construction · p. 7

B. Results and Analysis

The callback detects more benchmark bugs and localizes more root causes than Keras’s built-in methods, though it incurs analysis overhead. The results also identify scope boundaries involving unsupported APIs, performance-only differences, and training or data problems.

B. Results and Analysis

  • 34 out of 40 bugs were identified by the callback, compared with 32 out of 40 by the three Keras methods together; the tool identified 23 out of 29.The authors attribute the callback’s broader detection to analyzing more runtime values than methods using only loss or accuracy.Source: B. Results and Analysis · p. 8
  • The tool did not detect 7 out of 30 models, including a wrong-label case where ReLU in the last layer mapped negative values to zero.The cited input range was [−∞, +∞], while the labels required outputs in the same range.Source: B. Results and Analysis · p. 8
  • The technique did not support fit_generator(), which trains on data generated batch by batch.The authors identified this API as future work.Source: B. Results and Analysis · p. 8
  • Performance differences between two models that both train correctly may not yield a numerical error or misbehavior for the tool to detect.The example involved models with different input dimensions.Source: B. Results and Analysis · p. 8
  • The tool did not target missing datasets, training-data distribution problems, or incorrect training settings such as epochs, batch sizes, and layer or node counts.The authors report that such cases can stop training before the model finishes learning.Source: B. Results and Analysis · p. 8
  • 21 out of 40 root causes were localized by the callback and 19 out of 29 by the tool, while none of the three Keras methods determined root causes.The reported localizations were compared with the benchmark ground truth.Source: B. Results and Analysis · p. 8
  • The callback averaged 421.39 seconds on Stack Overflow benchmarks and 2613.6 seconds on GitHub benchmarks, with analysis overhead from collecting additional values such as weights and gradients.The authors say this overhead can grow with model parameter count; Figure 5 plots average time for the methods.Source: B. Results and Analysis · p. 8, Figure 5 · p. 8
  • Observed bug patterns included choices of activation or loss function, hyperparameters, and training-data preprocessing.The examples include learning-rate and layer-size choices, and normalizing MNIST data to [-1, 1].Source: B. Results and Analysis · p. 9

C. Summary

The callback approach detected more faulty models and localized faults where Keras did not; the imperative implementation was consistent with Keras training and also detected and localized faults.

1) RQ1 (Validation):

  • Training with the imperative program was consistent with Keras; the tool detected 23/29 faulty models and localized 19/29, while the callback detected 34/40 and localized 21/40.Keras did not support fault localization.Source: 1) RQ1 (Validation) · p. 9

2) RQ2 (Comparison):

  • 34/40 faulty models were detected by the callback versus 32/40 by Keras methods combined, and 21/40 faults were localized versus none by Keras.The imperative tool detected 23/29 and localized 19/29; its average detection time was 107.99 seconds, compared with 191.6, 142.67, and 114.54 seconds for the three Keras methods.Source: 2) RQ2 (Comparison) · p. 9

3) RQ3 (Limitation):

The evaluation reports limits from early-stopping training cases and incomplete API support, alongside implementation and benchmark-validity threats; related-work passages distinguish DNN testing and bug studies.

3) RQ3 (Limitation):

  • Training can stop before learning finishes in cases involving wrong labels, dataset problems, or training settings, and the prototype does not support every Keras API.The tool failed to detect bugs in 7/30 programs and to localize faults in 11/30; the callback failed to localize faults in 20/41.Source: 3) RQ3 (Limitation) · p. 9

V. THREATS TO VALIDITY

  • Implementation correctness and the trustworthiness of manually created benchmarks are threats the authors sought to mitigate through code review and prior benchmark methodology.They also evaluated benchmarks before and after fixing model issues.Source: §V · p. 9

VI. RELATED WORK

  • The cited testing work targets adversarial inputs or suspicious neurons, whereas this approach focuses on localizing structural bugs using existing training data.The authors distinguish DeepFault's focus on training bugs and pretrained-model analysis from their structural-bug focus.Source: A. Testing Deep Neural Networks · p. 9, 3) RQ3 (Limitation) · p. 9

B. Empirical Study on Deep Learning Bugs

  • Prior empirical studies used Stack Overflow and GitHub material to examine deep-learning bug symptoms, root causes, and fixes across libraries.The cited repair-pattern study analyzed 415 Stack Overflow posts and 555 GitHub commits.Source: B. Empirical Study on Deep Learning Bugs · p. 10

C. Bugs Repairing in Deep Learning

The paper distinguishes its structural-bug localization from prior DNN repair work, then reports detection and localization results against Keras and outlines future directions.

C. Bugs Repairing in Deep Learning

  • The authors describe their approach as the first to automatically identify buggy models and localize structural-bug root causes, while prior work focused on training bugs.The paper identifies MODE and Apricot as prior repair approaches.Source: C. Bugs Repairing in Deep Learning · pp. 10–11

VII. CONCLUSIONS AND FUTURE WORK

  • 34/40 faults were detected versus 32/40 by the best Keras debugging approach, and 21/40 bugs were localized while Keras localized none.The authors identify repair, unexplored failures, structural decomposition, and non-functional bugs such as fairness as future directions.Source: §VII · p. 11
Loading 2103.03376v1…