Pith. sign in

REVIEW 4 major objections 5 minor 66 references

ConfLogger: Enhance Systems' Configuration Diagnosability through Configuration Logging

T0 review · 4 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that injecting configuration-aware log statements—found by taint analysis, written by an LLM—raises misconfiguration localization from 0% to 100% on 30 silent-failure cases.

desk verdict ConfLogger is a genuinely new config-specific logging pipeline, but the headline 100% claim rests on a self-selected benchmark and a diagnostic metric that rewards exactly what the generator was told to emit. read the letter →

arxiv 2508.20977 v2 pith:6LACXXP3 submitted 2025-08-28 cs.SE

Shiwen Shan , Yintong Huo , Yuxin Su , Zhining Wang , Dan Li , Zibin Zheng This is my paper
classification cs.SE
keywords configurationdiagnosabilitymisconfigurationdiagnosisloggingtaintanalysisprogramdependencegraphLLM-basedloggenerationsilentpractice
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ConfLogger's proposal is that a system's configuration diagnosability can be improved at the source, before any failure happens: software should log its configuration decision points, not just its errors. The paper documents two deficiencies in current systems — silent failures, where a bad parameter value is ignored without any warning, and insufficient diagnostic messages, where logs omit the parameter name and value — and argues that these gaps, not the analysis tools, are what make misconfigurations hard to fix. ConfLogger closes the gap in two steps: configuration-aware static taint analysis (tracking configuration values as they flow through the program) locates the code where those values are checked and acted upon, and an LLM generates logging statements that expose the parameter name, runtime value, violated constraint, and a concrete fix hint. The central empirical claim is that these added logs let a log-based diagnosis tool localize 100% of 30 silent-misconfiguration scenarios (versus 0% on the original logs), and in a user study helped people diagnose failures 1.25x faster with 251.4% higher accuracy than with official documentation alone.

What carries the argument

The load-bearing mechanism is a two-stage pipeline. Stage one, configuration-sensitive code identification: parameter keys from official configuration documents are matched to source constants, seeding 'configuration engine' classes (Key-Holder: identifier constants only; Both-Holder: keys plus typed getters; Dict-Holder: dictionary maps), expanded through inheritance and composition. A program dependence graph over SSA form is traversed by breadth-first search (bounded to 30 hops) from getter-call statements (sources) to branches consuming the tainted values (sinks); the branch and its handling code is the logging target. Stage two, LLM log generation: the model inspects the extracted block

What would settle it

Run ConfLogger on a real configurable program that reads its configuration through an untyped dictionary or direct field injection rather than the three recognized engine types, and check whether the branches that decide behavior on invalid values receive generated logs; any configuration-sensitive branch that goes unlogged refutes the coverage claim. Conversely, construct a configuration-sensitive branch more than 30 dependence-graph hops from its getter call and confirm that no log is injected — the paper's own bound guarantees this miss.

Watch

Extended reading notes

Core claim

The paper argues that configuration diagnosability can be engineered in advance: a tool that tracks where configuration values flow into program logic can write the log lines that turn silent failures into nameable causes. ConfLogger labels configuration-engine classes from official documentation, traces parameter values through a program dependence graph with bounded taint analysis, and treats the branches that check those values as configuration-sensitive code. An LLM, given the extracted block and the tracked parameter key, generates messages carrying the parameter name, runtime value, constraint, and fix guidance. In evaluation, 30 silent misconfigurations — all undiagnosable from origin

Load-bearing premise

The method rests on the assumption that configuration values reach program logic only through getter calls on a small set of recognizable configuration-engine classes (Key-Holder, Both-Holder, Dict-Holder) and that every configuration-sensitive decision is within 30 data- or control-flow steps of such a call; systems that read configuration through untyped maps, direct field access, or longer propagation chains will be invisible to the tool.

Editorial extensions

