Pith. sign in

REVIEW 5 major objections 8 minor 1 cited by

Harnessing LLMs for Document-Guided Fuzzing of OpenCV Library

T0 review · 5 major / 8 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read VISTAFUZZ claims that GPT-4-parsed API documentation can drive fuzzing of OpenCV, yielding 17 bugs of which 10 were confirmed and 5 fixed.

desk verdict Genuinely new application of LLM doc-guided fuzzing to OpenCV with externally confirmed bugs, but the paper's own numbers are inconsistent and the exception oracle needs scrutiny. read the letter →

arxiv 2507.14558 v1 pith:ATD4A6G4 submitted 2025-07-19 cs.SE

Bin Duan , Tarek Mahmud , Meiru Che , Yan Yan , Naipeng Dong , Dan Dongseong Kim , Guowei Yang This is my paper
classification cs.SE
keywords fuzzingOpenCVlargelanguagemodelsdocument-guidedtestingAPIdocumentationparameterdependenciesconstraintextractionbugdetection
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

VISTAFUZZ tries to establish that API documentation—even sparse, incomplete documentation—can be turned by an LLM into enough structured information to fuzz a real computer-vision library effectively. The paper's central result is that, testing 330 OpenCV-python APIs, the approach found 17 bugs, 10 confirmed by OpenCV developers and 5 already fixed. The method matters because OpenCV's strict dependencies between input parameters (image sizes, types, and ranges that must agree) defeated prior document-guided and LLM-based fuzzers, and because the 32 poorly documented APIs produced a disproportionate share of the finds (5 of 17 bugs from 9.7% of tested APIs). If the result holds, document-guided fuzzing can be extended to a class of libraries where previous tools stopped.

What carries the argument

