libgomp dynamic and guided OpenMP schedules segfault on the riscv64 runners

Summary

On the ubuntu-24.04-riscv runners, libgomp's dynamic and guided work-share schedules fault. A 40-line C program that allocates nothing in the loop body segfaults 3 times out of 3; schedule(static) on the same program is clean. This is independent of LightGBM, of the compiler version and of the container.

Any riscv64 wheel we publish whose extension uses #pragma omp parallel for schedule(dynamic) or schedule(guided) is exposed at runtime.

Reproducer

#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static long calc_body(int i) { return (long)i * 3 % 7; }

int main(int argc, char **argv) {
  const char *kind = argc > 1 ? argv[1] : "guided";
  int rounds = argc > 2 ? atoi(argv[2]) : 100000;
  int n = argc > 3 ? atoi(argv[3]) : 300;
  int nthreads = omp_get_max_threads();
  long total = 0;
  for (int r = 0; r < rounds; r++) {
    long s = 0;
    if (!strcmp(kind, "guided")) {
#pragma omp parallel for num_threads(nthreads) schedule(guided) reduction(+ : s)
      for (int i = 0; i < n; i++) s += calc_body(i);
    } else if (!strcmp(kind, "dynamic")) {
#pragma omp parallel for num_threads(nthreads) schedule(dynamic) reduction(+ : s)
      for (int i = 0; i < n; i++) s += calc_body(i);
    } else {
#pragma omp parallel for num_threads(nthreads) schedule(static) reduction(+ : s)
      for (int i = 0; i < n; i++) s += calc_body(i);
    }
    total += s;
  }
  printf("OK %s %ld\n", kind, total);
  return 0;
}

gcc -O2 -fopenmp -o probe probe.c && ./probe guided 100000 300

Results

Runner riscv-runner-48, 4 harts, isa: rv64imafdcsu, mmu: sv39, 16 GB.

Controls: the identical binaries are clean under QEMU riscv64 (6M guided regions) and on manylinux_2_39_aarch64 at 4, 16 and 64 threads.

So the fault is specific to libgomp's shared work-share iterator — the path schedule(static) does not use — on this hardware. glibc's allocator is not implicated.

How it surfaces

lightgbm (#616) is the package that found it. Its wheel builds and repairs cleanly, then the ranking tests fault inside gomp_iter_guided_next():

Thread 9 "python" received signal SIGSEGV
#0  gomp_iter_guided_next () from /lib64/lp64d/libgomp.so.1
#1  LightGBM::FeatureGroup::FinishLoad()._omp_fn.0 () at include/LightGBM/feature_group.h:366
#2  gomp_thread_start () from /lib64/lp64d/libgomp.so.1

Setting OMP_WAIT_POLICY=passive GOMP_SPINCOUNT=0, or OMP_NUM_THREADS=1, makes it disappear (0/10 each, against 9/10 at the default). Rebuilding LightGBM at -O1 does not (10/10), so it is not a codegen problem in the package.

Next steps

Worth narrowing to hardware vs kernel vs libgomp before reporting upstream: the same probe on a different riscv64 machine would say which.

首先，在 ubuntu-24.04-riscv runner 上使用 gcc -O2 -fopenmp 编译提供的 C 复现程序；将 guided 和 dynamic 调度与 static 以及列出的控制项进行比较。利用 include/LightGBM/feature_group.h:366 处的 LightGBM trace，确定该故障是否因不同的 riscv64 机器、内核或 libgomp 版本而有所不同；记录已确认的原因或 upstream 报告。