Re: 2025Q1 lang/rust build failure on illumos (ENOMEM)

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2025-04-17 at 18:29 BST, Hans Rosenfeld wrote:

> On Wed, Apr 16, 2025 at 10:34:42PM +0100, Jonathan Perkin wrote:
> > * On 2025-04-16 at 15:32 BST, Hans Rosenfeld wrote:
> >
> > > I ran 'ulimit -s 131072' in the shell I'm using for building, and
> > > devel/cargo-c built successfully.
> > >
> > > I presume that means it needs UNLIMIT_RESOURCES? Is that perhaps the
> > > case for all rust-based packages?
> >
> > What's your default stacksize?  On SmartOS it's 10MB and I didn't have any
> > problems building cargo-c.  At what threshold does it start working for you?
>
> It did work with 131072, while it did not when it was unlimited.
>
> I didn't check any other values. I figure it's the same problem that I
> saw building lang/rust, and I would conclude that rustc (?) just doesn't
> like running with unlimited stack size in general, for the reasons given
> previously (https://github.com/NetBSD/pkgsrc/commit/a7aeedc3).
>
> I do however wonder whether it is stack_getbounds(3c) that is wrong, or
> whether rust is wrong not handling this case properly. It seems counter-
> intuitive to have UNLIMIT_RESOURCES actually limit stack size to a
> smaller value if it's already "unlimited".

Yeh, I have a number of thoughts on this:

 * It's highly unlikely that a user will have a default stacksize of
   "unlimited", so this is only a problem specifically in a pkgsrc
   context when using infrastructure prior to my change.  So in theory,
   there is currently no problem, at least in a default environment.

 * stack_getbounds(3C) in the unlimited case is at least unhelpful,
   though I wouldn't go so far as calling it wrong.  Just a CAVEAT that
   needs to be thoroughly understood by anyone relying on it.

 * Due to the above, it's probably the best long-term fix that this is
   correctly handled in upstream rust, so that it doesn't also affect
   'ulimit -s unlimited' users outside of pkgsrc.

 * It's also worth pointing out that on many other systems the default
   hard stacksize limit is not unlimited.  NetBSD appears to be 128MB,
   macOS 64MB, etc.  Rather than CAVEAT stack_getbounds(3C), a better
   long-term fix in illumos would be to have a similar hard limit and
   remove the problem entirely.

If someone wants to do work in either or both of upstreams, we will 
still need to support older systems and/or Solaris (I don't know what 
they do here), so will still need the pkgsrc workaround for quite a long 
time.

Cheers,

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com