Deploy DIVINE to Europe — Jiří Barnat 🇨🇿 (Masaryk University Brno), the Concurrent C/C++ Model Checker from the Czech Republic, on EU Infrastructure in 2026

In 2018, an automotive tier-1 supplier delivering a C++ AUTOSAR stack for an ISO 26262 ASIL D embedded controller needed to certify that no thread interleaving in their concurrent interrupt service routines could lead to a data race or deadlock. Standard testing — even with ThreadSanitizer enabled — could not exhaustively cover all possible thread schedules. The number of possible interleavings of four threads executing 200 instructions each is astronomically large. ThreadSanitizer observes one execution at a time; it cannot guarantee that the specific failing interleaving will manifest in any finite test run.

The answer was a model checker: a tool that does not sample executions but systematically enumerates all possible thread schedules, checking each one for violations. The tool the team used was DIVINE.

DIVINE is an explicit-state model checker for concurrent C and C++ programs. It takes your C/C++ source code, compiles it through LLVM, and exhaustively explores all reachable states of all thread interleavings, checking for deadlocks, data races, assertion violations, memory safety errors, and user-specified LTL safety and liveness properties. Where testing scales with the number of test runs, model checking scales with the number of reachable states — and DIVINE applies state compression and partial-order reduction to make that enumeration tractable for realistic concurrent programs.

DIVINE is built and maintained at the ParaDiSe laboratory (Parallel and Distributed Systems) at Masaryk University Brno 🇨🇿 — the second oldest university in the Czech Republic (founded 1919), located in Brno, the industrial heart of Moravia. The Czech Republic has been an EU member since 2004. DIVINE participates in SV-COMP (Software Verification Competition), the annual European benchmarking competition organized under ETAPS, in the ConcurrencySafety, ReachSafety, and MemSafety categories.

Jiří Barnat, Luboš Brim, and the ParaDiSe Laboratory

Jiří Barnat 🇨🇿 is the primary architect of the DIVINE model checker and a researcher at the Faculty of Informatics, Masaryk University Brno. His research focuses on explicit-state model checking, distributed model checking algorithms, LTL verification, and weak memory model analysis. Barnat developed DIVINE from its first distributed LTL-model-checking prototype through to DIVINE 4, the LLVM-based C/C++ verifier now used for industrial concurrent software verification.

Luboš Brim 🇨🇿 is a professor at the Faculty of Informatics, Masaryk University, and the PI of the ParaDiSe group. Brim's research spans concurrent and distributed systems verification, timed automata, probabilistic model checking, and parameter synthesis. He co-authored the foundational DIVINE papers and leads the group's engagement with European research funding, including projects under the Czech Science Foundation (GAČR) and Horizon Europe.

Petr Ročkai 🇨🇿 led the architecture of DIVINE 4, the major redesign that replaced DIVINE's proprietary input language with a full LLVM frontend, enabling direct analysis of C and C++ programs compiled by Clang. Ročkai designed DIVINE's DiVM (Divine Virtual Machine) — the virtual machine that interprets LLVM IR under DIVINE's model-checking semantics — which is the core innovation that makes DIVINE 4's C/C++ analysis tractable.

The ParaDiSe laboratory's work on distributed model checking — running the state-space exploration across a cluster of machines using MPI — was a significant contribution of DIVINE 2 and 3 (2008–2016). This distributed approach allowed DIVINE to handle state spaces too large for a single machine, addressing one of the fundamental scalability challenges in explicit-state model checking. DIVINE 4 refocused on single-machine C/C++ analysis via LLVM, but the distributed infrastructure remains available for large-scale industrial verification tasks.

DIVINE's papers have been published regularly at TACAS (Tools and Algorithms for Construction and Analysis of Systems), the flagship European tools venue within ETAPS, and at CAV (Computer Aided Verification), the premier international conference in the field. The tool has been a consistent SV-COMP participant since the competition's early editions.

How DIVINE Works: Explicit-State Model Checking via LLVM

DIVINE 4's verification pipeline consists of five stages:

Stage 1 — Compilation. DIVINE uses Clang to compile the C/C++ source to LLVM IR (bitcode). DIVINE ships a modified standard library (DiOS — Divine Operating System) and a modified POSIX threading layer (DiOS POSIX) that replace the real operating system with a model-checking-aware environment. DiOS intercepts pthread_create, pthread_mutex_lock, sem_wait, malloc, free, and all other system interactions and replaces them with DIVINE-instrumented equivalents that allow the model checker to control execution and track state.

# Compile a concurrent C program for DIVINE analysis
divine compile --llvm -o program.bc program.c -lpthread