If this is right

  • If the 100% localization result holds beyond the 30 benchmark cases, log-based diagnosis tools can treat configuration logging — not just log analysis — as the variable they improve, and system owners can ask whether a failure mode even produces a diagnosable log before shipping.
  • The 74% coverage of existing human-written configuration log points, versus 57–66% for general LLM loggers, implies that configuration-aware tracing, not a bigger language model, is the bottleneck for logging configuration decisions.
  • The roughly 39x speedup over manual identification of configuration engines makes pre-mortem log enhancement affordable: about 4 seconds of automated analysis versus 155 seconds of human effort, with the invalid rate dropping from 26.6% to 8.9%.
  • Because 24 of 30 silent failures were resolved by direct parameter extraction, the design implies that explicit parameter identifiers in logs are the highest-value diagnostic content, more valuable than free-text explanations.
  • The user study results imply that enhanced logs can substitute for configuration documentation in practice, which matters for systems whose documentation is stale or ambiguous.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The two-component design implies a sharp division of labor — static analysis supplies the 'where,' the LLM supplies the 'what to say.' A testable consequence: giving the LLM whole methods instead of taint-traced entry points should degrade log quality to baseline levels, since the comparison loggers that lack the tracing step achieve lower coverage.
  • The 30-hop bound and the three engine types are portability boundaries. Systems whose configuration enters through untyped dictionaries, reflection, or dependency injection sit outside the typed-getter assumption; transplanting the idea to such languages would need new source-validation rules, and the 100% figure would not automatically transfer.
  • Six of the 30 cases fell back to indirect inference because of parameter-name/documentation mismatches and misleading tokens in logs. A concrete improvement the paper leaves implicit: constrain the generated log text to the documented parameter schema (canonical key plus official description), which should push direct inference toward 100%.
  • Injecting log text that deliberately departs from legacy templates (the paper reports low text-similarity scores) could break log parsers and anomaly detectors tuned on historical formats; a hybrid that appends the diagnostic clause to an existing template, rather than replacing it, would preserve both diagnosability and downstream tooling compatibility.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. ConfLogger proposes to improve configuration diagnosability by inserting configuration-specific log statements into Java systems. It first uses a configuration-class labeling step plus interprocedural PDG taint analysis to locate configuration-sensitive code blocks, then uses an LLM with chain-of-thought prompting to decide whether/how to add logging statements that expose parameter names, values, constraints, and remediation guidance. The evaluation is carried out on eight Java systems and reports: (i) RQ1, 100% localization accuracy on 30 silent-misconfiguration cases using the LogConfigLocalizer tool; (ii) RQ2, 74% coverage of existing log points versus 66% for UniLog and 57% for SCLogger, with higher variable-logging F1; (iii) RQ3, faster and more precise configuration-engine identification than a random/manual variant; and (iv) RQ4, a user study showing faster and more accurate diagnosis with ConfLogger-enhanced logs than with documentation only.

Significance. If the claims were supported by an independent benchmark, ConfLogger would be a useful contribution: it is, to my knowledge, the first tool to treat configuration logging as a diagnosability enhancement problem, and the combination of static taint analysis with LLM-based log generation is sensible and novel. The paper ships an open-source implementation, evaluates on eight real systems, and includes a user study, which are strengths. However, the central evaluation is weakened by author-constructed benchmarks and by an evaluation design that largely measures ConfLogger's own selection criteria rather than an external notion of diagnosability. The core idea is plausible and worth pursuing, but the current evidence does not support the abstract's broad generalization to 'enhancing systems' configuration diagnosability.'

