[Bug 253602] devel/glib20: Local patch to glib20 uses a broken and unstable fdwalk implementation

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253602

            Bug ID: 253602
           Summary: devel/glib20: Local patch to glib20 uses a broken and
                    unstable fdwalk implementation
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: desktop at FreeBSD.org
          Reporter: jhb at FreeBSD.org
             Flags: maintainer-feedback?(desktop at FreeBSD.org)
          Assignee: desktop at FreeBSD.org

Created attachment 222539
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222539&action=edit
Patch to the port

Paul Saab found that devel/glib20 was failing to build in a poudriere jail on
one of his machines.  We tracked this down to the alloca() in our local patch
to add fdwalk2() failing and overflowing the stack.  The reason is that the
fdwalk2() implementation uses the kern.file sysctl which fetches a _global_
table of all open files across all processes, meaning that the amount of
required memory scales with the number of processes in the system.  fdwalk2()
should instead be using kinfo_getfile() from libutil which fetches only the
open files for the current process (which also uses malloc() to avoid stack
limit issues).  While here, I also noticed that fdwalk2() failed to propagate
the callback's return value to the caller and instead always returns 0 since
*ret was never assigned a value.

The attached patch is untested, but should fix both of these issues.  I wasn't
quite sure how to convince glib20's port to add libutil as an explicit
dependency (e.g. in LDFLAGS), so I'm hopeful a port maintainer can add that
missing bit and finish this the rest of the way.

-- 
You are receiving this mail because:
You are the assignee for the bug.