Cross-Language Bugs (CLBs)
- Cross-language bugs (CLBs) are defects that occur at the interface of two programming languages, often due to type, declaration, or metadata mismatches.
- Detection methodologies such as differential testing and tools like CrossLangFuzzer generate unified IR programs to expose compiler inconsistencies across language boundaries.
- Empirical studies show that CLBs are prevalent in multi-language projects, leading to higher maintenance costs and potential security vulnerabilities.
Cross-language bugs (CLBs) are defects that arise not inside one programming language alone, but at the boundary where two languages interact through a shared runtime, a foreign-function interface, a bridge mechanism, or a cross-compiler pipeline. In the JVM setting, a CLB is a compiler defect that only appears when a program crosses a language boundary, typically when one language compiler misinterprets or mishandles declarations, types, or inheritance information originating from another JVM language. More broadly, recent work distinguishes CLBs from broader multilingual bugs by requiring direct interaction between languages rather than merely multi-language edits, and it emphasizes that CLBs are difficult to detect by single-language bug detection tools (Ma et al., 26 Jun 2026, Li et al., 29 Jul 2025).
1. Definitions and operational boundaries
The term cross-language bug is used most precisely when the fault is rooted in the interaction itself. One recent CLB study states that a multilingual bug may require edits in multiple languages, but the languages do not necessarily interact directly, whereas a CLB specifically involves direct interaction between languages through a mechanism such as JNI, ctypes, or similar bridges (Li et al., 29 Jul 2025). This distinction separates boundary-induced defects from broader multi-language maintenance phenomena.
Several adjacent literatures use broader operationalizations. In Apache projects, a multi-programming-language bug (MPLB) is defined commit-wise: a bug is an MPLB if it is resolved in one or more commits and at least one of those commits is an MPL commit that modifies source files in multiple programming languages, or if it is resolved in multiple single-PL commits involving different programming languages (Li et al., 2023). This definition is highly relevant to CLBs, but it does not require that the root cause be a semantic mismatch across a language boundary. A similar operationalization appears in deep learning frameworks, where an MPL fix is a pull request involving source files in multiple programming languages; that study explicitly notes that one code-bug subtype includes “problems in cross-programming-language communication” (Li et al., 2023).
Another important subclass is the translation bug. In code-translation research, a translation bug is operationalized by failure to preserve behavior after translation, observed via compilation errors, runtime errors, functional errors, or non-terminating execution (Pan et al., 2023). These are CLBs in a strict sense because the defect is introduced by crossing from one language to another. By contrast, some cross-lingual bug-localization studies address language mismatch in bug reports and source artifacts rather than semantic interaction between executable components; these works are adjacent to CLBs, but their primary object is retrieval effectiveness under language mismatch rather than runtime or compiler misbehavior (Hayashi et al., 2023).
2. Semantic fault lines at language boundaries
The canonical CLB setting is one in which languages share a platform but not a single semantic model. On the JVM, Java, Kotlin, Groovy, and Scala differ in generic type systems, declaration-site variance, nullability, raw types, platform types, inheritance rules, and method dispatch or override semantics. A compiler consuming foreign-language bytecode or source must reconstruct semantic intent from metadata that may be incomplete or encoded differently. The resulting failures include rejecting a valid program, accepting an invalid one, inferring the wrong type, or failing to resolve an override (Ma et al., 26 Jun 2026).
A representative example is Kotlin’s handling of Java raw types. A Java class hierarchy using a raw List in an override is valid, but Kotlin can reject a downstream Kotlin subclass because it treats the raw type as a wildcard-like form that no longer matches the generic signature it expects. The defect is not visible in purely intra-language testing; it emerges only when Kotlin consumes Java-originated type information (Ma et al., 26 Jun 2026).
Outside the JVM, the same structural problem appears under different semantic pressures. In CLB detection with CodeLMs, the central boundary mechanisms are data conversion, memory ownership, exception propagation, control transfer, and API usage between languages. In practice, a Python or Java function may look correct in isolation, but still be buggy because of how it calls into C/C++ code, receives return values, or passes objects across the boundary (Li et al., 29 Jul 2025). In Rust FFI, interoperating languages allow design patterns that conflict with Rust’s evolving aliasing models, producing ownership and aliasing bugs, allocation bugs, and typing or initialization bugs across foreign-function boundaries (McCormack et al., 2024). In Android applications written in Java and C/C++, the source is on the Java side and the sink is on the native side: a Java-originated value can flow through JNI and trigger a native buffer overflow, making the vulnerability a cross-language data-flow problem rather than a purely native bug (Thangarajah et al., 2023).
Deep learning frameworks provide another recurrent fault line. In MXNet, PyTorch, and TensorFlow, the dominant PL combination in MPL fixes is Python and C/C++, accounting for more than 92% of MPL bug fixes in all selected frameworks (Li et al., 2023). This suggests that CLBs are especially likely where a high-level front end and a performance-critical back end must agree on representation, control, and memory discipline.
3. Detection methodologies
A major recent development is differential testing designed specifically for cross-language compilation. “CrossLangFuzzer” is presented as the first differential testing framework for cross-language JVM compilation. Its central idea is to generate programs in a unified intermediate representation rather than directly in source syntax, so that the fuzzer can construct semantically rich cross-language hierarchies without being tied to any one language’s syntax. The IR is inspired by Kotlin compiler backend IR, but implemented independently as a language-neutral model. It represents a program as a tree of declarations, where each class carries a target-language tag, inheritance information (extends/implements), optional type parameters, and member functions. Its type system explicitly models simple types, parameterized types, nullable types, platform types (with !), and type parameters with optional bounds (Ma et al., 26 Jun 2026).
The generation workflow is described as “valid by construction.” The generator synthesizes an initial IR program while enforcing semantic constraints so the resulting hierarchy respects JVM inheritance rules. The mutator then deliberately perturbs the program without rechecking semantic well-typedness. The runner supports two modes: NormalTest, which looks for crashes or internal errors in a single compiler, and DifferentialTest, which compares behaviors across compiler versions or across compilers to detect mismatches. When a candidate bug is found, the tool applies Delta Debugging Minimization (DDMin): the program is serialized back into IR, minimized with an optimized reducer, reprinted into source code, rerun, and retained only if the failure still reproduces (Ma et al., 26 Jun 2026).
The later CrossLangFuzzer formulation emphasizes seven mutation operators, each tied to a specific cross-language semantic pressure point (Ma et al., 26 Jun 2026):
mutateGenericArgumentInParent: changes the type argument of a superclass or interface.mutateGenericArgumentInMemberFunctionParameter: changes nested type arguments in parameter types.mutateClassTypeParameterUpperBound: replaces a class type parameter’s upper bound with a different type.mutateParameterNullability: flips a function parameter between nullable and non-nullable.mutateClassTypeParameterUpperBoundNullability: toggles whether a type parameter’s upper bound admits nulls.removeOverrideMemberFunction: strips an overridden method body while preserving its signature.shuffleLanguage: reassigns the target language of IR classes while preserving the structure.
An earlier CrossLangFuzzer paper reported a related architecture based on a universal IR, universal override rules, and three mutation techniques—LangShuffler, FunctionRemoval, and TypeChanger—again coupled with differential testing across compiler versions (Feng et al., 9 Jul 2025). The methodological continuity across the two papers is that CLB discovery depends on generating programs whose semantics are determined by how one compiler interprets declarations emitted by another.
Other CLB detection methods target different boundaries. CLCFinder identifies cross-language code involving three PL combinations—Python-C/C++, Java-C/C++, and Python-Java—and nine interaction mechanisms, and the resulting dataset is used to fine-tune 13 CodeLMs for CLB detection (Li et al., 29 Jul 2025). MiriLLI combines Miri with an LLVM interpreter so that Rust and foreign code can be jointly executed while preserving each side’s semantics (McCormack et al., 2024). PilaiPidi converts Java and C/C++ source code into a shared XML-based AST using srcML, performs forward program slicing, constructs a unified data-flow graph across JNI, and searches source-to-sink paths ending in native buffer-sensitive operations (Thangarajah et al., 2023).
4. Empirical findings across domains
The empirical evidence indicates that CLBs are neither rare nor confined to experimental toolchains. In the most recent CrossLangFuzzer evaluation, the framework was tested on the latest actively maintained versions of five major JVM compilers—Kotlin (kotlinc), Groovy (groovyc), Scala 2 (scala2c), Scala 3 (scala3c), and Java (javac)—and uncovered 32 confirmed bugs: 15 in Kotlin, 4 in Groovy, 7 in Scala 3, 2 in Scala 2, and 4 in Java. The bugs were all validated by the corresponding compiler teams. All four Groovy bugs were fixed, one Kotlin bug was already patched, and the remaining 14 Kotlin bugs were confirmed and awaiting fixes at the time of writing (Ma et al., 26 Jun 2026). The paper associates these bugs with incorrect handling of generic arguments and bounds across imported hierarchies, nullability mismatches, raw types and platform types, variance and bound checking, and overridden member resolution (Ma et al., 26 Jun 2026).
The earlier CrossLangFuzzer study reported 24 confirmed bugs across the same compiler family—10 in Kotlin, 4 in Groovy, 7 in Scala 3, 2 in Scala 2, and 1 in Java—and found TypeChanger to be the most effective mutator, detecting 11 of the 24 compiler bugs (Feng et al., 9 Jul 2025). Taken together, the two studies indicate that cross-language compiler testing yields confirmed defects even in mature production compilers.
Empirical software-engineering studies show that multi-language bug resolution is common and comparatively costly. In 54 Apache multi-programming-language projects, 66,932 bugs were analyzed and 6,700 MPLBs were found, yielding an overall proportion of 10.01%. Of these MPLBs, 95.07% involved 2 programming languages and 4.51% involved 3 programming languages. Relative to single-programming-language bugs, MPLB resolution had higher median change complexity and open time: LOCM 110 vs 30, NOFM 5 vs 2, NODM 3 vs 2, OT 9.46 vs 4.27 days, Entropy 0.92 vs 0.84, and reopen rate 0.065 vs 0.056 (Li et al., 2023). In the same study, the reopen rate for the PL combination of JavaScript and Python reached 20.66% (Li et al., 2023).
Deep learning frameworks display a similarly strong multi-language signature. After manual analysis of 1,497 bugs in MXNet, PyTorch, and TensorFlow, MPL bugs accounted for 28.6% of bugs in MXNet, 31.4% in PyTorch, and 16.0% in TensorFlow. In more than 92% of MPL bug fixes across all selected frameworks, the PL combination was Python and C/C++, and the code change complexity of MPL bug fixes was significantly greater than that of single-programming-language bug fixes in all three frameworks (Li et al., 2023).
Security-oriented analyses find equally concrete cross-language failures. In six well-known Android applications, PilaiPidi detected 23 buffer overflow vulnerabilities of cross-language nature, and developers confirmed 11 vulnerabilities in three applications (Thangarajah et al., 2023). In Rust libraries that call foreign functions, a joint Rust/LLVM interpretation approach found 46 instances of undefined or undesired behavior in 37 libraries; three bugs were found in libraries that had more than 10,000 daily downloads on average during the observation period, and one was found in a library maintained by the Rust Project (McCormack et al., 2024).
5. Adjacent research areas and supporting infrastructures
CLB research intersects with several neighboring fields that do not always use the same terminology but study analogous boundary failures.
| Research line | Operational focus | Representative result |
|---|---|---|
| Debug-information consistency | Differential comparison of optimized and unoptimized debugger traces using toolchain- and programming language-agnostic invariants | 23 bugs in the LLVM toolchain, 8 in the GNU toolchain, and 3 in the Rust toolchain (Luna et al., 2020) |
| Cross-language and cross-project bug localization | Multi-language datasets and retrieval models for ranking buggy files from bug reports | BuGL contains 10,187 bugs/issues closed by pull requests across 54 projects in C, C++, Java, and Python; BEETLEBOX contains 26,321 bugs from 29 projects across Java, C++, Python, Go, and JavaScript (Muvva et al., 2020, Chakraborty et al., 2024) |
| Cross-boundary semantic mismatch outside PL interoperability | Optimized-versus-de-optimized comparison across Datalog rules | Deopt discovered a total of 30 bugs, including 13 logic bugs, in Soufflé, CozoDB, Z, and DDlog (Zhang et al., 2024) |
| LLM-mediated translation and repair | Translation bugs and translation-assisted repair across languages | Correct translations ranged from 2.1% to 47.3%; Rust showed a 22.09% improvement in Pass@10 via translation-based repair (Pan et al., 2023, Luo et al., 28 Mar 2025) |
These adjacent studies clarify the broader landscape. “Debug” is not directly about CLBs in the usual language-interoperability sense, but it demonstrates that generic cross-toolchain and cross-language invariants can expose real bugs in LLVM, GNU, and Rust debugging pipelines (Luna et al., 2020). The Datalog work on cross-rule optimization bugs explicitly presents its target as analogous to semantic cross-boundary mismatch bugs, even though the boundary is between logical specification and optimized execution rather than between source languages (Zhang et al., 2024).
Bug-localization infrastructures also matter because they provide the data needed for CLB-related studies. BuGL was created to enable questions such as “Finding similarity between bugs occurring in different programming languages” and “Analysing use of bug data on from projects in one programming language in facilitating bug localization for projects written in a different programming language” (Muvva et al., 2020). BLAZE addresses cross-project and cross-language bug localization with dynamic chunking and hard example learning, while BEETLEBOX broadens the evaluation space to five languages (Chakraborty et al., 2024). In industrial cross-lingual bug localization, translating Japanese comments and string literals in source files as well as translating bug reports improved retrieval; in one reported case, an oracle file rank improved from 91st to 11th after source-side translation (Hayashi et al., 2023).
6. Conceptual lessons, misconceptions, and open issues
A persistent misconception is that per-language correctness is sufficient in a multi-language ecosystem. The compiler literature directly rejects this view: compilers in multilingual JVM applications are not only translating source to bytecode, but also interpreting foreign-language declarations, inheritance chains, type arguments, nullability annotations, platform types, and override relationships produced by other compilers. Existing compiler testing has historically been too “single-language minded,” and small semantic mismatches can lead to invalid rejections, incorrect acceptance, or subtle bytecode miscompilations that are very hard to diagnose without cross-language test generation (Ma et al., 26 Jun 2026).
A second misconception is that every multi-language bug is a CLB. The literature is more careful. MPLBs in Apache projects are defined by multi-language resolution activity, not necessarily by direct semantic interaction (Li et al., 2023). In CLB detection with CodeLMs, the distinction is made explicit: multilingual bugs may require edits in multiple languages without direct interaction, whereas CLBs specifically involve direct interaction through a bridge or interface (Li et al., 29 Jul 2025).
A third lesson concerns responsibility attribution. In cross-language compiler bugs, one study introduces the distinction between the provider language, which defines the referenced class or interface, and the user language, which consumes or extends it. Among 17 cross-language trigger programs, 9 bugs were confirmed on the user side, 5 on the provider side, and 3 were too complex to classify cleanly as either (Feng et al., 9 Jul 2025). This indicates that the consuming compiler often bears the burden of reconciling foreign-language constructs.
The current evidence also shows that CLBs are not reducible to ordinary single-language bug patterns. Models fine-tuned on single-language bug datasets performed poorly on CLB detection, which is used to argue that CLBs and single-language bugs have significantly different feature characteristics (Li et al., 29 Jul 2025). In code translation, even the strongest studied LLMs remained unreliable, with correct translations ranging from 2.1% to 47.3% and a taxonomy of 15 translation bug categories spanning syntax, API behavior, operators, data types, parsing, logic removal, and model-specific failures (Pan et al., 2023). Yet cross-language transformation is not only a source of bugs; it can also be a repair strategy. LANTERN leverages cross-language translation and multi-agent refinement, and on xCodeEval it reported that Rust showed a 22.09% improvement in Pass@10 metrics (Luo et al., 28 Mar 2025).
The general implication is methodological as much as technical. CLB-oriented testing should not merely generate more programs; it should generate programs whose semantics depend on how one compiler, runtime, analyzer, or repair system interprets declarations or behaviors produced by another (Ma et al., 26 Jun 2026). A plausible implication is that future CLB research will increasingly combine IR-centered generation, differential testing, dynamic multi-language execution, and learned models specialized for cross-boundary signals rather than reusing single-language tools unchanged. The Rust FFI work states the point in ecosystem terms: the community must invest in new, production-ready tooling for multi-language applications to ensure that developers can detect these errors (McCormack et al., 2024).