Date: Wed, 17 Feb 2021 22:08:12 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: maintainer-feedback requested: [Bug 253602] devel/glib20: Local patch to glib20 uses a broken and unstable fdwalk implementation Message-ID: <bug-253602-39348-tyCm0ZccLW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253602-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-253602-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Bugzilla Automation <bugzilla@FreeBSD.org> has asked freebsd-desktop (Team) <desktop@FreeBSD.org> for maintainer-feedback: Bug 253602: devel/glib20: Local patch to glib20 uses a broken and unstable fdwalk implementation https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253602 --- Description --- 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 pat= ch 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 was= n'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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253602-39348-tyCm0ZccLW>