major comments (4)
  1. [§5.2, §5.3.1, Fig. 4] Benchmark I is self-selected. The paper states that the 30 cases are those whose original implementations suffer from silent failures and that ConfLogger was used to replicate them, but it does not report the candidate pool, the selection criteria, or any cases where ConfLogger failed to produce an enhanced log. Because LogConfigLocalizer's direct inference phase is rule-based extraction of explicit parameter names from logs (§5.3.1), and ConfLogger is explicitly instructed to include parameter names and actionable guidance (§4.3.2), the 100% direct/indirect hit rate largely measures whether the LLM followed the prompt. The 0%→100% contrast is built into the benchmark design. A comparison with a simple baseline that logs the parameter name/value at every recognized getter call site is missing. This is load-bearing for the RQ1 claim and for the abstract's generalization.
  2. [§5.2, §5.3.2, Table 4] Benchmark II's ground truth is circular. The 90 log points were 'identified by ConfLogger as diagnostically sufficient and manually validated as configuration-related.' Measuring ConfLogger's coverage against ground truth produced by ConfLogger's own criteria inflates the metric. The baseline comparison is further weakened by the admitted adaptation: UniLog and SCLogger were pre-populated with project-specific logging methods and had target methods manually designated, which bypasses ConfLogger's automated configuration-sensitive-code localization and biases the comparison in ConfLogger's favor. An independent ground truth derived from developer-added logs, historical commits, or a separate manual annotation process is needed, and the same target-method identification should be applied to all tools.
  3. [§4.2.3, Table 2, §4.2.4] The method's coverage of real configuration-reading patterns is not established. ConfLogger relies on taint sources being getter calls on three recognized configuration-engine types (Key-Holder, Both-Holder, Dict-Holder) and on configuration-sensitive code lying within 30 BFS hops of those sources. Systems that read configuration through untyped dictionaries, direct field access, reflection, or longer propagation chains are invisible to ConfLogger. The paper does not quantify how many configuration usages in the eight evaluated systems fall outside these assumptions, nor does it provide a sensitivity analysis for the path-length limit of 30. This is a correctness-risk concern for the generalizability claim; at minimum, an external-validity analysis is needed.
  4. [§5.3.4, Fig. 6] The user study's reporting is ambiguous and its statistical support is thin. The abstract says '22 cases,' but §5.3.4 describes five representative misconfiguration scenarios; it appears that 22 participants may have been used, but this is not explicit. The between-subjects design with such a small number of scenarios and no significance test makes the 251.4% accuracy improvement difficult to interpret. This is less central than RQ1/RQ2, but it should be reported with precise participant counts, scenario-to-condition allocation, and at least a basic statistical test or effect-size measure.
minor comments (5)
  1. [Fig. 4] Typo: 'Overall Hit Score btween' should be 'between'.
  2. [Table 4 / Answer to RQ2] Inconsistency: Table 4 reports CL-Average F1 = 0.501, but the Answer to RQ2 states F1 = 0.541. The corresponding baseline values also need to be aligned.
  3. [§5.3.4] Typo: 'Experiement Setting' should be 'Experiment Setting'; also clarify whether '22 cases' refers to participants, scenarios, or logged cases.
  4. [Fig. 5] 'BM2.5' appears to be a typo for 'BM25'.
  5. [§5.3.2] The paper says SCLogger was 'reproduced under the agreement of the authors.' If a public reproduction is available, include a link; if not, state the degree of fidelity more precisely.

Circularity Check

2 steps flagged · score 6.0 of 10

RQ1's direct-localization result is constructed: generated logs are mandated to include parameter names, and success is measured by a rule that extracts exactly those names, using the authors' own LogConfigLocalizer.

  1. self definitional [Section 4.3.2 (Log Message Generation) and Section 5.3.1 (RQ1)]
    "LogConfigLocalizer employs rule-based extraction of explicit parameters in logs during its direct inference phase. ... dynamic variables capturing parameter names and runtime values, aligned with configuration troubleshooting practices [38, 51, 59]."

    Section 2 defines a configuration-informative log as one containing parameter identifiers/values, constraints, and guidance; Section 4.3.2 instructs the LLM to generate exactly these components; and Section 5.3.1's direct-inference phase succeeds by rule-based extraction of explicit parameters from logs. Thus '80% directly resolvable through explicit configuration information' is not an independent prediction about diagnosability—it is a check that the LLM emitted the property it was prompted to emit. The 0% to 100% contrast on silent cases is therefore partly manufactured: a log that names the parameter will be found by a rule that looks for named parameters.

  2. self citation load bearing [Section 5.3.1 (Experiment Setting), with reference [38]]
    "We validate the effectiveness of ConfLogger on Benchmark I using LogConfigLocalizer [38]."

    LogConfigLocalizer is the authors' prior work (Shan et al., ISSTA 2024), and Section 4.3.2 says the log-generation rules are 'aligned with configuration troubleshooting practices [38, 51, 59]'. The headline 100% localization accuracy is therefore obtained by evaluating ConfLogger with a tool whose input conventions ConfLogger was explicitly designed to satisfy. No independent diagnoser or external benchmark is used for RQ1, so the result is a closed self-citation loop rather than evidence of general diagnosability.

full rationale

