| Product Version | Agent Count | User Count | Licensed To | Remaining User Months |
|---|---|---|---|---|
| 16.4.2 | 2 | 1 | ceballos technologies | 10 |
| Install Type | OS | JVM | Total Memory | Used Memory | System Date |
|---|---|---|---|---|---|
| Docker | Linux 6.12.91-fly, amd64 | OpenJDK 64-Bit Server VM 17.0.19, Ubuntu | 986 MB | 312 MB | 2026-08-08 00:33:23 +0000 |
-
This stack trace points to corrupted LOB data in the embedded HSQLDB for one (or more)
Buildrows in that project — not a general UI/API bug, and not something the 16.3 → 16.4.2 upgrade itself typically causes.What is failing
When OneDev lists or loads builds, Hibernate reads a binary column on
o_Build(o_checkoutPaths). For a bad row, HSQLDB throwsEOFExceptionwhile reading the blob, which surfaces as:- project Builds page exception
- global Builds page exception (because that list includes the bad build)
- REST
GETof that build → HTTP 500
Other projects work because their build rows are still readable. That matches what you reported after the container-image publish job.
Your host also shows only ~1 GB RAM for the OneDev container. Publishing a container image on the embedded DB with that little memory can OOM / hard-kill the process and leave HSQLDB LOB files truncated. That is a common way to get exactly this failure.
Recovery (Docker + embedded HSQLDB)
UI/API delete will also try to load the bad row, so clean it up with SQL while OneDev is stopped.
Replace
YOUR_PROJECT_PATHandYOUR_BUILD_NUMBERwith the project path and the build number that returns 500 from the REST API. Run these from the directory that contains your compose file and data volume (often./onedevor./onedev_datamounted at/opt/onedev).0. Stop and back up
docker compose down # adjust the data dir name if yours differs cp -a ./onedev "./onedev.bak-$(date +%Y%m%d%H%M%S)"1. Download SqlTool (once)
curl -fsSL -o /tmp/sqltool-2.7.1.jar \ https://repo1.maven.org/maven2/org/hsqldb/sqltool/2.7.1/sqltool-2.7.1.jar2. Resolve the build id (does not read the bad LOB)
cat > /tmp/onedev-find-build.sql <<'SQL' SELECT p.o_id AS project_id, p.o_path, b.o_id AS build_id, b.o_number, b.o_jobName FROM o_Build b JOIN o_Project p ON p.o_id = b.o_project_id WHERE p.o_path = 'YOUR_PROJECT_PATH' AND b.o_number = YOUR_BUILD_NUMBER; COMMIT; SHUTDOWN; SQL docker run --rm \ -v "$(pwd)/onedev:/data" \ -v /tmp/sqltool-2.7.1.jar:/sqltool.jar:ro \ -v /tmp/onedev-find-build.sql:/find.sql:ro \ --entrypoint bash \ 1dev/server:16.4.2 \ -c 'set -e HSQL=$(ls /app/lib/org.hsqldb.hsqldb-*.jar | head -1) echo "Using HSQLDB jar: $HSQL" java -cp "$HSQL:/sqltool.jar" org.hsqldb.cmdline.SqlTool \ --inlineRc="url=jdbc:hsqldb:file:/data/internaldb/onedev;hsqldb.tx=mvcc;hsqldb.lob_compressed=true;hsqldb.lob_file_scale=4;sql.ignore_case=true;shutdown=true,user=sa,password=" \ /find.sql'Note the
build_idfrom that output.3. Delete the bad build (keep published packages)
This removes the broken build row and its dependent rows, but keeps package records by clearing their build link first (so the published container image metadata can remain).
# set BUILD_ID from step 2 BUILD_ID=REPLACE_WITH_BUILD_ID cat > /tmp/onedev-delete-bad-build.sql <<SQL -- keep packages; only detach them from the bad build UPDATE o_Pack SET o_build_id = NULL WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_BuildLabel WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_BuildParam WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_UnitTestMetric WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_CoverageMetric WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_ProblemMetric WHERE o_build_id = ${BUILD_ID}; DELETE FROM o_BuildDependence WHERE o_dependent_id = ${BUILD_ID} OR o_dependency_id = ${BUILD_ID}; DELETE FROM o_Build WHERE o_id = ${BUILD_ID}; COMMIT; SHUTDOWN; SQL docker run --rm \ -v "$(pwd)/onedev:/data" \ -v /tmp/sqltool-2.7.1.jar:/sqltool.jar:ro \ -v /tmp/onedev-delete-bad-build.sql:/cleanup.sql:ro \ --entrypoint bash \ 1dev/server:16.4.2 \ -c 'set -e HSQL=$(ls /app/lib/org.hsqldb.hsqldb-*.jar | head -1) java -cp "$HSQL:/sqltool.jar" org.hsqldb.cmdline.SqlTool \ --inlineRc="url=jdbc:hsqldb:file:/data/internaldb/onedev;hsqldb.tx=mvcc;hsqldb.lob_compressed=true;hsqldb.lob_file_scale=4;sql.ignore_case=true;shutdown=true,user=sa,password=" \ /cleanup.sql'If your data volume directory is not named
./onedev, change the-v "$(pwd)/onedev:/data"mount accordingly (it must be the host dir that maps to/opt/onedev).4. Start again
docker compose up -dThen reopen the project Builds page and the global Builds page. If either still fails, another build row is also corrupted — repeat steps 2–3 for the next build that returns REST 500 (or tell us the project path / build numbers and we can refine the SQL).
If you have a recent DB backup
Restoring a backup taken before the bad build is also fine:
https://docs.onedev.io/administration-guide/backup-restore
Hardening (recommended)
- Give the OneDev container more memory (2 GB+ is much safer when building/publishing images).
- For production, use an external database (PostgreSQL/MySQL) instead of embedded HSQLDB — see
conf/hibernate.properties/ the Docker Compose example that ships with OneDev. - Enable periodic database backup under Administration → Database Backup.
Please reply with whether the Builds pages load again after deleting the bad build, or paste the SqlTool output if something fails. If this resolves it, we can close the issue.
-
Previous Value Current Value Open
Closed
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
-
onedev.io
External participants do not have accounts and involve in the issue via email