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: [email protected]
Reporter: [email protected]
Flags: maintainer-feedback?([email protected])
Assignee: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-desktop
To unsubscribe, send any mail to "[email protected]"