The paper contains no mathematical derivation chain; the circularity is in the evaluation design. Step 1 is a definitional overlap: the mandatory output property (parameter names and values in logs) is identical to the direct-inference success criterion (rule-based extraction of explicit parameters). Step 2 makes this more severe because the successful evaluator is the authors' own prior tool, and the generation rules are explicitly aligned with it. Benchmark I is also self-selected—Section 5.2 says the cases were 'identified' and then ConfLogger was used to 'replicate' them, with no candidate pool or selection criteria reported—which weakens the 0% to 100% contrast, though this is selection bias rather than a by-construction reduction. The remaining experiments provide partial independent content: RQ2 compares against UniLog and SCLogger on existing developer log points, RQ3 ablates the source-identification strategy, and RQ4 is a human study. Because the central RQ1 result is partially constructed and the headline evaluation relies on a self-citation, the score is 6 rather than 0-2.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claim rests on three kinds of assumptions: (1) the PDG/SSA taint analysis is a faithful model of configuration data flow, (2) the hand-crafted notion of configuration-sensitive code (checking-handling blocks) is the right unit for logging, and (3) the LLM, prompted with configuration contexts, produces correct and useful log statements. No new entities are introduced. The 30-edge BFS cap and the getter validation rules are free parameters that control what code is considered.

free parameters (2)
  • tainted path length limit = 30
    BFS traversal on PDG is limited to path length 30 to balance efficiency and accuracy (Section 5.1). This cutoff determines which configuration-sensitive code segments are found; it is an implementation choice not derived from data.
  • getter type validation rules = Table 2
    Table 2 specifies which parameter types are allowed for each configuration engine type; these hand-crafted rules directly influence which call statements are treated as taint sources and thus which code gets logged.
assumptions (5)
  • domain assumption PDG-based taint analysis with SSA IR accurately models configuration data flow across procedures.
    Invoked in Section 4.2.3; the method's identification of configuration-sensitive code depends on this analysis being sound and complete enough.
  • domain assumption Checking-handling code blocks are the correct unit for configuration-sensitive code and the best place to insert logs.
    Stated in Section 4.2.1; the entire approach is built on this design choice.
  • domain assumption GPT-4o generates textually and semantically correct logging statements from the provided configuration context.
    Section 4.3 relies on the LLM to decide whether to log, where to log, and what to write; no verification of generated logs is performed beyond the downstream diagnosis evaluation.
  • domain assumption Configuration documentation maps cleanly to identifiers in source code.
    Section 4.2.2 labels configuration engine classes by matching documentation parameter keys to code identifiers; imperfect mapping would cause missed or wrong sources.
  • domain assumption LogConfigLocalizer's two-phase inference is a valid proxy for diagnosability.
    Section 5.3.1 uses this same-group tool as the sole evaluator of diagnosis success, so the measured 'diagnosability' is defined by that tool's rules.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ConfLogger: Enhance Systems' Configuration Diagnosability through Configuration Logging." pith.science (2026). https://pith.science/paper/6LACXXP3

@misc{pith2026250820977,
  author       = {Pith},
  title        = {Pith review of: ConfLogger: Enhance Systems' Configuration Diagnosability through Configuration Logging},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6LACXXP3}},
  note         = {Machine review of arXiv:2508.20977}
}
read the original abstract

Modern configurable systems offer customization via intricate configuration spaces, yet such flexibility introduces pervasive configuration-related issues such as misconfigurations and latent softwarebugs. Existing diagnosability supports focus on post-failure analysis of software behavior to identify configuration issues, but none of these approaches look into whether the software clue sufficient failure information for diagnosis. To fill in the blank, we propose the idea of configuration logging to enhance existing logging practices at the source code level. We develop ConfLogger, the first tool that unifies configuration-aware static taint analysis with LLM-based log generation to enhance software configuration diagnosability. Specifically, our method 1) identifies configuration-sensitive code segments by tracing configuration-related data flow in the whole project, and 2) generates diagnostic log statements by analyzing configuration code contexts. Evaluation results on eight popular software systems demonstrate the effectiveness of ConfLogger to enhance configuration diagnosability. Specifically, ConfLogger-enhanced logs successfully aid a log-based misconfiguration diagnosis tool to achieve 100% accuracy on error localization in 30 silent misconfiguration scenarios, with 80% directly resolvable through explicit configuration information exposed. In addition, ConfLogger achieves 74% coverage of existing logging points, outperforming baseline LLM-based loggers by 12% and 30%. It also gains 8.6% higher in precision, 79.3% higher in recall, and 26.2% higher in F1 compared to the state-of-the-art baseline in terms of variable logging while also augmenting diagnostic value. A controlled user study on 22 cases further validated its utility, speeding up diagnostic time by 1.25x and improving troubleshooting accuracy by 251.4%.

