Re: new rust (was: gdb issues?)

[RVP <rvp%SDF.ORG@localhost>]

On Wed, 11 Oct 2023, Havard Eidnes wrote:

> > Program terminated with signal SIGSEGV, Segmentation fault.
> ...
> > #0  0x60d0fe74 in _cpuset_isset () from /usr/lib/libc.so.12
> > #1  0x03d2bf8c in std::sys::unix::thread::available_parallelism ()
>
> ...
>
> > At least it gives a bit of clue about where to go looking for the
> > null pointer de-reference, so that's at least something...
>
> This gets me to
>
> work/rustc-1.73.0-src/library/std/src/sys/unix/thread.rs
>
> which says:
>
>                            for i in 0..u64::MAX {
>                                match libc::_cpuset_isset(i, set) {
> [...]
> but ... under which conditions would it seg-fault inside that function?

What's does the Rust impl. of _cpuset_isset() look like? Does it
take ints by any chance and you're passing a u64 to it here. A C
compiler will complain if you use `-m32', but, that's all. Don't
know how the Rust FFI will handle this. That's all I can think
of...

> Debugging the C program reveals that pthread_getaffinity_np() has
> done exactly nothing to the "cset" contents as near as I can
> tell, the "bits" entry doesn't change.

pthread_getaffinity_np() _can_ be used to get the no. of "online"
CPUs on both Linux and FreeBSD, but it looks (from my perusal just
now) like threads default to no affinity on NetBSD and the scheduler
just picks whatever CPUs available for it--unless the affinity is
explicitly set, in which case it's inherited.

I think you should just use sysconf(_SC_NPROCESSORS_ONLN) or the
equivalent on NetBSD.

HTH,

-RVP