Stage 2 — State representation. DIVINE represents the program state as a snapshot of the entire execution: the contents of all memory (heap and stack for each thread), the program counters of all threads, and the current values of all mutexes, semaphores, and condition variables. States are stored in a compressed hash table. DIVINE uses tau-reduction (a form of partial-order reduction tailored to LLVM instructions) to avoid redundantly re-exploring states that differ only in the order of independent internal computations — this dramatically reduces the state space for programs with many local computations between synchronisation points.

Stage 3 — State-space exploration. DIVINE's exploration engine implements nested depth-first search (NDFS) for LTL model checking, and a straightforward BFS/DFS for safety properties. At each state, DIVINE enumerates all enabled thread transitions (threads that are not blocked on a mutex, semaphore, join, or sleep) and creates a successor state for each. The scheduler is not the real OS scheduler — DIVINE controls scheduling explicitly to explore all interleavings, not just those that would occur under a specific OS scheduler.

Stage 4 — Property checking. DIVINE checks the following properties in every explored state:

• Deadlock freedom: no state where all threads are blocked with no thread able to make progress
• Data race detection: concurrent unsynchronised accesses to shared memory where at least one is a write (DIVINE uses happens-before analysis at the LLVM IR level)
• Memory safety: invalid memory accesses (null pointer, use-after-free, out-of-bounds), double-free, memory leaks
• Assertion violations: assert() failures and C++ exceptions not caught by the harness
• LTL properties: user-specified linear temporal logic formulae over program state predicates (via Büchi automaton product with the state space)

Stage 5 — Counterexample output. When DIVINE finds a property violation, it produces a counterexample trace: a complete description of the thread interleaving, the sequence of instructions executed by each thread, and the memory state at the point of the violation. The trace is fully reproducible — it specifies exactly which thread ran which instruction in which order, making the bug deterministic and debuggable.

# Run DIVINE verification with a safety property
divine verify --report program.bc

# Check with LTL property (no starvation)
divine verify --ltl "G (waiting -> F critical)" program.bc

# Output: counterexample trace if violation found

DIVINE and Weak Memory Models

Modern multiprocessor hardware does not guarantee sequential consistency. On x86 processors, the Total Store Order (TSO) memory model allows stores to be buffered in per-processor store buffers, making them temporarily invisible to other processors. On ARM and POWER architectures, reordering is even more permissive. A concurrent program that appears correct under sequential consistency (the idealized model where all memory accesses are instantaneously visible to all processors) can exhibit bugs under the weaker guarantees of real hardware.

DIVINE 4 includes a weak memory model module that extends the exploration to include TSO-induced store buffer states. Under this mode, DIVINE explores not just the thread interleavings but also the non-determinism introduced by the store buffer: when a thread writes to memory, the write may or may not be immediately visible to other threads (depending on whether the store buffer has been flushed). This analysis finds bugs that would be invisible to a verifier that assumes sequential consistency but can manifest on real x86 hardware.

// This program is safe under SC but can fail under TSO:
int x = 0, y = 0;

// Thread 1:
x = 1;
int r1 = y;  // may read 0 if y's store is still in T2's buffer

// Thread 2:
y = 1;
int r2 = x;  // may read 0 if x's store is still in T1's buffer

// Under TSO: r1 == 0 && r2 == 0 is possible — DIVINE detects this

This capability is directly relevant to EU automotive safety standards. ISO 26262 ASIL D and IEC 62443-4-1 both require that concurrent safety-critical software behave correctly on the actual target hardware architecture, not just under an idealized memory model. DIVINE's TSO analysis provides evidence that a concurrent C/C++ program is correct under the memory model of the deployment architecture.

EU Industrial Context: Czech Republic as Verification Hub

The Czech Republic 🇨🇿 occupies a distinctive position in European industrial software. Brno — where Masaryk University is located — is one of the largest technology clusters in Central Europe:

Automotive: The Czech Republic is the highest per-capita automobile producer in the world. Škoda Auto (VW Group 🇩🇪) headquartered in Mladá Boleslav develops safety-critical embedded software for ADAS systems under ISO 26262 ASIL D. Continental operates a major R&D center in Prague (Continental Barum in Otrokovice). Bosch has a significant Czech engineering presence. All of these firms require formal verification evidence for their concurrent embedded C/C++ software stacks.

Aerospace: Aero Vodochody 🇨🇿 (now part of Aero Holding, with ties to Leonardo DRS) manufactures military aircraft. Boeing Research & Technology Europe operates a center in Prague. Honeywell Aerospace has a major Brno presence focused on avionics software — avionics software certified to DO-178C DAL A requires evidence of correct concurrent behaviour, and DIVINE provides the formal analysis layer.