Figures

Figures reproduced from arXiv: 2508.20977 by the authors.

Figure 1
Figure 1. Overview of ConfLogger. 4 ConfLogger 4.1 Overview [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. An example of configuration-sensitive code identification. The red text indicates objects colored by the configuration [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. An example case of logging statement generation. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Overall Hit Scores and Hit Scores of different inference phases. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: A case example on Benchmark II. manually trace general configuration engines, identify getter func￾tions for taint analysis rules. Conventional approaches only require locating configuration engine types regardless of specific parame￾ters as RN implements. We deem the …
Figure 6
Figure 6. Figure 6: Results of Group LA and DA on total points and [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

66 extracted references · 63 canonical work pages

  1. [1]

    AlDanial. 2024. cloc. https://github.com/AlDanial/cloc. Accessed: 2025-01-20

    work page 2024

  2. [2]

    Boyuan Chen and Zhen Ming Jiang. 2017. Characterizing and detecting anti- patterns in the logging code. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 71–81

    work page 2017

  3. [3]

    Boyuan Chen and Zhen Ming Jiang. 2019. Extracting and studying the Logging- Code-Issue-Introducing changes in Java-based large-scale open source software systems. Empirical Software Engineering 24 (2019), 2285–2322

    work page 2019

  4. [4]

    Qingrong Chen, Teng Wang, Owolabi Legunsen, Shanshan Li, and Tianyin Xu

    work page

  5. [5]

    Zhen Dong, Artur Andrzejak, David Lo, and Diego Costa. 2016. Orplocator: Identifying read points of configuration options via static analysis. In 2016 IEEE 27th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 185–195

    work page 2016

  6. [6]

    Min Du, Feifei Li, Guineng Zheng, and Vivek Srikumar. 2017. Deeplog: Anomaly detection and diagnosis from system logs through deep learning. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security . 1285–1298

    work page 2017

  7. [7]

    Jeanne Ferrante, Karl J Ottenstein, and Joe D Warren. 1987. The program de- pendence graph and its use in optimization. ACM Transactions on Programming Languages and Systems (TOPLAS) 9, 3 (1987), 319–349

    work page 1987

  8. [8]

    ASM Framework. 2025. https://asm.ow2.io/. Accessed: 2025-01-20

    work page 2025

Show all 66 references
  1. [9]

    WALA Framework. 2025. https://github.com/wala/WALA. Accessed: 2025-01-20

    2025

  2. [10]

    Ying Fu, Teng Wang, Shanshan Li, Jinyan Ding, Shulin Zhou, Zhouyang Jia, Wang Li, Yu Jiang, and Xiangke Liao. 2024. MissConf: LLM-Enhanced Repro- duction of Configuration-Triggered Bugs. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering:...

    2024

  3. [11]

    GPT-4o. [n. d.]. GPT-4o. https://platform.openai.com/docs/models/gpt-4o. Ac- cessed: 2025-01-20

    2025

  4. [12]

    James Hampton. 2018. The between-subjects experiment. In Laboratory psychol- ogy. Psychology Press, 15–37

    2018

  5. [13]

    Pinjia He, Jieming Zhu, Zibin Zheng, and Michael R Lyu. 2017. Drain: An online log parsing approach with fixed depth tree. In 2017 IEEE international conference on web services (ICWS) . IEEE, 33–40

    2017

  6. [14]

    Shilin He, Pinjia He, Zhuangbin Chen, Tianyi Yang, Yuxin Su, and Michael R Lyu. 2021. A survey on automated log analysis for reliability engineering. ACM computing surveys (CSUR) 54, 6 (2021), 1–37

    2021

  7. [15]

    Yintong Huo, Cheryl Lee, Yuxin Su, Shiwen Shan, Jinyang Liu, and Michael R Lyu. 2023. EvLog: Identifying Anomalous Logs over Software Evolution. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 391–402

    2023

  8. [16]

    Yintong Huo, Yuxin Su, Cheryl Lee, and Michael R Lyu. 2023. Semparser: A semantic parser for log analytics. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 881–893

    2023

  9. [17]

    Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023. Survey of hallucination in natural language generation. Comput. Surveys 55, 12 (2023), 1–38

    2023

  10. [18]

    Zhouyang Jia, Shanshan Li, Xiaodong Liu, Xiangke Liao, and Yunhuai Liu. 2018. SMARTLOG: Place error log statement by deep understanding of log intention. In 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 61–71

    2018

  11. [19]

    Zhihan Jiang, Jinyang Liu, Zhuangbin Chen, Yichen Li, Junjie Huang, Yintong Huo, Pinjia He, Jiazhen Gu, and Michael R Lyu. 2024. LILAC: Log parsing using LLMs with adaptive parsing cache. Proceedings of the ACM on Software Engineering 1, FSE (2024), 137–160

    2024

  12. [20]

    Lorenzo Keller, Prasang Upadhyaya, and George Candea. 2008. ConfErr: A tool for assessing resilience to human configuration errors. In 2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN) . IEEE, 157–166

    2008

  13. [21]

    Heng Li, Weiyi Shang, Bram Adams, Mohammed Sayagh, and Ahmed E Hassan

  14. [22]

    Heng Li, Weiyi Shang, and Ahmed E Hassan. 2017. Which log level should developers choose for a new logging statement? Empirical Software Engineering 22 (2017), 1684–1716

    2017

  15. [23]

    IEEE Transactions on Software Engineering 47, 12 (2020), 2858–2873

    A qualitative study of the benefits and costs of logging from developers’ perspectives. IEEE Transactions on Software Engineering 47, 12 (2020), 2858–2873

    2020

  16. [24]

    Shanshan Li, Wang Li, Xiangke Liao, Shaoliang Peng, Shulin Zhou, Zhouyang Jia, and Teng Wang. 2018. Confvd: System reactions analysis and evaluation through misconfiguration injection. IEEE Transactions on Reliability 67, 4 (2018), 1393–1405

    2018

  17. [25]

    Junqiang Li, Senyi Li, Keyao Li, Falin Luo, Hongfang Yu, Shanshan Li, and Xiang Li. 2024. ECFuzz: Effective Configuration Fuzzing for Large-Scale Systems. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering. 1–12

    2024

  18. [26]

    Wang Li, Shanshan Li, Xiangke Liao, Xiangyang Xu, Shulin Zhou, and Zhouyang Jia. 2017. Conftest: Generating comprehensive misconfiguration for system reaction ability evaluation. In Proceedings of the 21st International Conference on Evaluation and Assessment in Software Engin...

    2017

  19. [27]

    Wang Li, Zhouyang Jia, Shanshan Li, Yuanliang Zhang, Teng Wang, Erci Xu, Ji Wang, and Xiangke Liao. 2021. Challenges and opportunities: an in-depth empirical study on configuration error injection testing. In Proceedings of the 30th ACM SIGSOFT International Symposium on Softw...

    2021

  20. [28]

    Zhenhao Li. 2020. Towards providing automated supports to developers on writing logging statements. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings . 198–201

    2020

  21. [29]

    Yichen Li, Yintong Huo, Renyi Zhong, Zhihan Jiang, Jinyang Liu, Junjie Huang, Jiazhen Gu, Pinjia He, and Michael R Lyu. 2024. Go static: Contextualized logging statement generation. Proceedings of the ACM on Software Engineering 1, FSE (2024), 609–630

    2024

  22. [30]

    Zhenhao Li, Heng Li, Tse-Hsun Chen, and Weiyi Shang. 2021. Deeplv: Sug- gesting log levels using ordinal based neural networks. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . IEEE, 1461–1472

    2021

  23. [31]

    Zhenhao Li, Tse-Hsun Chen, and Weiyi Shang. 2020. Where shall we log? studying and suggesting logging locations in code blocks. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering . 361– 372

    2020

  24. [32]

    Xiangke Liao, Shulin Zhou, Shanshan Li, Zhouyang Jia, Xiaodong Liu, and Haochen He. 2018. Do you really know how to configure your software? config- uration constraints in source code may help. IEEE Transactions on Reliability 67, 3 (2018), 832–846

    2018

  25. [33]

    Xinyu Lian, Yinfang Chen, Runxiang Cheng, Jie Huang, Parth Thakkar, Minjia Zhang, and Tianyin Xu. 2024. Large Language Models as Configuration Validators. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE) . IEEE Computer Society, 204–216

    2024

  26. [34]

    Antonio Mastropaolo, Luca Pascarella, and Gabriele Bavota. 2022. Using deep learning to generate complete log statements. In Proceedings of the 44th Interna- tional Conference on Software Engineering . 2279–2290

    2022

  27. [35]

    Jiahao Liu, Jun Zeng, Xiang Wang, Kaihang Ji, and Zhenkai Liang. 2022. Tell: log level suggestions via modeling multi-level code block information. In Proceed- ings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 27–38

    2022

  28. [36]

    Maven Repository. 2024. Maven Repository. https://mvnrepository.com/. Ac- cessed: 2025-01-20

    2024

  29. [37]

    Mirza Masfiqur Rahman and Ashish Kundu. 2024. Code Hallucination. arXiv preprint arXiv:2407.04831 (2024)

    2024 arXiv

  30. [38]

    Shiwen Shan, Yintong Huo, Yuxin Su, Yichen Li, Dan Li, and Zibin Zheng. 2024. Face it yourselves: An llm-based two-stage strategy to localize configuration errors via logs. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 13–25

    2024

  31. [39]

    Edward J Schwartz, Thanassis Avgerinos, and David Brumley. 2010. All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask). In 2010 IEEE symposium on Security and privacy. IEEE, 317–331

    2010

  32. [40]

    Xudong Sun, Runxiang Cheng, Jianyan Chen, Elaine Ang, Owolabi Legunsen, and Tianyin Xu. 2020. Testing configuration changes in context to prevent production failures. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 735–751

    2020

  33. [41]

    SLF4J. 2024. SLF4J. https://slf4j.org/. Accessed: 2025-01-20

    2024

  34. [42]

    Adrian-Victor Vevera, Andreea Cătălina CRĂCIUN, Mihail DUMITRACHE, Ionut SANDU, Carmen-Ionela ROTUNĂ, and Radu Alexandru BOSTAN. 2025. Cyber- security Challenges in Managing Domain Names. From DNS to ENS in the Web3 Era. Romanian Cyber Security Journal 7, 1 (2025), 97–112

    2025

  35. [43]

    Chunqiang Tang, Thawan Kooburat, Pradeep Venkatachalam, Akshay Chander, Zhe Wen, Aravind Narayanan, Patrick Dowell, and Robert Karl. 2015. Holistic configuration management at facebook. In Proceedings of the 25th symposium on operating systems principles. 328–343

    2015

  36. [44]

    Teng Wang, Zhouyang Jia, Shanshan Li, Si Zheng, Yue Yu, Erci Xu, Shaoliang Peng, and Xiangke Liao. 2023. Understanding and detecting on-the-fly configuration bugs. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 628–639

    2023

  37. [45]

    Teng Wang, Haochen He, Xiaodong Liu, Shanshan Li, Zhouyang Jia, Yu Jiang, Qing Liao, and Wang Li. 2023. Conftainter: Static taint analysis for configuration options. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1640–1651

    2023

  38. [46]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning ConfLogger: Enhance Systems’ Configuration Diagnosability through Configuration Logging ICSE ’26, April 12–18, 2026, Rio de...

    2022

  39. [47]

    Teng Wang, Xiaodong Liu, Shanshan Li, Xiangke Liao, Wang Li, and Qing Liao

  40. [48]

    Tianyin Xu, Long Jin, Xuepeng Fan, Yuanyuan Zhou, Shankar Pasupathy, and Rukma Talwadker. 2015. Hey, you have given me too many knobs!: Understanding and dealing with over-designed configuration in system software. In Proceedings of the 2015 10th Joint Meeting on Foundations o...

    2015

  41. [49]

    Tianyin Xu, Xinxin Jin, Peng Huang, Yuanyuan Zhou, Shan Lu, Long Jin, and Shankar Pasupathy. 2016. Early detection of configuration errors to reduce failure damage. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). 619–634

    2016

  42. [50]

    Junjielong Xu, Ziang Cui, Yuan Zhao, Xu Zhang, Shilin He, Pinjia He, Liqun Li, Yu Kang, Qingwei Lin, Yingnong Dang, et al. 2024. UniLog: Automatic Logging via LLM and In-Context Learning. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering . 1–12

    2024

  43. [51]

    Tianyin Xu, Jiaqi Zhang, Peng Huang, Jing Zheng, Tianwei Sheng, Ding Yuan, Yuanyuan Zhou, and Shankar Pasupathy. 2013. Do not blame users for miscon- figurations. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 244–259

    2013

  44. [52]

    de Pádua, Weiyi Shang, Steve Sporea, Andrei Toma, and Sarah Sajedi

    Kundi Yao, Guilherme B. de Pádua, Weiyi Shang, Steve Sporea, Andrei Toma, and Sarah Sajedi. 2018. Log4perf: Suggesting logging locations for web-based systems’ performance monitoring. In Proceedings of the 2018 ACM/SPEC International Conference on Performance Engineering . 127–138

    2018

  45. [53]

    Tianyin Xu and Owolabi Legunsen. 2019. Configuration testing: Testing configu- ration values as code and with code. arXiv preprint arXiv:1905.12195 (2019)

    2019 arXiv

  46. [54]

    Lee, Xiaoming Tang, Yuanyuan Zhou, and Stefan Savage

    Ding Yuan, Soyeon Park, Peng Huang, Yang Liu, Michael M. Lee, Xiaoming Tang, Yuanyuan Zhou, and Stefan Savage. 2012. Be Conservative: Enhancing Failure Diagnosis with Proactive Logging. In 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12) . USENIX ...

    2012

  47. [55]

    Ding Yuan, Jing Zheng, Soyeon Park, Yuanyuan Zhou, and Stefan Savage. 2012. Improving software diagnosability via log enhancement. ACM Transactions on Computer Systems (TOCS) 30, 1 (2012), 1–28

    2012

  48. [56]

    Zuoning Yin, Xiao Ma, Jing Zheng, Yuanyuan Zhou, Lakshmi N Bairavasundaram, and Shankar Pasupathy. 2011. An empirical study on configuration errors in commercial and open source systems. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles . 159–172

    2011

  49. [57]

    Sai Zhang and Michael D Ernst. 2013. Automated diagnosis of software con- figuration errors. In 2013 35th International Conference on Software Engineering (ICSE). IEEE, 312–321

    2013

  50. [58]

    Sai Zhang and Michael D Ernst. 2014. Which configuration option should I change?. InProceedings of the 36th international conference on software engineering. 152–163

    2014

  51. [59]

    Jialu Zhang, Ruzica Piskac, Ennan Zhai, and Tianyin Xu. 2021. Static detection of silent misconfigurations with deep interaction analysis. Proceedings of the ACM on Programming Languages 5, OOPSLA (2021), 1–30

    2021

  52. [60]

    Xu Zhao, Kirk Rodrigues, Yu Luo, Michael Stumm, Ding Yuan, and Yuanyuan Zhou. 2017. Log20: Fully automated optimal placement of log printing statements under specified overhead threshold. In Proceedings of the 26th Symposium on Operating Systems Principles. 565–581

    2017

  53. [61]

    Renyi Zhong, Yichen Li, Jinxi Kuang, Wenwei Gu, Yintong Huo, and Michael R Lyu. 2024. Automated Defects Detection and Fix in Logging Statement. arXiv preprint arXiv:2408.03101 (2024)

    2024 arXiv

  54. [62]

    Sai Zhang and Michael D Ernst. 2015. Proactive detection of inadequate diagnostic messages for software configuration errors. InProceedings of the 2015 International Symposium on Software Testing and Analysis . 12–23

    2015

  55. [63]

    Jieming Zhu, Pinjia He, Qiang Fu, Hongyu Zhang, Michael R Lyu, and Dong- mei Zhang. 2015. Learning to log: Helping developers make informed logging decisions. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engi- neering, Vol. 1. IEEE, 415–425

    2015

  56. [65]

    Shulin Zhou, Xiaodong Liu, Shanshan Li, Zhouyang Jia, Yuanliang Zhang, Teng Wang, Wang Li, and Xiangke Liao. 2021. Confinlog: Leveraging software logs to infer configuration constraints. In 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC) . IEEE, 94–105

    2021

  57. [2018]

    In 2018 IEEE International Conference on Software Quality, Reliability and Security (QRS)

    MisconfDoctor: diagnosing misconfiguration via log-based configuration testing. In 2018 IEEE International Conference on Software Quality, Reliability and Security (QRS). IEEE, 1–12

    2018

  58. [2020]

    In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    Understanding and discovering software configuration dependencies in cloud and datacenter systems. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 362–374

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.