This is an automated email from the ASF dual-hosted git repository. leginee pushed a commit to branch bazel-migration in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit d47b96e0acf95ed96e8a564d78ef952f1f04ed53 Author: Peter Kovacs <[email protected]> AuthorDate: Thu Aug 6 08:06:34 2026 +0200 docs(bridges): record why test_any_jni is red — a 32-bit sequence-size overflow //main/bridges:test_any_jni has been failing on this branch since it was wired, with no note anywhere saying why. Diagnosed while regression-checking the Java test work, and it is neither flaky nor a fixture problem: the bridge is wrong. jni_uno's seq_allocate() (source/jni_uno/jni_data.cxx:41) computes the buffer size as SAL_SEQUENCE_HEADER_SIZE + (nElements * nSize) in 32-BIT SIGNED arithmetic. TestSeqSize sends 5,000,000 elements of 1024 bytes: 5,120,000,000 overflows INT32_MAX and wraps to 825,032,704, which a 32-bit process cannot allocate, so rtl_mem::allocate throws "out of memory!". The test accepts a rejection only if it carries the size guard's "out of range", and that distinction is its entire purpose — today the oversized sequence is refused BY LUCK. Choose a count whose wrap lands small (4,194,304 * 1024 is exactly 2^32, wrapping to 0) and seq_allocate returns an 8-byte header, after which the loop at jni_data.cxx:1115 writes nElements elements into it — with nPos * nSize overflowing as well, so some writes land BEFORE the buffer. A heap overflow reachable from any in-process Java UNO caller. The fix already exists on the security line: 7efd38098e "jni_uno: added guard sequence allocation size against integer overflow" (security-triage, security-ASVS-Scan, ww8-fixes) computes the size in sal_uInt64, rejects negatives, and throws "sequence size out of range" above SAL_MAX_SIZE. 799ee9fa5e brought the TEST here when it unified the two bridge test sets and deliberately left the security-branch source edits behind; its own verification note reads "both test targets ANALYSE clean" — analysis, not execution. So this branch has carried the regression pin without the fix. Left red on purpose: it is an accurate report of a real defect, and this branch does not change source (CLAUDE.md). Cherry-picking 7efd38098e is ~15 lines in one file if the branch is ever to carry it. Also refreshes the surrounding table, whose "blocked on qadevOOo" and "needs a 2-process socket fixture" notes are both stale: OOoRunner.jar is built, and gtest_test grew server_args / server_ready_port for testtools:bridgetest_urp. What is left there is wiring, not missing machinery. Co-Authored-By: Claude Opus 5 <[email protected]> --- CLAUDE.md | 26 ++++++++++++++++ main/bridges/readme.md | 82 ++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 96 insertions(+), 12 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index ad0c198cff..3bb50a4efe 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -363,6 +363,32 @@ test 🔨 C++ unit-test infra runnable — NOW THE FRONT-LINE TASK: br and several qa/complex dirs (writerfilter's among them) have no makefile.mk at all, i.e. were never wired upstream either. See main/test/readme.md. + OPEN RED, LEFT RED ON PURPOSE — //main/bridges:test_any_jni. + NOT a fixture problem and NOT caused by anything above: it fails in + TestSeqSize because jni_uno's seq_allocate() computes + SAL_SEQUENCE_HEADER_SIZE + (nElements*nSize) in 32-BIT SIGNED + arithmetic (jni_data.cxx:41). 5,000,000 × 1024 = 5.12e9 wraps to + 825,032,704, which a 32-bit process cannot allocate ⇒ + BridgeRuntimeError "out of memory!", and the test only accepts a + rejection that came from a SIZE GUARD ("out of range"). That + distinction is the point: today the oversized sequence is refused BY + LUCK. Pick a count whose wrap lands small — 4,194,304 × 1024 is + exactly 2^32 ⇒ wraps to 0 — and seq_allocate returns an 8-byte header + while the loop at jni_data.cxx:1115 writes nElements elements into it + (nPos*nSize overflowing too, so some writes land BEFORE the buffer): + a heap overflow reachable from any in-process Java UNO caller. + THE FIX EXISTS ON ANOTHER BRANCH — 7efd38098e "jni_uno: added guard + sequence allocation size against integer overflow" (security-triage, + security-ASVS-Scan, ww8-fixes): size in sal_uInt64, negatives + rejected, > SAL_MAX_SIZE ⇒ "sequence size out of range". 799ee9fa5e + brought the TEST here when it unified the two bridge test sets and + deliberately left the security-branch SOURCE edits behind; its own + note says "both test targets ANALYSE clean", i.e. analysis, not + execution. So this branch holds the regression pin without the fix. + Kept red because it is an accurate report of a real defect and this + branch does not change source; cherry-picking 7efd38098e (~15 lines, + one file) is the fix if it is ever to carry it. + See main/bridges/readme.md. testtools 🔨 bridgetest GREEN 2026-08-05, ALL THREE halves — //main/testtools: bridgetest (C++ object in-process, ~1.1s), :bridgetest_java (Java object over the java_uno JNI bridge, ~1.4s) and :bridgetest_urp diff --git a/main/bridges/readme.md b/main/bridges/readme.md index 2510c902a4..091158c8fd 100644 --- a/main/bridges/readme.md +++ b/main/bridges/readme.md @@ -1,3 +1,22 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + # Notes for bridges (done) ## cpp_uno (C++↔UNO bridge) → `msci_uno.dll` @@ -60,11 +79,12 @@ calls `System.loadLibrary("java_uno")`), so there is no build-time cycle. ## Tests (`bridges/test/`) | Test | Kind | Bazel status | -|------|------|--------------| +| ---- | ---- | ------------ | | `inter_libs_exc` | single C++ process | ✅ `//main/bridges:inter_libs_exc_test` — runs & passes | -| `java_uno/any`, `…/equals`, `…/nativethreadpool` | 2-process socket URP bridge (native `uno` ↔ java) | ⬜ deferred — multi-process orchestration fixture | -| `java_uno/acquire` | same + `OOoRunner.jar` | ⬜ blocked on qadevOOo | -| `com/sun/star/lib/uno/bridges/java_remote/*` | pure-Java JUnit-via-OOoRunner | ⬜ blocked on qadevOOo | +| `java_uno/any` | in-process JVM host (`staged_java_test`) | ❌ `//main/bridges:test_any_jni` — **red on a real bridge defect, see below** | +| `java_uno/equals`, `…/nativethreadpool` | 2-process socket URP bridge (native `uno` ↔ java) | ⬜ deferred — the fixture now exists, see below | +| `java_uno/acquire` | same + `OOoRunner.jar` | ⬜ `OOoRunner.jar` is built now; needs the 2-process fixture | +| `com/sun/star/lib/uno/bridges/java_remote/*` | pure-Java JUnit-via-OOoRunner | ⬜ `OOoRunner.jar` is built now; needs wiring | | `performance` | UNO perf harness | ⬜ deferred (needs running UNO env) | | `testserver`/`testclient`/`testcomp`/`testsameprocess` | legacy CORBA-era (`com.sun.star.corba.giop`) | ⬜ likely obsolete | @@ -73,15 +93,53 @@ calls `System.loadLibrary("java_uno")`), so there is no build-time cycle. `starter.dll` (an MSVC RTTI/ABI check). `inter.exe` loads both via `osl::Module("thrower"/"starter")`, so the cc_binary target names MUST be the bare `thrower`/`starter` (the dll basenames it hard-codes). Run via the generic - `staged_run_test` (the non-gtest form of `gtest_test`'s staging rule): inter.exe - + both dlls + sal3/cppu3 + VC90 CRT are staged into one dir; the test passes iff - the exe exits 0. No UNO connection, no Java — the only test here that runs + `staged_run_test` (the non-gtest form of `gtest_test`'s staging rule): inter.exe, + both dlls, sal3/cppu3 and the VC90 CRT are staged into one dir; the test passes + iff the exe exits 0. No UNO connection, no Java — the only test here that runs without a qadevOOo / running-soffice fixture. +- **`test_any_jni` is RED, and it is the bridge that is wrong — not the test.** + It fails in `TestSeqSize`, on this line: + + ``` + TestSeqSize: oversized sequence rejected: [jni_uno bridge error] Java calling UNO method mapAny: out of memory! + TestSeqSize: rejected, but not by the size guard! + ``` + + `seq_allocate()` ([jni_data.cxx:41](source/jni_uno/jni_data.cxx)) computes the + buffer size as `SAL_SEQUENCE_HEADER_SIZE + (nElements * nSize)` in **32-bit + signed** arithmetic. The test sends 5,000,000 elements of 1024 bytes: + 5,120,000,000 overflows `INT32_MAX` and wraps to 825,032,704, which a 32-bit + process cannot allocate, so `rtl_mem::allocate` throws `"out of memory!"`. The + test accepts a rejection only if it came from a size *guard* (`"out of + range"`), and that distinction is its whole purpose: today the oversized + sequence is refused **by luck**. Choose a count whose wrap lands small — + 4,194,304 × 1024 is exactly 2³², wrapping to **0** — and `seq_allocate` + returns an 8-byte header, after which the loop at + [jni_data.cxx:1115](source/jni_uno/jni_data.cxx) writes `nElements` elements + into it (`nPos * nSize` overflowing as well, so some writes land *before* the + buffer). That is a heap overflow reachable from any in-process Java UNO caller. + + **The fix exists, on another branch**: `7efd38098e` "jni_uno: added guard + sequence allocation size against integer overflow" (on `security-triage`, + `security-ASVS-Scan`, `ww8-fixes`) computes the size in `sal_uInt64`, rejects + negatives, and throws `"sequence size out of range"` above `SAL_MAX_SIZE`. + `799ee9fa5e` brought the *test* here when it unified the two bridge test sets + and deliberately left the security-branch source edits behind — its own + verification note is "both test targets **analyse** clean", i.e. analysis, not + execution. So this branch holds the regression pin without the fix. + + Left red on purpose: it is an accurate report of a real defect, and + bazel-migration does not change source (CLAUDE.md). Cherry-picking + `7efd38098e` (~15 lines, one file) is the fix if this branch is ever to carry + it. + - **Why the rest are deferred**: the `java_uno/*` tests were *manual* harnesses upstream (each `readme.txt`: "run `…-server &`, sleep 3, run `…-client`") — the makefile only builds the components + emits run-scripts. The native `uno` - runner exists (`//main/cpputools:uno`), but automating them under `bazel test` - needs a 2-process socket fixture (port allocation, server-ready wait). - `acquire` + `java_remote` additionally need `OOoRunner.jar` from **qadevOOo**, - which is not migrated (frontier). These belong with the deferred - OfficeConnection/subsequent-test bucket. + runner exists (`//main/cpputools:uno`). Both former blockers are now GONE: + `OOoRunner.jar` is built (`//main/qadevOOo:OOoRunner`), and the 2-process + socket fixture exists — `gtest_test`/`staged_run_test` grew `server_args` + + `server_ready_port` for `//main/testtools:bridgetest_urp`, which does exactly + this (start the server detached, wait until it listens, run the client, kill + stragglers). What is left is wiring, not missing machinery. `java_remote`'s + pure-Java suites are JUnit and can use `//build/rules:junit_test.bzl`.
