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.

Bắt đầu bằng cách biên dịch trình tái hiện C được cung cấp với gcc -O2 -fopenmp trên runner ubuntu-24.04-riscv; so sánh các lịch guided và dynamic với static cùng các tùy chọn điều khiển được liệt kê. Thu hẹp xem lỗi có khác nhau giữa các máy riscv64, kernel hoặc phiên bản libgomp hay không, bằng cách sử dụng trace của LightGBM tại include/LightGBM/feature_group.h:366; ghi lại nguyên nhân đã được xác nhận hoặc báo cáo upstream.