The load-bearing mechanism is the standardized API information record: for every input parameter, GPT-4 produces five attributes—Flag (whether the parameter is modifiable), Default (a predefined value if any), Type (accepted data types), Size (array structure and dimensions), and Description (ranges and relations to other parameters). From these records VISTAFUZZ derives per-parameter constraints and, crucially, dependencies that make one parameter's Type or Size follow another's (for example, a second image matching the first image's shape and channel count). The generator then mutates inputs under Type, Size, and Value strategies while preserving those dependencies, and the oracle flags crashes, NaN results, and unexpected exceptions. This record is what transfers information from well-documented APIs to poorly documented ones: GPT-4 fills missing parameter details by analogy with parameters seen in well-documented APIs.

What would settle it

Take the GPT-4 standardized records for the 32 poorly documented APIs and compare each inferred parameter Type, Size, and Description against the function's C++ source signature and argument checks; count how many inferred constraints contradict the implementation. If a substantial share do, then the 99.39 percent valid-input rate would not survive an independent human-curated oracle, and some reported bugs would turn out to be invalid test inputs.

Watch

Extended reading notes

Core claim

VISTAFUZZ's claim is that the obstacle to fuzzing OpenCV is not random test generation but valid test generation: an OpenCV API often requires several parameters to satisfy joint constraints, and many APIs lack the documentation needed to know them. The paper's solution is to let GPT-4 parse each API's documentation into a standardized five-attribute record per input parameter—Flag, Default, Type, Size, and Description—and then extract both per-parameter constraints and cross-parameter dependencies from those records. Test inputs are generated under Type, Size, and Value strategies (including noise, masking, and division) and executed against the library, with crashes, NaN outputs, and unexpected exceptions logged as bugs. On 330 APIs of OpenCV-python v4.9.0, the approach reports 17 bugs, of which 10 were newly confirmed and 5 were fixed in v4.11.0; on well-documented APIs it extracted 2,797 constraints versus 528 for the closest document-guided baseline and generated inputs with 99.39% success versus 8.74%, leading to 48,902 covered lines versus 7,829.

Load-bearing premise

The approach assumes that the constraints GPT-4 extracts or infers from documentation are what each API actually requires, so an input that follows them and still crashes, returns NaN, or raises an exception is a library bug rather than a test artifact.

Editorial extensions

If this is right

  • Fuzzing that models cross-parameter dependencies can reach valid-input rates near 100 percent on libraries where prior documentation-based fuzzers generate mostly invalid inputs (8.74 percent in the comparison).
  • Poorly documented APIs are a comparatively high-yield target: 29.4 percent of the detected bugs came from the 9.7 percent of APIs tested that lacked parameter descriptions, so test budgets should not skip them.
  • The pipeline is language- and library-agnostic in design, so the same documentation-parsing, constraint-extraction, and dependency-modeling steps could be applied to other Python projects and dynamically typed libraries.
  • Five of the confirmed bugs were fixed by OpenCV in v4.11.0, and the remaining confirmed reports are active defects for downstream computer-vision applications to avoid.
  • Generating 600 test cases per API is a cost-effective operating point: coverage and bug count plateau around that budget in the paper's ablation.

Reading between the lines

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

  • The 99.39 percent validity rate is computed against the same doc-derived constraints that produced the inputs, so a stronger test would be to judge the generated inputs against an independent, human-curated specification; that check is not in the paper.
  • Because the approach treats documentation as the ground truth and the paper records two false positives caused by documentation errors, applying the method to another library is likely to produce a similar small rate of false positives until implementation and docs are cross-checked.
  • A natural extension the paper leaves implicit is applying the same standardized-information pipeline to the 248 undocumented OpenCV APIs by combining source-code signatures and type hints with the learned parameter patterns; the paper lists this as future work.
  • The reported concentration of bugs in poorly documented APIs suggests a testable prediction: other libraries with sparse documentation will show a higher per-API bug yield than well-documented ones when tested this way.
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

5 major / 8 minor

Summary. The paper presents VISTAFUZZ, a document-guided fuzzing approach for OpenCV Python APIs. It uses GPT-4 to parse API documentation into a standardized schema (Flag, Default, Type, Size, Description), extracts per-parameter constraints and inter-parameter dependencies, and generates test inputs under three strategies (Type, Size, Value) with sub-strategies for adding noise, random masking, and division. The oracle flags crashes, NaNs, and exceptions, and the evaluation on 330 APIs reports 17 detected bugs, with 10 confirmed by OpenCV maintainers and 5 subsequently fixed. The paper also claims a 99.39% valid input generation rate, 2,797 extracted constraints, and higher coverage than DocTer.

Significance. The externally confirmed bug reports are genuine evidence that documentation-guided fuzzing can find real defects in OpenCV, and the method's attempt to handle poorly-documented APIs could extend prior work such as DocTer to a new library class. However, the paper's headline numbers are internally inconsistent, the exception oracle underlying 13 of 17 reports is not independently validated, and the comparison with DocTer is confounded. The contribution is potentially significant, but the claims in their current form substantially overstate what is supported by the data.

major comments (5)
  1. [Section V-A1, Table I] The headline claim of '17 new bugs' is contradicted by the same section's breakdown: 10 newly confirmed, 5 previously known, and 2 false positives. The abstract and Section I refer to all 17 as 'new bugs,' which is inaccurate. Additionally, Table I's Reported column sums to 21 (3 crash + 5 NaN + 13 exception), not 17. Please correct the counts and consistently distinguish reported, newly confirmed, previously known, and false positive throughout the paper.
  2. [Section III-D, Section III-C1, Table I] The exception oracle is load-bearing but not validated. VISTAFUZZ deliberately generates invalid types and malformed data (Section III-C1), so an exception on such inputs can be expected behavior; treating every exception as a bug requires knowing the input is valid, which is not established independently of the documentation-derived constraints. The 99.39% success rate in Table II is measured against these same constraints, making it circular evidence of constraint quality. Since 13 of 17 reports come from the exception oracle and only 6 are confirmed, the total bug count is not robust to this issue.
  3. [Section IV-D, Table II] The comparison with DocTer is confounded. DocTer is applied only to well-documented APIs, while VISTAFUZZ is evaluated on all 330 APIs including 32 poorly-documented ones, so the higher coverage and bug count may stem from the larger API set rather than from the constraint extraction approach. The adaptation of DocTer is not described in sufficient detail to assess fairness. The claim that VISTAFUZZ 'detects all bugs found by DocTer' should be scoped to the comparable well-documented subset.
  4. [Section V-A2] The claim that poorly-documented APIs are more bug-prone rests on only 5 reported bugs and 2 confirmed bugs from 32 APIs. With such small numbers and no statistical analysis, the 29.4% versus 9.7% comparison is not compelling. Moreover, the GPT-4-inferred constraints for poorly-documented APIs are never checked against a human-curated specification, so the 2 confirmed bugs are the sole evidence that the inference produces valid inputs.
  5. [Section IV-B] The API exclusion counts are inconsistent. The listed exclusions (248 undocumented, 6 stereo/video, 55 file, 32 no outputs, 10 strong dependencies) sum to 351, leaving 328 APIs, not the stated 330. Figure 4 also includes a 'creating objects' category not described in the exclusion text. Please reconcile the arithmetic and clarify the exclusion workflow.
minor comments (8)
  1. [Abstract] The phrase '17 new bugs' should be reworded to match the breakdown in Section V-A1, for example '17 reported bugs, 10 of which were newly confirmed.'
  2. [Section III-C1] There is a typo 'the API API maintains' that should read 'the API maintains.'
  3. [Section III-B] There is a typo 'its its predefined constraints' that should read 'its predefined constraints.'
  4. [Section III-C1] When generating invalid types, the paper should explicitly state how the oracle distinguishes an expected TypeError from a genuine bug; without this distinction, the exception oracle is underspecified.
  5. [Section IV-C] The 'success rate' metric only checks whether the API throws an error; it does not assess whether a returned value is semantically correct, so the notion of 'success' is narrow and may not reflect test input validity.
  6. [Figure 5] The text says the starting point represents original test inputs without modification, but the x-axis begins at 100 generated test cases; please clarify how the starting point is defined.
  7. [Section V-A1] The paper does not list the actual OpenCV issue numbers or report identifiers for the 10 confirmed bugs; including them would strengthen reproducibility and independent verification.
  8. [Section III-A] The GPT-4 model version and hyperparameters (e.g., temperature) are not reported, which limits reproducibility of the standardized API information generation.

Circularity Check

1 steps flagged · score 1.0 of 10

Core bug-finding result is externally benchmarked by OpenCV maintainers and is not circular; only a minor self-referential validity definition remains (valid input is defined by the same GPT-4 parsing that generates the inputs).

  1. self definitional [Secs. III-A, III-C, III-D; Sec. IV-C; Sec. V-A1.]
    "These include arithmetic bugs, resource access discrepancies (e.g., correct inputs leading to incorrect exceptions or PermissionError), and logical bugs causing exceptions like index out-of-range or type incompatibility."

    The exception oracle counts an anomaly as a bug only when it occurs on 'correct inputs', but input correctness is defined by the constraints extracted from GPT-4's standardized API information, the same artifact from which the test inputs are generated. The 99.39% 'success rate' (Table II) likewise validates inputs against those self-produced constraints, and Sec. V-C attributes residual throws to 'discrepancies between the document description and the code implementation' rather than to an independent specification. The paper's own data expose the loop: 2 of 17 reports were false positives 'caused by errors in the documentation', and only 6 of 13 exception reports were confirmed.

full rationale

The central claim - VISTAFUZZ detected 17 bugs, 10 confirmed, 5 fixed - is not circular: bugs are defined behaviorally (crash, NaN, exception) and the decisive confirmations come from an external authority, the OpenCV maintainers, with fixes landing in v4.11.0. Crash and NaN reports (8 of 17) depend on no doc-derived constraint at all. There is no load-bearing self-citation: the paper cites no prior work of its own authors, invokes no imported uniqueness theorem, and smuggles no ansatz via citation; its GPT-4 standardization is an extension of DocTer rather than a renamed known result. The one self-referential element is the definition of 'valid/correct input': it is fixed by the same GPT-4-synthesized standardized API information that generates the test inputs, and the 99.39% success rate (Table II) is measured against those same constraints, making the exception oracle's validity partially self-referential. The paper acknowledges this by disclosing the 2 documentation-error false positives and the 6/13 exception-confirmation rate, and the external confirmations break the loop for the headline count. Caveats that are consistency or soundness issues rather than circularity: (i) Table I's reported category counts (3 crash + 5 NaN + 13 exceptions) sum to 21, not the stated total of 17; (ii) the constraint-count comparison (2,797 vs DocTer's 528) is representation-dependent since the five per-parameter attributes are each counted; (iii) the Sec. VI threat-to-validity passage concedes reliance on documentation 'as the primary data source' with no human-curated specification check of GPT-4's inferred constraints. None of these reduce the central derivation to its inputs.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The central claim rests on documentation as ground truth, GPT-4's ability to infer missing parameter information, and an oracle that treats exceptions, crashes, and NaN on conforming inputs as defects. None of these premises is independently verified: constraint accuracy is not measured against a human specification, and the oracle is known to over-fire (6/13 exception confirmations). The only free parameters are engineering choices: the 600-input budget, unspecified value-strategy parameters, and the API filter. No new physical or formal entities are postulated; the standardized API schema is a paper-specific data format whose outputs are externally checkable.

free parameters (3)
  • test_case_budget_per_api = 600
    Selected because coverage and bug counts plateau near 600 generations per API (Sec V-B1, Fig 5); the budget is tuned on the same experiment used to state the results.
  • value_strategy_parameters = not specified
    Noise levels, masking pixel values, and division divisors for the three value strategies (Sec III-C1) are never quantified, so a reimplementation must choose them by hand.
  • api_selection_filter = 330 of 679 APIs
    The tested set excludes undocumented, file-I/O, no-output, and strongly dependent APIs (Sec IV-B, Fig 4); all effectiveness claims apply only to the selected subset.
assumptions (4)
  • domain assumption OpenCV API documentation accurately specifies valid inputs and parameter dependencies
    The entire pipeline (Sec III-A to III-C) treats doc-derived constraints as ground truth for input validity; the paper's 2 false positives (Sec V-A1) show the premise is fallible.
  • domain assumption GPT-4 infers accurate constraints for poorly documented APIs by analogy to well documented ones
    Sec III-A relies on this inference for the 32 poorly documented APIs; 5 of 17 reports came from them with 2 confirmed, but inference accuracy is never directly evaluated.
  • domain assumption Crashes, NaN, and exceptions on documentation-conforming inputs are library defects
    Sec III-D defines the oracle this way; only 6 of 13 exception reports were confirmed, so the oracle over-fires relative to this assumption.
  • domain assumption Coverage.py and GCOV faithfully measure exercised code through the Python wrapper
    Sec IV-C relies on both tools to report 48,902 covered lines combining Python and C++ code.
invented entities (1)
  • Standardized API information schema (Flag, Default, Type, Size, Description) independent evidence
    purpose: Intermediate representation of API documentation that drives constraint extraction and input generation
    The schema is a paper-specific construct, but its outputs are falsifiable: 10 confirmed bugs and the 99.39% valid-input rate provide external handles, and the schema itself could be checked against human-annotated APIs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Harnessing LLMs for Document-Guided Fuzzing of OpenCV Library." pith.science (2026). https://pith.science/paper/ATD4A6G4

@misc{pith2026250714558,
  author       = {Pith},
  title        = {Pith review of: Harnessing LLMs for Document-Guided Fuzzing of OpenCV Library},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ATD4A6G4}},
  note         = {Machine review of arXiv:2507.14558}
}
read the original abstract

