---
title: Cross-Language Bugs (CLBs)
url: https://www.emergentmind.com/topics/cross-language-bugs-clbs
type: topic
---

# Cross-Language Bugs (CLBs)

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 [2606.28132][2507.21954].

## 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 [2507.21954]. 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 [2307.01970]. 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” [2303.02695].

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 [2308.03109]. 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 [2310.01803].

## 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 [2606.28132].

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 [2606.28132].

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 [2507.21954]. 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 [2404.11671]. 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 [2305.10233].

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 [2303.02695]. 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 [2606.28132].

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 [2606.28132].

The later CrossLangFuzzer formulation emphasizes seven mutation operators, each tied to a specific cross-language semantic pressure point [2606.28132]:

- **`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 [2507.06584]. 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 [2507.21954]. `MiriLLI` combines Miri with an LLVM interpreter so that Rust and foreign code can be jointly executed while preserving each side’s semantics [2404.11671]. `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 [2305.10233].

## 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 [2606.28132]. 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 [2606.28132].

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 [2507.06584]. 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 [2307.01970]. In the same study, the reopen rate for the PL combination of JavaScript and Python reached 20.66% [2307.01970].

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 [2303.02695].

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 [2305.10233]. 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 [2404.11671].

## 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 [2011.13994] |
| 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 [2004.08846][2407.17631] |
| 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, $\mu$Z, and DDlog [2402.12863] |
| 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 [2308.03109][2503.22512] |

These adjacent studies clarify the broader landscape. “Debug$^{2}$” 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 [2011.13994]. 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 [2402.12863].

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” [2004.08846]. `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 [2407.17631]. 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 [2310.01803].

## 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 [2606.28132].

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 [2307.01970]. 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 [2507.21954].

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 [2507.06584]. 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 [2507.21954]. 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 [2308.03109]. 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 [2503.22512].

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 [2606.28132]. 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 [2404.11671].

Source: https://www.emergentmind.com/topics/cross-language-bugs-clbs