Segmentation fault and compiler flags #2128

Activity

1. veljjanoski commented on Nov 1, 2026

   

   veljjanoski

   on Nov 1, 2026

   Contributor

   More actions

   I can reproduce the crash on main (2bc0681), in Docker with GCC 12 and Clang 21 (Debian 12) and GCC 16 (Fedora). Built with only -I<stdexec>/include, the README example crashes in get_parallel_scheduler(): query_parallel_scheduler_backend is declared weak and nothing defines it, so the call goes to address 0.

   #2349 documents the two ways to provide the backend. The second one, -DSTDEXEC_BUILD_PARALLEL_SCHEDULER=ON and linking STDEXEC::parallel_scheduler, also crashes for me. I used a small CMake project with add_subdirectory(stdexec) and the README example:

   STDEXEC::parallel_scheduler	GCC 12	Clang 21
   static library (the default)	crash	crash
   shared library	crash	works

   The program has only a weak reference to the backend, and a weak reference does not pull an object file out of a static library. Debian's GCC also links with --as-needed by default, which drops a shared library that only satisfies weak references. Defining STDEXEC_PARALLEL_SCHEDULER_HEADER_ONLY works with both compilers.

   I'd like to fix this, in two parts:

   1. In get_parallel_scheduler(), check the address of the weak function first, and throw a std::runtime_error that says how to provide a backend, instead of calling a null pointer. I have this working locally.
   2. Make the library route work. One way: STDEXEC::parallel_scheduler adds a compile definition for its users, and with it the header declares query_parallel_scheduler_backend without weak. Users of the library then have a normal reference, which pulls in the backend, while the library's own definition stays weak and can still be replaced. I haven't tried this yet.

   Would you take a PR for both? Or do you prefer another fix for the second part?

   Claude (Anthropic) was used as assistant.