The combination of computer vision and artificial intelligence is fundamentally transforming a broad spectrum of industries by enabling machines to interpret and act upon visual data with high levels of accuracy. As the biggest and by far the most popular open-source computer vision library, OpenCV library provides an extensive suite of programming functions supporting real-time computer vision. Bugs in the OpenCV library can affect the downstream computer vision applications, and it is critical to ensure the reliability of the OpenCV library. This paper introduces VISTAFUZZ, a novel technique for harnessing large language models (LLMs) for document-guided fuzzing of the OpenCV library. VISTAFUZZ utilizes LLMs to parse API documentation and obtain standardized API information. Based on this standardized information, VISTAFUZZ extracts constraints on individual input parameters and dependencies between these. Using these constraints and dependencies, VISTAFUZZ then generates new input values to systematically test each target API. We evaluate the effectiveness of VISTAFUZZ in testing 330 APIs in the OpenCV library, and the results show that VISTAFUZZ detected 17 new bugs, where 10 bugs have been confirmed, and 5 of these have been fixed.

Figures

Figures reproduced from arXiv: 2507.14558 by the authors.

Figure 1
Figure 1. Overview of VISTAFUZZ III. APPROACH [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The example of parser minimizing manual intervention and enhancing the reliability of the testing process. We begin with well-documented APIs, as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Example of Standardized API Information and Initialisation [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: OpenCV-python APIs information. The entire testing process takes a total of 3.2 hours. Environment. We experiment on 64-core PC with 32GB RAM. C. Metrics Code Coverage. Code coverage is a widely adopted test adequacy criterion in traditional software testing. Tests are…
Figure 6
Figure 6. Figure 6: Code Coverage of Different Generation Strategies. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Bug Detection by Different Generation Strategies. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. XAMT: Cross-Framework API Matching for Testing Deep Learning Libraries

    cs.SE 2025-08 conditional novelty 5.0 of 10

    XAMT matches functionally equivalent APIs across five deep learning frameworks and uses variance-guided differential testing to detect 17 bugs, 12 confirmed, that intra-framework tests miss.

Reference graph

Works this paper leans on

65 extracted references · 56 canonical work pages · cited by 1 Pith paper

  1. [1]

    Szeliski, Computer vision: algorithms and applications

    R. Szeliski, Computer vision: algorithms and applications . Springer Nature, 2022

    work page 2022

  2. [2]

    Deep learning in computer vision: A critical review of emerging techniques and application scenar- ios,

    J. Chai, H. Zeng, A. Li, and E. W. Ngai, “Deep learning in computer vision: A critical review of emerging techniques and application scenar- ios,” Machine Learning with Applications , vol. 6, p. 100134, 2021

    work page 2021

  3. [3]

    The opencv library

    G. Bradski, “The opencv library.” Dr. Dobb’s Journal: Software Tools for the Professional Programmer , vol. 25, no. 11, pp. 120–123, 2000

    work page 2000

  4. [4]

    A vision-based home security system using opencv on raspberry pi 3,

    T. Prathaban, W. Thean, and M. I. S. M. Sazali, “A vision-based home security system using opencv on raspberry pi 3,” in AIP Conference Proceedings, vol. 2173, no. 1. AIP Publishing, 2019

    work page 2019

  5. [5]

    Hand gesture recognition on python and opencv,

    A. P. Ismail, F. A. Abd Aziz, N. M. Kasim, and K. Daud, “Hand gesture recognition on python and opencv,” in IOP conference series: Materials science and engineering , vol. 1045, no. 1. IOP Publishing, 2021, p. 012043

    work page 2021

  6. [6]

    Real time object detection and tracking using deep learning and opencv,

    G. Chandan, A. Jain, H. Jain et al. , “Real time object detection and tracking using deep learning and opencv,” in 2018 International Conference on inventive research in computing applications (ICIRCA) . IEEE, 2018, pp. 1305–1308

    work page 2018

  7. [7]

    Howse and J

    J. Howse and J. Minichino, Learning OpenCV 4 Computer Vision with Python 3: Get to grips with tools, techniques, and algorithms for computer vision and machine learning . Packt Publishing Ltd, 2020

    work page 2020

  8. [8]

    Minichino and J

    J. Minichino and J. Howse, Learning OpenCV 3 Computer Vision with Python. Packt Publishing Ltd, 2015

    work page 2015

Show all 65 references
  1. [9]

    Comparison of opencv’s feature detectors and feature matchers,

    F. K. Noble, “Comparison of opencv’s feature detectors and feature matchers,” in 2016 23rd International Conference on Mechatronics and Machine Vision in Practice (M2VIP) . IEEE, 2016, pp. 1–6

    2016

  2. [10]

    Evaluation of feature based image stitching algorithm using opencv,

    Y .-J. Ha and H.-D. Kang, “Evaluation of feature based image stitching algorithm using opencv,” in 2017 10th International Conference on Human System Interactions (HSI) . IEEE, 2017, pp. 224–229

    2017

  3. [11]

    Real-time lane detection and motion planning in raspberry pi and arduino for an autonomous vehicle prototype,

    A. Rossi, N. Ahmed, S. Salehin, T. H. Choudhury, and G. Sarowar, “Real-time lane detection and motion planning in raspberry pi and arduino for an autonomous vehicle prototype,” arXiv preprint arXiv:2009.09391, 2020

    2009 arXiv

  4. [12]

    A practical hybrid iot architecture with deep learning technique for healthcare and security applications,

    V . Q. Vu, M.-Q. Tran, M. Amer, M. Khatiwada, S. S. Ghoneim, and M. Elsisi, “A practical hybrid iot architecture with deep learning technique for healthcare and security applications,” Information, vol. 14, no. 7, p. 379, 2023

    2023

  5. [13]

    Revolutionizing healthcare: The application of image processing techniques,

    V . Eswaran, U. Eswaran, V . Eswaran, and K. Murali, “Revolutionizing healthcare: The application of image processing techniques,” in Medi- cal Robotics and AI-Assisted Diagnostics for a High-Tech Healthcare Industry. IGI Global, 2024, pp. 309–324

    2024

  6. [14]

    Machine vision based defect detection approach using image processing,

    M. Baygin, M. Karakose, A. Sarimaden, and A. Erhan, “Machine vision based defect detection approach using image processing,” in 2017 international artificial intelligence and data processing symposium (IDAP). Ieee, 2017, pp. 1–5

    2017

  7. [15]

    Uav navigation in gps-denied envi- ronment using particle filtered rvl,

    A. Couturier and M. A. Akhloufi, “Uav navigation in gps-denied envi- ronment using particle filtered rvl,” in Situation Awareness in Degraded Environments 2019, vol. 11019. SPIE, 2019, pp. 188–198

    2019

  8. [16]

    A review of computer vision–based structural health monitoring at local and global levels,

    C.-Z. Dong and F. N. Catbas, “A review of computer vision–based structural health monitoring at local and global levels,” Structural Health Monitoring, vol. 20, no. 2, pp. 692–743, 2021

    2021

  9. [17]

    Fuzzing: a survey,

    J. Li, B. Zhao, and C. Zhang, “Fuzzing: a survey,” Cybersecurity, vol. 1, no. 1, pp. 1–13, 2018

    2018

  10. [18]

    Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models,

    Y . Deng, C. S. Xia, H. Peng, C. Yang, and L. Zhang, “Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models,” in Proceedings of the 32nd ACM SIGSOFT interna- tional symposium on software testing and analysis , 2023, pp. 423–435

    2023

  11. [19]

    Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries,

    Y . Deng, C. S. Xia, C. Yang, S. D. Zhang, S. Yang, and L. Zhang, “Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 2024, pp. 1–13

    2024

  12. [20]

    Violating assumptions with fuzzing,

    P. Oehlert, “Violating assumptions with fuzzing,” IEEE Security & Privacy, vol. 3, no. 2, pp. 58–62, 2005

    2005

  13. [21]

    Fuzzing the internet of things: A review on the techniques and challenges for efficient vulnerability discovery in embedded systems,

    M. Eceiza, J. L. Flores, and M. Iturbe, “Fuzzing the internet of things: A review on the techniques and challenges for efficient vulnerability discovery in embedded systems,” IEEE Internet of Things Journal , vol. 8, no. 13, pp. 10 390–10 411, 2021

    2021

  14. [22]

    Rtfm! automatic assumption discovery and verification derivation from library document for api misuse detection,

    T. Lv, R. Li, Y . Yang, K. Chen, X. Liao, X. Wang, P. Hu, and L. Xing, “Rtfm! automatic assumption discovery and verification derivation from library document for api misuse detection,” in Proceedings of the 2020 ACM SIGSAC conference on computer and communications security , ...

    2020

  15. [23]

    Docter: documentation-guided fuzzing for testing deep learning api functions,

    D. Xie, Y . Li, M. Kim, H. V . Pham, L. Tan, X. Zhang, and M. W. God- frey, “Docter: documentation-guided fuzzing for testing deep learning api functions,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , 2022, pp. 176–188

    2022

  16. [24]

    Automatic early defects detection in use case documents,

    S. Liu, J. Sun, Y . Liu, Y . Zhang, B. Wadhwa, J. S. Dong, and X. Wang, “Automatic early defects detection in use case documents,” in Proceedings of the 29th ACM/IEEE international conference on Automated software engineering , 2014, pp. 785–790

    2014

  17. [25]

    Automatic detection and repair recommendation of directive defects in java api documentation,

    Y . Zhou, C. Wang, X. Yan, T. Chen, S. Panichella, and H. Gall, “Automatic detection and repair recommendation of directive defects in java api documentation,” IEEE Transactions on Software Engineering , vol. 46, no. 9, pp. 1004–1023, 2018

    2018

  18. [26]

    Translating code comments to procedure spec- ifications,

    A. Blasi, A. Goffi, K. Kuznetsov, A. Gorla, M. D. Ernst, M. Pezz `e, and S. D. Castellanos, “Translating code comments to procedure spec- ifications,” in Proceedings of the 27th ACM SIGSOFT international symposium on software testing and analysis , 2018, pp. 242–253

    2018

  19. [27]

    Large language model guided protocol fuzzing,

    R. Meng, M. Mirchev, M. B ¨ohme, and A. Roychoudhury, “Large language model guided protocol fuzzing,” in Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS) , 2024

    2024

  20. [28]

    Fuzz4all: Universal fuzzing with large language models,

    C. S. Xia, M. Paltenghi, J. Le Tian, M. Pradel, and L. Zhang, “Fuzz4all: Universal fuzzing with large language models,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering , 2024, pp. 1–13

    2024

  21. [29]

    Deep learning for computer vision: A brief review,

    A. V oulodimos, N. Doulamis, A. Doulamis, E. Protopapadakis et al. , “Deep learning for computer vision: A brief review,” Computational intelligence and neuroscience , vol. 2018, 2018

    2018

  22. [30]

    Computer vision techniques in construction: a critical review,

    S. Xu, J. Wang, W. Shou, T. Ngo, A.-M. Sadick, and X. Wang, “Computer vision techniques in construction: a critical review,” Archives of Computational Methods in Engineering , vol. 28, pp. 3383–3397, 2021

    2021

  23. [31]

    Kornia: an open source differentiable computer vision library for pytorch,

    E. Riba, D. Mishkin, D. Ponsa, E. Rublee, and G. Bradski, “Kornia: an open source differentiable computer vision library for pytorch,” in Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision, 2020, pp. 3674–3683

    2020

  24. [32]

    Chainercv: a library for deep learning in computer vision,

    Y . Niitani, T. Ogawa, S. Saito, and M. Saito, “Chainercv: a library for deep learning in computer vision,” in Proceedings of the 25th ACM international conference on Multimedia , 2017, pp. 1217–1220

    2017

  25. [33]

    Javavis: An integrated computer vision library for teaching computer vision,

    M. Cazorla and D. Viejo, “Javavis: An integrated computer vision library for teaching computer vision,” Computer Applications in Engineering Education, vol. 23, no. 2, pp. 258–267, 2015

    2015

  26. [34]

    Scenic: A jax library for computer vision research and beyond,

    M. Dehghani, A. Gritsenko, A. Arnab, M. Minderer, and Y . Tay, “Scenic: A jax library for computer vision research and beyond,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2022, pp. 21 393–21 398

    2022

  27. [35]

    gvnn: Neural network library for geometric computer vision,

    A. Handa, M. Bloesch, V . P ˘atr˘aucean, S. Stent, J. McCormac, and A. Davison, “gvnn: Neural network library for geometric computer vision,” in Computer Vision–ECCV 2016 Workshops: Amsterdam, The Netherlands, October 8-10 and 15-16, 2016, Proceedings, Part III 14 . Springer, ...

    2016

  28. [36]

    Benchmarking of feature detectors and matchers using opencv-python wrapper,

    O. Golovnin and D. Rybnikov, “Benchmarking of feature detectors and matchers using opencv-python wrapper,” in 2021 International Conference on Information Technology and Nanotechnology (ITNT) . IEEE, 2021, pp. 1–6

    2021

  29. [37]

    Face detection and recognition using opencv,

    R. T. Hasan and A. B. Sallow, “Face detection and recognition using opencv,” Journal of Soft Computing and Data Mining , vol. 2, no. 2, pp. 86–97, 2021

    2021

  30. [38]

    Emotion detection with facial feature recognition using cnn & opencv,

    S. Giri, G. Singh, B. Kumar, M. Singh, D. Vashisht, S. Sharma, and P. Jain, “Emotion detection with facial feature recognition using cnn & opencv,” in 2022 2nd International Conference on Advance Computing and Innovative Technologies in Engineering (ICACITE) . IEEE, 2022, pp. 230–232

    2022

  31. [39]

    Object detection using opencv and python,

    A. Sharma, J. Pathak, M. Prakash, and J. Singh, “Object detection using opencv and python,” in 2021 3rd International Conference on Advances in Computing, Communication Control and Networking (ICAC3N) . IEEE, 2021, pp. 501–505

    2021

  32. [40]

    Real time automatic attendance system for face recognition using face api and opencv,

    S. Khan, A. Akram, and N. Usman, “Real time automatic attendance system for face recognition using face api and opencv,” Wireless Personal Communications, vol. 113, pp. 469–480, 2020

    2020

  33. [41]

    Automated visual inspection and defect detection of large-scale silicon strip sensors,

    K. Affolder, A. Ciocio, E. Cornell, V . Fadeyev, Z. Luce, J. Gunnell, F. Martinez-McKinney, T. Johnson, R. MacFadyen, L. Poley et al. , “Automated visual inspection and defect detection of large-scale silicon strip sensors,” Journal of Instrumentation , vol. 17, no. 03, p. P03...

    2022

  34. [42]

    Metamorphic testing of deep learning compilers,

    D. Xiao, Z. Liu, Y . Yuan, Q. Pang, and S. Wang, “Metamorphic testing of deep learning compilers,” Proceedings of the ACM on Measurement and Analysis of Computing Systems , vol. 6, no. 1, pp. 1–28, 2022

    2022

  35. [43]

    Nnsmith: Generating diverse and valid test cases for deep learning compilers,

    J. Liu, J. Lin, F. Ruffy, C. Tan, J. Li, A. Panda, and L. Zhang, “Nnsmith: Generating diverse and valid test cases for deep learning compilers,” in Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Vo...

    2023

  36. [44]

    Reformer: The efficient trans- former,

    N. Kitaev, Ł. Kaiser, and A. Levskaya, “Reformer: The efficient trans- former,” arXiv preprint arXiv:2001.04451 , 2020

    2001 arXiv

  37. [45]

    Minigpt-4: Enhancing vision-language understanding with advanced large language models,

    D. Zhu, J. Chen, X. Shen, X. Li, and M. Elhoseiny, “Minigpt-4: Enhancing vision-language understanding with advanced large language models,” arXiv preprint arXiv:2304.10592 , 2023

    2023 arXiv

  38. [46]

    Recent advances in natural language processing via large pre-trained language models: A survey,

    B. Min, H. Ross, E. Sulem, A. P. B. Veyseh, T. H. Nguyen, O. Sainz, E. Agirre, I. Heintz, and D. Roth, “Recent advances in natural language processing via large pre-trained language models: A survey,” ACM Computing Surveys, vol. 56, no. 2, pp. 1–40, 2023

    2023

  39. [47]

    From images to textual prompts: Zero-shot visual question answering with frozen large language models,

    J. Guo, J. Li, D. Li, A. M. H. Tiong, B. Li, D. Tao, and S. Hoi, “From images to textual prompts: Zero-shot visual question answering with frozen large language models,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition , 2023, pp. 10 867–10 877

    2023

  40. [48]

    Offsite-tuning: Transfer learning without full model,

    G. Xiao, J. Lin, and S. Han, “Offsite-tuning: Transfer learning without full model,” arXiv preprint arXiv:2302.04870 , 2023

    2023 arXiv

  41. [49]

    A survey on evaluation of large language models,

    Y . Chang, X. Wang, J. Wang, Y . Wu, L. Yang, K. Zhu, H. Chen, X. Yi, C. Wang, Y . Wang et al. , “A survey on evaluation of large language models,” ACM Transactions on Intelligent Systems and Technology , 2023

    2023

  42. [50]

    Evaluating the rationales of amateur investors,

    C.-C. Chen, H.-H. Huang, and H.-H. Chen, “Evaluating the rationales of amateur investors,” in Proceedings of the Web Conference 2021 , 2021, pp. 3987–3998

    2021

  43. [51]

    Sparks of artificial general intelligence: Early experiments with gpt-4,

    S. Bubeck, V . Chandrasekaran, R. Eldan, J. Gehrke, E. Horvitz, E. Ka- mar, P. Lee, Y . T. Lee, Y . Li, S. Lundberg et al. , “Sparks of artificial general intelligence: Early experiments with gpt-4,” arXiv preprint arXiv:2303.12712, 2023

    2023 arXiv

  44. [52]

    Free lunch for testing: Fuzzing deep-learning libraries from open source,

    A. Wei, Y . Deng, C. Yang, and L. Zhang, “Free lunch for testing: Fuzzing deep-learning libraries from open source,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 995–1007

    2022

  45. [53]

    Ruggedness and robustness testing,

    B. Dejaegher and Y . Vander Heyden, “Ruggedness and robustness testing,” Journal of chromatography A, vol. 1158, no. 1-2, pp. 138–157, 2007

    2007

  46. [54]

    Tensorfuzz: De- bugging neural networks with coverage-guided fuzzing,

    A. Odena, C. Olsson, D. Andersen, and I. Goodfellow, “Tensorfuzz: De- bugging neural networks with coverage-guided fuzzing,” inInternational Conference on Machine Learning . PMLR, 2019, pp. 4901–4911

    2019

  47. [55]

    Muffin: Testing deep learning libraries via neural architecture fuzzing,

    J. Gu, X. Luo, Y . Zhou, and X. Wang, “Muffin: Testing deep learning libraries via neural architecture fuzzing,” in Proceedings of the 44th International Conference on Software Engineering , 2022, pp. 1418– 1430

    2022

  48. [56]

    Coverage.py,

    “Coverage.py,” https://github.com/nedbat/coveragepy, 2022

    2022

  49. [57]

    Project, Using gcov with GCC 12.1 , Free Software Foundation, Boston, MA, USA, 2023

    G. Project, Using gcov with GCC 12.1 , Free Software Foundation, Boston, MA, USA, 2023. [Online]. Available: https://gcc.gnu.org/ onlinedocs/gcc-12.1.0/gcc/Gcov.html

    2023

  50. [58]

    Drone: a tool to detect and repair directive defects in java apis documentation,

    Y . Zhou, X. Yan, T. Chen, S. Panichella, and H. Gall, “Drone: a tool to detect and repair directive defects in java apis documentation,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion) . IEEE, 2019, pp. 115– 118

    2019

  51. [59]

    An empirical study of the reliability of unix utilities,

    B. P. Miller, L. Fredriksen, and B. So, “An empirical study of the reliability of unix utilities,” Communications of the ACM, vol. 33, no. 12, pp. 32–44, 1990

    1990

  52. [60]

    Sfuzz: Slice-based fuzzing for real-time op- erating systems,

    L. Chen, Q. Cai, Z. Ma, Y . Wang, H. Hu, M. Shen, Y . Liu, S. Guo, H. Duan, K. Jiang et al., “Sfuzz: Slice-based fuzzing for real-time op- erating systems,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security , 2022, pp. 485–498

    2022

  53. [61]

    Aflnet: a greybox fuzzer for network protocols,

    V .-T. Pham, M. B¨ohme, and A. Roychoudhury, “Aflnet: a greybox fuzzer for network protocols,” in 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST) . IEEE, 2020, pp. 460–465

    2020

  54. [62]

    Restler: Stateful rest api fuzzing,

    V . Atlidakis, P. Godefroid, and M. Polishchuk, “Restler: Stateful rest api fuzzing,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 748–758

    2019

  55. [63]

    Fuzzing deep-learning libraries via automated relational api inference,

    Y . Deng, C. Yang, A. Wei, and L. Zhang, “Fuzzing deep-learning libraries via automated relational api inference,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering , 2022, pp. 44– 56

    2022

  56. [64]

    Llm based input space partitioning testing for library apis,

    J. Li, Z. Dong, C. Wang, H. You, C. Zhang, Y . Liu, and X. Peng, “Llm based input space partitioning testing for library apis,” arXiv preprint arXiv:2501.05456, 2024

    2024 arXiv

  57. [65]

    Automatically generating precise oracles from structured natural language specifications,

    M. Motwani and Y . Brun, “Automatically generating precise oracles from structured natural language specifications,” in2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 188–199

    2019

Pith tools

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