Industrial Control: ABB and Siemens both operate significant Czech engineering centers. IEC 62443-4-1 (Secure Development Lifecycle for industrial automation systems) requires formal analysis of concurrent state machines in PLC and DCS firmware — DIVINE provides this analysis for C/C++ implementations.

ICT and Cybersecurity: Red Hat Czech (Brno is Red Hat's largest R&D site outside the US) develops concurrent Linux kernel and OpenShift infrastructure code. Kiwi.com and the Czech startup ecosystem contribute to the pool of engineering talent at Masaryk University's ParaDiSe lab.

DIVINE's creation at Masaryk University Brno reflects a deliberate research strategy: build a formal verification tool that is directly applicable to the concurrent embedded software challenges of the Czech industrial economy, and validate it on the international SV-COMP stage alongside the leading European tools from LMU Munich (CPAchecker), University of Freiburg (UltimateAutomizer), and University of Oxford (CBMC).

SV-COMP: DIVINE in the European Verification Ecosystem

The Software Verification Competition (SV-COMP), organized annually under ETAPS (European Joint Conferences on Theory and Practice of Software) since 2012, is the definitive benchmark for automated software verification tools. SV-COMP evaluates tools on thousands of C and C++ programs across multiple categories:

• ConcurrencySafety: concurrent programs with pthreads and C11 threads — DIVINE's primary strength
• ReachSafety: assertion reachability in sequential and concurrent programs
• MemSafety: memory safety (null dereference, buffer overflow, use-after-free)
• Termination, NoOverflow, SoftwareSystems: broader categories

DIVINE consistently performs strongly in ConcurrencySafety — the category where most other tools (which focus primarily on sequential programs or use abstract interpretation rather than explicit-state enumeration) have limited applicability. The explicit-state approach that makes DIVINE slower on large sequential programs makes it more precise on concurrent programs: DIVINE explores actual thread interleavings rather than computing an overapproximation of concurrent behaviour.

The EU SV-COMP ecosystem illustrates the depth of European formal verification research:

No US-originated tool dominates this landscape. European universities — funded by national research councils and the EU Framework programmes — have built the tools that define the state of the art in automated software verification.

Regulatory Compliance Evidence with DIVINE

ISO 26262 ASIL D (Automotive Safety): DIVINE's exhaustive concurrent state-space exploration provides evidence that a C/C++ embedded software component has no deadlocks, data races, or assertion violations under any thread interleaving — a requirement for software with safety integrity level ASIL D. Czech automotive suppliers delivering to Škoda/VW, Continental, and Bosch use DIVINE analysis as part of their ISO 26262 Functional Safety Management documentation.

IEC 61508 SIL 3/4 (Generic Safety-Critical Systems): IEC 61508 requires "systematic analysis of race conditions and deadlocks" for concurrent SIL 3/4 software. DIVINE's counterexample traces provide the auditable evidence of exhaustive concurrent state-space exploration required by the standard's Table A.6 (formal methods) and Table A.7 (dynamic analysis and testing — model checking satisfies the "structural test coverage" requirement for concurrent programs).

IEC 62443-4-1 (Industrial Automation Security): Concurrent control system firmware in PLCs and DCS systems must be verified for correct synchronisation — a deadlock in a safety controller can result in a loss of process control with severe consequences. DIVINE provides the formal verification evidence for the SR 3.3 (System Integrity) and SR 3.4 (Software and Information Integrity) requirements.

EU AI Act Art. 9 (Risk Management for High-Risk AI): Embedded AI inference engines running concurrent neural network inference threads (e.g., AUTOSAR Adaptive Platform with multiple AI tasks) are subject to Art. 9's risk management requirements. DIVINE's concurrent analysis — verifying that no thread interleaving leads to assertion violations in the inference pipeline — provides machine-readable verification evidence for Art. 9(5)(b) compliance.

CRA 2027 (Cyber Resilience Act): CWE-362 (Race Condition enabling Link Following) and CWE-820 (Missing Synchronization) are data race vulnerabilities that appear in concurrent C/C++ network software. DIVINE's exhaustive race detection provides formal evidence of CWE-362/CWE-820 absence — relevant for IoT devices, industrial controllers, and connected software products subject to CRA.

Deploying DIVINE on EU Infrastructure with sota.io

DIVINE is a command-line tool that runs verification workloads locally or as CI/CD steps. For teams that need to run large-scale verification as a service — across multiple projects, with centralised reporting — deploying DIVINE on EU infrastructure via sota.io provides GDPR-compliant, German-hosted compute with zero DevOps overhead.

Why EU infrastructure matters for DIVINE workloads:

DIVINE analysis requires access to your C/C++ source code. That source code may be:

• Automotive ASIL D software: subject to export control and confidentiality agreements with OEMs
• Industrial control firmware: covered by trade secret protections under EU Directive 2016/943
• Aerospace avionics code: subject to ITAR/EAR export control and EU equivalent regulations
• Medical device software: subject to MDR 2017/745 and GDPR data processing requirements

Running DIVINE on sota.io — hosted on German infrastructure, operating under German law, subject only to EU data protection regulation and not the US Cloud Act — ensures that your source code and verification results remain under EU jurisdiction.

FROM ubuntu:24.04

RUN apt-get update && apt-get install -y \
    cmake ninja-build clang-18 llvm-18 \
    libboost-dev zlib1g-dev libz3-dev \
    git python3 python3-pip

WORKDIR /opt
RUN git clone --depth 1 https://github.com/paradise-fi/divine.git
WORKDIR /opt/divine/build
RUN cmake .. -GNinja -DCMAKE_BUILD_TYPE=Release && ninja divine

ENV PATH="/opt/divine/build:${PATH}"

WORKDIR /workspace

# docker-compose.yml for sota.io deployment
version: "3.8"
services:
  divine-verifier:
    build: .
    volumes:
      - ./src:/workspace/src
      - ./reports:/workspace/reports
    command: >
      sh -c "
        divine compile --llvm -o /workspace/program.bc /workspace/src/main.c &&
        divine verify --report=/workspace/reports/divine-report.json /workspace/program.bc
      "
    environment:
      - DIVINE_JOBS=4  # parallel state-space exploration threads

# GitHub Actions CI integration
name: DIVINE Verification

on: [push, pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and run DIVINE
        run: |
          docker build -t divine-verifier .
          docker run --rm \
            -v ${{ github.workspace }}/src:/workspace/src \
            -v ${{ github.workspace }}/reports:/workspace/reports \
            divine-verifier
      - name: Upload verification report
        uses: actions/upload-artifact@v4
        with:
          name: divine-report
          path: reports/divine-report.json

sota.io deployment (free tier, German infrastructure):

# Deploy to sota.io — EU-native PaaS
sota deploy --project divine-verifier --region eu-central-1

Verification workloads run on German servers under EU data protection law. No US Cloud Act jurisdiction. GDPR-compliant by infrastructure design — Article 25 Privacy by Design satisfied at the infrastructure layer.

Getting Started with DIVINE

DIVINE is open-source (ISC licence), hosted at github.com/paradise-fi/divine. The ParaDiSe laboratory maintains active development and responds to issues.

SV-COMP Docker image (quickest start):

# Run DIVINE from the official SV-COMP image
docker pull paradise/divine
docker run --rm -v $PWD:/mnt paradise/divine verify /mnt/program.c

# Check for memory safety
docker run --rm -v $PWD:/mnt paradise/divine verify --msan /mnt/program.c

# Check LTL property
docker run --rm -v $PWD:/mnt paradise/divine verify \
  --ltl "G (mutex_held -> F mutex_released)" /mnt/program.c

Build from source:

git clone https://github.com/paradise-fi/divine.git
cd divine && mkdir build && cd build
cmake .. -GNinja -DCMAKE_BUILD_TYPE=Release
ninja divine divine-cc  # divine-cc = drop-in compiler wrapper

Write a verification harness for a concurrent data structure:

#include <pthread.h>
#include <assert.h>
#include <divine/dios/api.h>  // DIVINE-specific: __dios_choice()

int shared_counter = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

void *increment(void *arg) {
    for (int i = 0; i < 3; i++) {
        pthread_mutex_lock(&lock);
        shared_counter++;
        pthread_mutex_unlock(&lock);
    }
    return NULL;
}

int main() {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, increment, NULL);
    pthread_create(&t2, NULL, increment, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    // DIVINE verifies this holds for ALL interleavings:
    assert(shared_counter == 6);
    return 0;
}

DIVINE will enumerate all interleavings of t1 and t2, verifying that shared_counter == 6 holds in every possible execution — something no finite number of test runs can guarantee.

See Also

• Deploy CPAchecker to Europe → — Dirk Beyer 🇩🇪 (LMU Munich), configurable program analysis framework
• Deploy UltimateAutomizer to Europe → — Heizmann + Podelski 🇩🇪 (Uni Freiburg), trace abstraction
• Deploy CBMC to Europe → — Daniel Kroening 🇩🇪 (Oxford), C bounded model checker
• Deploy 2LS to Europe → — Kroening group (Oxford), two-level lattice solver
• Deploy SPIN/Promela to Europe → — Gerard Holzmann 🇳🇱 (JPL/Bell Labs), the original concurrent model checker
• Deploy to Europe: All 167 Programming Languages →