net/netatalk3: fix leftover build file #2

evansus · 2013-06-04T05:42:37Z

Resolves build warning that the file /etc/dbus-1/system.d/afp.conf is leftover after package is deinstalled.

evansus · 2013-06-04T05:45:24Z

Tested via tinderbox-4.0.x build: netatalk3 builds without errors, but dependent meta-package had leftover files, and succeeds with a Leftover warning. Checking build logs revealed the missing plist file.
Rebuilt both netatalk3 package and dependent meta-package after this patch, both build without errors.

tota · 2013-06-04T14:01:47Z

See below

evansus · 2013-06-04T14:11:27Z

Thanks @tota, I'll submit a PR for each.

tota · 2013-06-04T14:19:08Z

Thank you for patches and reports.
I'm looking forward to seeing you again on the FreeBSD PR database.

uqs · 2013-06-04T16:01:08Z

Sorry, we're not yet set up to accept merge request for these repos via Github. Please file a PR as indicated, thank you!

2. RTM_OLDADD and RTM_OLDDEL were removed from -stable. Thanks alfred@ for this patch. 3. Stagify. Submitted by: alfred (freebsd#2)

2. RTM_OLDADD and RTM_OLDDEL were removed from -stable. Thanks alfred@ for this patch. 3. Stagify. Submitted by: alfred (freebsd#2) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@351495 35697150-7ecd-e111-bb59-0022644237b5

<ChangeLog> --[ Redis 2.8.17 ] Release date: 19 Sep 2014 # UPGRADE URGENCY: HIGH for Redis Sentinel. LOW for Redis Server (unmodified compared to 2.8.16). * [FIX] Resolved a memory leak in the hiredis library causing a memory leak in Redis Sentinel when a monitored instance or another Sentinel is unavailable. Every reconnection attempt will leak a small amount of memory, but in the long run the process can reach a considerable size. --[ Redis 2.8.16 ] Release date: 16 Sep 2014 # UPGRADE URGENCY: HIGH for Redis if you are using 2.8.15 + AOF. LOW for Sentinel. * [FIX] The ability to load truncated AOF files introduced with Redis 2.8.15 contains a bug fixed in this release: after loading the file was not truncated to the last valid command, so the new commands are appended after a non well formed command. This means that: 1) The first AOF rewrite triggered by the server will automatically fix the problem. 2) However, if the server is restarted before the rewrite, Redis may not be able to load the file and you need to manually fix it. In order to fix a corrupted file you should start the redis-check-aof utility WITHOUT the --fix option, just to check the offset where the corruption is found. Around the offset reported by the check utility you'll find, inside your AOF file, a command which is not complete according to the Redis protocol. Just remove this incomplete command leafing the file unaltered before and after the offending command, and restart the server. IMPORTANT #1: Redis 2.8.15 is the only stable version of Redis with this bug so probably no actual real-world problem happened since the problem is automatically fixed at the first automatic AOF rewrite. IMPORTANT #2: Before upgrading to Redis 2.8.16, if you are using Redis 2.8.15 with AOF enabled, make sure to trigger a manual AOF rewrite using the BGREWRITEAOF command. * [FIX] SAVE is no longer propagated to AOF / slaves. </ChangeLog> git-svn-id: svn+ssh://svn.freebsd.org/ports/head@368794 35697150-7ecd-e111-bb59-0022644237b5

<ChangeLog> --[ Redis 2.8.17 ] Release date: 19 Sep 2014 # UPGRADE URGENCY: HIGH for Redis Sentinel. LOW for Redis Server (unmodified compared to 2.8.16). * [FIX] Resolved a memory leak in the hiredis library causing a memory leak in Redis Sentinel when a monitored instance or another Sentinel is unavailable. Every reconnection attempt will leak a small amount of memory, but in the long run the process can reach a considerable size. --[ Redis 2.8.16 ] Release date: 16 Sep 2014 # UPGRADE URGENCY: HIGH for Redis if you are using 2.8.15 + AOF. LOW for Sentinel. * [FIX] The ability to load truncated AOF files introduced with Redis 2.8.15 contains a bug fixed in this release: after loading the file was not truncated to the last valid command, so the new commands are appended after a non well formed command. This means that: 1) The first AOF rewrite triggered by the server will automatically fix the problem. 2) However, if the server is restarted before the rewrite, Redis may not be able to load the file and you need to manually fix it. In order to fix a corrupted file you should start the redis-check-aof utility WITHOUT the --fix option, just to check the offset where the corruption is found. Around the offset reported by the check utility you'll find, inside your AOF file, a command which is not complete according to the Redis protocol. Just remove this incomplete command leafing the file unaltered before and after the offending command, and restart the server. IMPORTANT #1: Redis 2.8.15 is the only stable version of Redis with this bug so probably no actual real-world problem happened since the problem is automatically fixed at the first automatic AOF rewrite. IMPORTANT #2: Before upgrading to Redis 2.8.16, if you are using Redis 2.8.15 with AOF enabled, make sure to trigger a manual AOF rewrite using the BGREWRITEAOF command. * [FIX] SAVE is no longer propagated to AOF / slaves. </ChangeLog>

Bugs: - Fix NULL check against lcap data from the jail which was actually setting lcap to NULL. This lines up with similar code in jexec(8). Github PR #1 - Fix compile warning and segfault if lcap was actually NULL - can't cast the jusername struct to string output Github PR #2 Enhancements: - Support dynamic maximum number of groups rather than relying on compile-time NGROUPS Github PR #2 - Support specify target jail by jailname or jail ID through use of libjail jail_get_id() Github PR #3 - Return more specific details when username/UID mapping into jail fails Github PR #3 PR: 197207 Submitted by: Nicholas Kiraly <kiraly.nicholas@gmail.com> Approved by: steve.polyack@intermedix.com (maintainer) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@378754 35697150-7ecd-e111-bb59-0022644237b5

Bugs: - Fix NULL check against lcap data from the jail which was actually setting lcap to NULL. This lines up with similar code in jexec(8). Github PR #1 - Fix compile warning and segfault if lcap was actually NULL - can't cast the jusername struct to string output Github PR #2 Enhancements: - Support dynamic maximum number of groups rather than relying on compile-time NGROUPS Github PR #2 - Support specify target jail by jailname or jail ID through use of libjail jail_get_id() Github PR #3 - Return more specific details when username/UID mapping into jail fails Github PR #3 PR: 197207 Submitted by: Nicholas Kiraly <kiraly.nicholas@gmail.com> Approved by: steve.polyack@intermedix.com (maintainer)

http://cpansearch.perl.org/src/ETHER/Test-LWP-UserAgent-0.027/Changes register_psgi, unregister_psgi, map_response, map_network_response and unmap_all all return their invocant, to allow for method chaining (Tom Hukins, github #2) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@382854 35697150-7ecd-e111-bb59-0022644237b5

http://cpansearch.perl.org/src/ETHER/Test-LWP-UserAgent-0.027/Changes register_psgi, unregister_psgi, map_response, map_network_response and unmap_all all return their invocant, to allow for method chaining (Tom Hukins, github #2)

…e the sole purpose to avoid using our standard MAKE_ENV. They were introduced in r279589 as part of "update to 0.0.6" PR 159499 by Kato (duh!) some four years ago; in r359185 bapt@ had mentioned that "lots of invocation of MAKE_CMD here are wrong as they do not properly respect MAKE_ENV" (which is ironic as avoiding MAKE_ENV *is* their only point) but the the real problem was neither fixed nor rationale for ugly work-around explained. The port builds itself through a series of recursive make(1) calls, and is using variables to pass various bits of internal state to submakes. This approach typically requires strict discipline and can be hard to implement correctly, to an extent being considered harmful [Miller 1997]. Incidentally, ${MAKE_ENV} includes variables that are 1) used by the port's own build logic and 2) are not handled in a robust way by it. Problem #1: consider the following code from `Makefile.rules.gnu.in': ifndef LIBDIR LIBDIR=. endif This is roughly equivalent to the following: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else # use whatever LIBDIR value make(1) can deduce endif Knowing that LIBDIR is set to some other value (`..') by inner makefiles, that code can be rewritten more elaborately like this: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else ifeq ($(origin LIBDIR), file) # use LIBDIR value set by some Makefile else # use whatever LIBDIR value make(1) can deduce endif Now, because LIBDIR is passed to make(1) via MAKE_ENV and the code above does not have "ifeq ($(origin LIBDIR), environment)" check, the build was affected by unexpected bogus value of it and subsequently failed. Since the only valid place we can expect "our" LIBDIR to come from is makefiles, we can inhibit unwanted pollution from the environment by rewriting the initial code like this: ifneq ($(origin LIBDIR), file) LIBDIR=. endif Problem #2 is similar: checking for CFLAGS and LDFLAGS to protect their initial assignment is very fragile as many frameworks akin to the Ports Collection would provide some default values. While it is usually safe to append to them, it is almost always a bad idea to use them verbatim. Apparently, these checks were put there to support resetting CFLAGS and LDFLAGS in `util/Makefile', but since removing them does not hurt do so regardless of small pollution in that one case that does not affect the build in any noticeable way. git-svn-id: svn+ssh://svn.freebsd.org/ports/head@399689 35697150-7ecd-e111-bb59-0022644237b5

…e the sole purpose to avoid using our standard MAKE_ENV. They were introduced in r279589 as part of "update to 0.0.6" PR 159499 by Kato (duh!) some four years ago; in r359185 bapt@ had mentioned that "lots of invocation of MAKE_CMD here are wrong as they do not properly respect MAKE_ENV" (which is ironic as avoiding MAKE_ENV *is* their only point) but the the real problem was neither fixed nor rationale for ugly work-around explained. The port builds itself through a series of recursive make(1) calls, and is using variables to pass various bits of internal state to submakes. This approach typically requires strict discipline and can be hard to implement correctly, to an extent being considered harmful [Miller 1997]. Incidentally, ${MAKE_ENV} includes variables that are 1) used by the port's own build logic and 2) are not handled in a robust way by it. Problem #1: consider the following code from `Makefile.rules.gnu.in': ifndef LIBDIR LIBDIR=. endif This is roughly equivalent to the following: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else # use whatever LIBDIR value make(1) can deduce endif Knowing that LIBDIR is set to some other value (`..') by inner makefiles, that code can be rewritten more elaborately like this: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else ifeq ($(origin LIBDIR), file) # use LIBDIR value set by some Makefile else # use whatever LIBDIR value make(1) can deduce endif Now, because LIBDIR is passed to make(1) via MAKE_ENV and the code above does not have "ifeq ($(origin LIBDIR), environment)" check, the build was affected by unexpected bogus value of it and subsequently failed. Since the only valid place we can expect "our" LIBDIR to come from is makefiles, we can inhibit unwanted pollution from the environment by rewriting the initial code like this: ifneq ($(origin LIBDIR), file) LIBDIR=. endif Problem #2 is similar: checking for CFLAGS and LDFLAGS to protect their initial assignment is very fragile as many frameworks akin to the Ports Collection would provide some default values. While it is usually safe to append to them, it is almost always a bad idea to use them verbatim. Apparently, these checks were put there to support resetting CFLAGS and LDFLAGS in `util/Makefile', but since removing them does not hurt do so regardless of small pollution in that one case that does not affect the build in any noticeable way.

**Released on November 22nd, 2015.** This is a huge release and marks a major milestone for Kyua as it finally implements a long-standing feature request: the ability to execute test cases in parallel. This is a big deal because test cases are rarely CPU-bound: running them in parallel yields much faster execution times for large test suites, allowing faster iteration of changes during development. As an example: the FreeBSD test suite as of this date contains 3285 test cases. With sequential execution, a full test suite run takes around 12 minutes to complete, whereas on a 4-core machine with a high level of parallelism it takes a little over 1 minute. Implementing parallel execution required rewriting most of Kyua's core and partly explains explains why there has not been a new release for over a year. The current implementation is purely subprocess-based, which works but has some limitations and has resulted in a core that is really complex and difficult to understand. Future versions will investigate the use of threads instead for a simplified programming model and additional parallelization possibilities. * Issue #2: Implemented support to execute test cases in parallel when invoking `kyua test`. Parallel execution is *only* enabled when the new `parallelism` configuration variable is set to a value greater than `1`. The default behavior is still to run tests sequentially because some test suites contain test cases with side-effects that might fail when run in parallel. To resolve this, the new metadata property `is_exclusive` can be set to `true` on a test basis to indicate that the test must be run on its own. * Known regression: Running `kyua debug` on a TAP-based test program does not currently report the output in real time. The output will only be displayed once the test program completes. This is a shortcoming of the new parallel execution engine and will be resolved. * Removed the external C-based testers code in favor of the new built-in implementations. The new approach feels significantly faster than the previous one. * Fixed the handling of relative paths in the `fs.*` functions available in `Kyuafile`s. All paths are now resolved relative to the location of the caller `Kyuafile`. `Kyuafile.top` has been updated with these changes and you should update custom copies of this file with the new version. * Changed temporary directory creation to always grant search permissions on temporary directories. This is to prevent potential problems when running Kyua as root and executing test cases that require dropping privileges (as they may later be unable to use absolute paths that point inside their work directory). * The cleanup of work directories does not longer attempt to deal with mount points. If a test case mounts a file system and forgets to unmount it, the mount point will be left behind. It is now the responsibility of the test case to clean after itself. The reasons for this change are simplicity and clarity: there are many more things that a test case can do that have side-effects on the system and Kyua cannot protect against them all, so it is better to just have the test undo anything it might have done. * Improved `kyua report --verbose` to properly handle environment variables with continuation lines in them, and fixed the integration tests for this command to avoid false negatives. * Changed the configuration file format to accept the definition of unknown variables without declaring them local. The syntax version number remains at 2. This is to allow configuration files for newer Kyua versions to work on older Kyua versions, as there is no reason to forbid this. * Fixed stacktrace gathering with FreeBSD's ancient version of GDB. GDB 6.1.1 (circa 2004) does not have the `-ex` flag so we need to generate a temporary GDB script and feed it to GDB with `-x` instead. * Issue #136: Fixed the XML escaping in the JUnit output so that non-printable characters are properly handled when they appear in the process's stdout or stderr. * Issue #141: Improved reporting of errors triggered by sqlite3. In particular, all error messages are now tagged with their corresponding database filename and, if they are API-level errors, the name of the sqlite3 function that caused them. * Issue #144: Improved documentation on the support for custom properties in the test metadata. * Converted the `INSTALL`, `NEWS`, and `README` distribution documents to Markdown for better formatting online. Approved by: bapt (mentor) Differential Revision: https://reviews.freebsd.org/D4243 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@402256 35697150-7ecd-e111-bb59-0022644237b5

**Released on November 22nd, 2015.** This is a huge release and marks a major milestone for Kyua as it finally implements a long-standing feature request: the ability to execute test cases in parallel. This is a big deal because test cases are rarely CPU-bound: running them in parallel yields much faster execution times for large test suites, allowing faster iteration of changes during development. As an example: the FreeBSD test suite as of this date contains 3285 test cases. With sequential execution, a full test suite run takes around 12 minutes to complete, whereas on a 4-core machine with a high level of parallelism it takes a little over 1 minute. Implementing parallel execution required rewriting most of Kyua's core and partly explains explains why there has not been a new release for over a year. The current implementation is purely subprocess-based, which works but has some limitations and has resulted in a core that is really complex and difficult to understand. Future versions will investigate the use of threads instead for a simplified programming model and additional parallelization possibilities. * Issue #2: Implemented support to execute test cases in parallel when invoking `kyua test`. Parallel execution is *only* enabled when the new `parallelism` configuration variable is set to a value greater than `1`. The default behavior is still to run tests sequentially because some test suites contain test cases with side-effects that might fail when run in parallel. To resolve this, the new metadata property `is_exclusive` can be set to `true` on a test basis to indicate that the test must be run on its own. * Known regression: Running `kyua debug` on a TAP-based test program does not currently report the output in real time. The output will only be displayed once the test program completes. This is a shortcoming of the new parallel execution engine and will be resolved. * Removed the external C-based testers code in favor of the new built-in implementations. The new approach feels significantly faster than the previous one. * Fixed the handling of relative paths in the `fs.*` functions available in `Kyuafile`s. All paths are now resolved relative to the location of the caller `Kyuafile`. `Kyuafile.top` has been updated with these changes and you should update custom copies of this file with the new version. * Changed temporary directory creation to always grant search permissions on temporary directories. This is to prevent potential problems when running Kyua as root and executing test cases that require dropping privileges (as they may later be unable to use absolute paths that point inside their work directory). * The cleanup of work directories does not longer attempt to deal with mount points. If a test case mounts a file system and forgets to unmount it, the mount point will be left behind. It is now the responsibility of the test case to clean after itself. The reasons for this change are simplicity and clarity: there are many more things that a test case can do that have side-effects on the system and Kyua cannot protect against them all, so it is better to just have the test undo anything it might have done. * Improved `kyua report --verbose` to properly handle environment variables with continuation lines in them, and fixed the integration tests for this command to avoid false negatives. * Changed the configuration file format to accept the definition of unknown variables without declaring them local. The syntax version number remains at 2. This is to allow configuration files for newer Kyua versions to work on older Kyua versions, as there is no reason to forbid this. * Fixed stacktrace gathering with FreeBSD's ancient version of GDB. GDB 6.1.1 (circa 2004) does not have the `-ex` flag so we need to generate a temporary GDB script and feed it to GDB with `-x` instead. * Issue #136: Fixed the XML escaping in the JUnit output so that non-printable characters are properly handled when they appear in the process's stdout or stderr. * Issue #141: Improved reporting of errors triggered by sqlite3. In particular, all error messages are now tagged with their corresponding database filename and, if they are API-level errors, the name of the sqlite3 function that caused them. * Issue #144: Improved documentation on the support for custom properties in the test metadata. * Converted the `INSTALL`, `NEWS`, and `README` distribution documents to Markdown for better formatting online. Approved by: bapt (mentor) Differential Revision: https://reviews.freebsd.org/D4243

Changes in upstream Git between releases (git shortlog): Sergey Nechaev (1): Stricter command line args validation to dhcp_release6. Simon Kelley (4): Fix error in PXE arch names and add ARM32 and ARM64. Tweak CSAs affected by UEFI PXE workaround code. Tweak UEFI workaround code. Merge messages into translation files. Upstream CHANGELOG diff since rc #1: Swap the values if BC_EFI and x86-64_EFI in --pxe-service. These were previously wrong due to an error in RFC 4578. If you're using BC_EFI to boot 64-bit EFI machines, you will need to update your config. Add ARM32_EFI and ARM64_EFI as valid architectures in --pxe-service. git-svn-id: svn+ssh://svn.freebsd.org/ports/head@415366 35697150-7ecd-e111-bb59-0022644237b5

Changes in upstream Git between releases (git shortlog): Sergey Nechaev (1): Stricter command line args validation to dhcp_release6. Simon Kelley (4): Fix error in PXE arch names and add ARM32 and ARM64. Tweak CSAs affected by UEFI PXE workaround code. Tweak UEFI workaround code. Merge messages into translation files. Upstream CHANGELOG diff since rc #1: Swap the values if BC_EFI and x86-64_EFI in --pxe-service. These were previously wrong due to an error in RFC 4578. If you're using BC_EFI to boot 64-bit EFI machines, you will need to update your config. Add ARM32_EFI and ARM64_EFI as valid architectures in --pxe-service.

…correct define and disabling the JIT compiler. PR: 207275 Submitted by: mikael.urankar@gmail.com Reported by: sbruno Reviewed by: bdrewery (implicit) Approved by: maintainer timeout git-svn-id: svn+ssh://svn.freebsd.org/ports/head@422748 35697150-7ecd-e111-bb59-0022644237b5

…correct define and disabling the JIT compiler. PR: 207275 Submitted by: mikael.urankar@gmail.com Reported by: sbruno Reviewed by: bdrewery (implicit) Approved by: maintainer timeout

devel/arduino-builder. =) Right now, there's two possible configurations for building and flashing Arduino projects: 1.) Use devel/arduino16 -- this pulls in devel/arduino-builder and devel/arduino-tools itself, and uses its own method (as it turns out, completely different from arduino-builder's discovery mechanism =() for finding the proper utility for flashing (devel/bossa vs. devel/avrdude) 2.) Use devel/arduino-builder + devel/arduino-tools directly, flash the result yourself -- this has the pro of not requiring Java to build a project, but the con that you do have to figure out how to flash the board (w/ devel/bossa or devel/avrdude) yourself. I suspect that #1 will be the most commonly used configuration, but #2 is nice for "advanced" (or not-so-advanced) applications (such as using a Raspberry Pi to compile+flash firmware for a 3D printer =)). As such, we add an OPTION to make this a more straightforward process of install devel/arduino-builder and then Just Do It. This option will also add in a file at arduino/arduino-builder.options that can be passed into arduino-builder through the -build-options-file. This removes the need for -hardware, -libraries, and -tools flags based on the defaults for devel/arduino-tools. This also auto-populates the core version ("runtime.ide.version", -ide-version/-core-api-version, and the ARDUINO #define) with the minimally supported version (see: _COMPAT_VER, _IDE_VER -- these should be kept in sync, and correspond to versions of devel/arduino-{core,tools}) PR: 213749 Submitted by: Kyle Evans <bsdports@kyle-evans.net> (maintainer) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@424593 35697150-7ecd-e111-bb59-0022644237b5

devel/arduino-builder. =) Right now, there's two possible configurations for building and flashing Arduino projects: 1.) Use devel/arduino16 -- this pulls in devel/arduino-builder and devel/arduino-tools itself, and uses its own method (as it turns out, completely different from arduino-builder's discovery mechanism =() for finding the proper utility for flashing (devel/bossa vs. devel/avrdude) 2.) Use devel/arduino-builder + devel/arduino-tools directly, flash the result yourself -- this has the pro of not requiring Java to build a project, but the con that you do have to figure out how to flash the board (w/ devel/bossa or devel/avrdude) yourself. I suspect that #1 will be the most commonly used configuration, but #2 is nice for "advanced" (or not-so-advanced) applications (such as using a Raspberry Pi to compile+flash firmware for a 3D printer =)). As such, we add an OPTION to make this a more straightforward process of install devel/arduino-builder and then Just Do It. This option will also add in a file at arduino/arduino-builder.options that can be passed into arduino-builder through the -build-options-file. This removes the need for -hardware, -libraries, and -tools flags based on the defaults for devel/arduino-tools. This also auto-populates the core version ("runtime.ide.version", -ide-version/-core-api-version, and the ARDUINO #define) with the minimally supported version (see: _COMPAT_VER, _IDE_VER -- these should be kept in sync, and correspond to versions of devel/arduino-{core,tools}) PR: 213749 Submitted by: Kyle Evans <bsdports@kyle-evans.net> (maintainer)

Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: #0 0x28B2C4D6 #1 0x28B2CB17 #2 0xFFFFE193 gmake[2]: *** [Makefile:10: level1] Bus error (core dumped) Approved by: portmgr blanket git-svn-id: svn+ssh://svn.freebsd.org/ports/head@429052 35697150-7ecd-e111-bb59-0022644237b5

Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: #0 0x28B2C4D6 #1 0x28B2CB17 #2 0xFFFFE193 gmake[2]: *** [Makefile:10: level1] Bus error (core dumped) Approved by: portmgr blanket

* imapc: Info-level line is logged every time when successfully connected to the remote server. This includes local/remote IP/port, which can be useful for matching against external logs. * config: Log a warning if plugin { key=no } is used explicitly. v2.3 will support "no" properly in plugin settings, but for now any value at all for a boolean plugin setting is treated as "yes", even if it's written as explicit "no". This change will now warn that it most likely won't work as intended. + Various optimizations to avoid accessing files/directories when it's not necessary. Especially avoid accessing mail root directories when INDEX directories point to a different filesystem. + mail_location can now include ITERINDEX parameter. This tells Dovecot to perform mailbox listing from the INDEX path instead of from the mail root path. It's mainly useful when the INDEX storage is on a faster storage. + mail_location can now include VOLATILEDIR=<path> parameter. This is used for creating lock files and in future potentially other files that don't need to exist permanently. The path could point to tmpfs for example. This is especially useful to avoid creating lock files to NFS or other remote filesystems. For example: mail_location=sdbox:~/sdbox:VOLATILEDIR=/tmp/volatile/%2.256Nu/%u + mail_location's LISTINDEX=<path> can now contain a full path. This allows storing mailbox list index to a different storage than the rest of the indexes, for example to tmpfs. + mail_location can now include NO-NOSELECT parameter. This automatically deletes any \NoSelect mailboxes that have no children. These mailboxes are sometimes confusing to users. + mail_location can now include BROKENCHAR=<char> parameter. This can be useful with imapc to access mailbox names that aren't valid mUTF-7 charset from remote servers. + If mailbox_list_index_very_dirty_syncs=yes, the list index is no longer refreshed against filesystem when listing mailboxes. This allows the mailbox listing to be done entirely by only reading the mailbox list index. + Added mailbox_list_index_include_inbox setting to control whether INBOX's STATUS information should be cached in the mailbox list index. The default is "no", but it may be useful to change it to "yes", especially if LISTINDEX points to tmpfs. + userdb can return chdir=<path>, which override mail_home for the chdir location. This can be useful to avoid accessing home directory on login. + userdb can return postlogin=<socket> to specify per-user imap/pop3 postlogin socket path. + cassandra: Add support for result paging by adding page_size=<n> parameter to the connect setting. + dsync/imapc, pop3-migration plugin: Strip also trailing tabs from headers when matching mails. This helps with migrations from Zimbra. + imap_logout_format supports now %{appended} and %{autoexpunged} + virtual plugin: Optimize IDLE to use mailbox list index for finding out when something has changed. + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor - virtual plugin: A lot of fixes. In many cases it was also working very inefficiently or even incorrectly. - imap: NOTIFY parameter parsing was incorrectly "fixed" in v2.2.31. It was actually (mostly) working in previous versions, but broken in v2.2.31. - Modseq tracking didn't always work correctly. This could have caused imap unhibernation to fail or IMAP QRESYNC/CONDSTORE extensions to not work perfectly. - mdbox: "Inconsistency in map index" wasn't fixed automatically - dict-ldap: %variable values used in the LDAP filter weren't escaped. - quota=count: quota_warning = -storage=.. was never executed (try #2). v2.2.31 fixed it for -messages, but not for -storage. - imapc: >= 32 kB mail bodies were supposed to be cached for subsequent FETCHes, but weren't. - quota-status service didn't support recipient_delimiter - acl: Don't access dovecot-acl-list files with acl_globals_only=yes - mail_location: If INDEX dir is set, mailbox deletion deletes its childrens' indexes. For example if "box" is deleted, "box/child" index directory was deleted as well (but mails were preserved). - director: v2.2.31 caused rapid reconnection loops to directors that were down. git-svn-id: svn+ssh://svn.freebsd.org/ports/head@448697 35697150-7ecd-e111-bb59-0022644237b5

* imapc: Info-level line is logged every time when successfully connected to the remote server. This includes local/remote IP/port, which can be useful for matching against external logs. * config: Log a warning if plugin { key=no } is used explicitly. v2.3 will support "no" properly in plugin settings, but for now any value at all for a boolean plugin setting is treated as "yes", even if it's written as explicit "no". This change will now warn that it most likely won't work as intended. + Various optimizations to avoid accessing files/directories when it's not necessary. Especially avoid accessing mail root directories when INDEX directories point to a different filesystem. + mail_location can now include ITERINDEX parameter. This tells Dovecot to perform mailbox listing from the INDEX path instead of from the mail root path. It's mainly useful when the INDEX storage is on a faster storage. + mail_location can now include VOLATILEDIR=<path> parameter. This is used for creating lock files and in future potentially other files that don't need to exist permanently. The path could point to tmpfs for example. This is especially useful to avoid creating lock files to NFS or other remote filesystems. For example: mail_location=sdbox:~/sdbox:VOLATILEDIR=/tmp/volatile/%2.256Nu/%u + mail_location's LISTINDEX=<path> can now contain a full path. This allows storing mailbox list index to a different storage than the rest of the indexes, for example to tmpfs. + mail_location can now include NO-NOSELECT parameter. This automatically deletes any \NoSelect mailboxes that have no children. These mailboxes are sometimes confusing to users. + mail_location can now include BROKENCHAR=<char> parameter. This can be useful with imapc to access mailbox names that aren't valid mUTF-7 charset from remote servers. + If mailbox_list_index_very_dirty_syncs=yes, the list index is no longer refreshed against filesystem when listing mailboxes. This allows the mailbox listing to be done entirely by only reading the mailbox list index. + Added mailbox_list_index_include_inbox setting to control whether INBOX's STATUS information should be cached in the mailbox list index. The default is "no", but it may be useful to change it to "yes", especially if LISTINDEX points to tmpfs. + userdb can return chdir=<path>, which override mail_home for the chdir location. This can be useful to avoid accessing home directory on login. + userdb can return postlogin=<socket> to specify per-user imap/pop3 postlogin socket path. + cassandra: Add support for result paging by adding page_size=<n> parameter to the connect setting. + dsync/imapc, pop3-migration plugin: Strip also trailing tabs from headers when matching mails. This helps with migrations from Zimbra. + imap_logout_format supports now %{appended} and %{autoexpunged} + virtual plugin: Optimize IDLE to use mailbox list index for finding out when something has changed. + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor - virtual plugin: A lot of fixes. In many cases it was also working very inefficiently or even incorrectly. - imap: NOTIFY parameter parsing was incorrectly "fixed" in v2.2.31. It was actually (mostly) working in previous versions, but broken in v2.2.31. - Modseq tracking didn't always work correctly. This could have caused imap unhibernation to fail or IMAP QRESYNC/CONDSTORE extensions to not work perfectly. - mdbox: "Inconsistency in map index" wasn't fixed automatically - dict-ldap: %variable values used in the LDAP filter weren't escaped. - quota=count: quota_warning = -storage=.. was never executed (try #2). v2.2.31 fixed it for -messages, but not for -storage. - imapc: >= 32 kB mail bodies were supposed to be cached for subsequent FETCHes, but weren't. - quota-status service didn't support recipient_delimiter - acl: Don't access dovecot-acl-list files with acl_globals_only=yes - mail_location: If INDEX dir is set, mailbox deletion deletes its childrens' indexes. For example if "box" is deleted, "box/child" index directory was deleted as well (but mails were preserved). - director: v2.2.31 caused rapid reconnection loops to directors that were down.

Merge pull request #1 from swills/plasma5

patch -p1 -F0 -o helper/fast-import.patched.c git-core/builtin/fast-import.c < helper/fast-import.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/builtin/fast-import.c b/builtin/fast-import.c |index 20406f6775..7ff0911c2c 100644 |--- a/builtin/fast-import.c |+++ b/builtin/fast-import.c -------------------------- Patching file git-core/builtin/fast-import.c using Plan A... Hunk freebsd#1 failed at 19. Hunk freebsd#2 succeeded at 747 (offset 9 lines). Hunk freebsd#3 succeeded at 848 (offset 9 lines). Hunk freebsd#4 failed at 867. Hunk freebsd#5 succeeded at 967 (offset 9 lines). Hunk freebsd#6 succeeded at 1653 (offset 9 lines). Hunk freebsd#7 succeeded at 2222 (offset 9 lines). Hunk freebsd#8 succeeded at 2288 (offset 9 lines). 2 out of 8 hunks failed--saving rejects to helper/fast-import.patched.c.rej done

Version 1.5.0 produces errors when used with PHP-8: PHP Fatal error: Uncaught ValueError: fread(): Argument #2 ($length) must be greater than 0 in /usr/local/share/pear/Net/DNS2/Cache/File. It has been fixed in 1.5.2. PR: 263924 Approved by: sunpoet (maintainer)

FAILED: IGC/Release/libigc.so.1.0.1 : && /usr/bin/c++ ... -o IGC/Release/libigc.so.1.0.1 ... LLVM ERROR: out of memory PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bshareable --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o IGC/Release/libigc.so.1.0.1 ... #0 0x019dc334 (/usr/bin/ld+0x19dc334) #1 0x019dc73e (/usr/bin/ld+0x19dc73e) #2 0x019da64e (/usr/bin/ld+0x19da64e) #3 0x019dca0c (/usr/bin/ld+0x19dca0c) #4 0x22ef0319 (/lib/libthr.so.3+0x18319) c++: error: unable to execute command: Abort trap (core dumped) c++: error: linker command failed due to signal (use -v to see invocation) Reported by: pkg-fallout

$ ffmpeg -hide_banner -i foo.y4m -c:v libsvtav1 -y foo.mp4 [...] Segmentation fault (lldb) bt * thread #1, name = 'ffmpeg', stop reason = signal SIGSEGV: invalid address (fault address: 0x438) * frame #0: 0x00000008372f34b9 libSvtAv1Enc.so.1`svt_aom_copy_metadata_buffer(dst=0x000000089e044680, src=0x0000000000000438) at EbMetadataHandle.c:108:26 frame #1: 0x00000008372e67c4 libSvtAv1Enc.so.1`copy_input_buffer(scs=0x0000000868186380, dst=0x000000089e044680, dst_y8b=0x000000089e047380, src=0x0000000820287b20, pass=0) at EbEncHandle.c:4820:13 frame #2: 0x00000008372e64d4 libSvtAv1Enc.so.1`svt_av1_enc_send_picture(svt_enc_component=0x000000085f30de60, p_buffer=0x0000000820287b20) at EbEncHandle.c:4865:9 frame #3: 0x000000082449de42 libavcodec.so.58`eb_receive_packet at libsvtav1.c:433:9 frame #4: 0x000000082449dc7a libavcodec.so.58`eb_receive_packet(avctx=0x000000085f309300, pkt=0x000000085f312c00) at libsvtav1.c:503 frame #5: 0x000000082419f960 libavcodec.so.58`encode_receive_packet_internal(avctx=0x000000085f309300, avpkt=0x000000085f312c00) at encode.c:301:15 frame #6: 0x000000082419f893 libavcodec.so.58`avcodec_send_frame(avctx=0x000000085f309300, frame=0x0000000000000000) at encode.c:387:15 frame #7: 0x0000000000231e9a ffmpeg`transcode at ffmpeg.c:1995:23 frame #8: 0x0000000000231ce8 ffmpeg`transcode at ffmpeg.c:4825 frame #9: 0x000000000022da03 ffmpeg`main(argc=<unavailable>, argv=<unavailable>) at ffmpeg.c:5010:9 frame #10: 0x0000000000215ad0 ffmpeg`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 Regressed by: https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/921c1877c050 See also: https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/4243da4ff42e

FAILED: opencl_clang_options.inc ../.build/opencl_clang_options.inc cd ../.build && /usr/bin/llvm-tblgen -gen-opt-parser-defs -I /usr/local/llvm15/include -I . opencl_clang_options.td --write-if-changed -o opencl_clang_options.inc -d opencl_clang_options.inc.d Included from opencl_clang_options.td:8: /usr/local/llvm15/include/llvm/Option/OptParser.td:16:66: error: Variable not defined: 'false' class OptionKind<string name, int precedence = 0, bit sentinel = false> { ^ Included from opencl_clang_options.td:8: /usr/local/llvm15/include/llvm/Option/OptParser.td:25:18: error: Value not specified for template argument #2 (OptionKind:sentinel) of subclass 'OptionKind'! def KIND_GROUP : OptionKind<"Group">; ^

FAILED: opencl_clang_options.inc ../.build/opencl_clang_options.inc cd ../.build && /usr/bin/llvm-tblgen -gen-opt-parser-defs -I /usr/local/llvm15/include -I . opencl_clang_options.td --write-if-changed -o opencl_clang_options.inc -d opencl_clang_options.inc.d Included from opencl_clang_options.td:8: /usr/local/llvm15/include/llvm/Option/OptParser.td:16:66: error: Variable not defined: 'false' class OptionKind<string name, int precedence = 0, bit sentinel = false> { ^ Included from opencl_clang_options.td:8: /usr/local/llvm15/include/llvm/Option/OptParser.td:25:18: error: Value not specified for template argument freebsd#2 (OptionKind:sentinel) of subclass 'OptionKind'! def KIND_GROUP : OptionKind<"Group">; ^

…eeBSD < 13 FAILED: IGC/Release/libigc.so.1.0.1 [...] LLVM ERROR: out of memory [...] #0 0x01c031d4 (/usr/bin/ld+0x1c031d4) #1 0x01c035de (/usr/bin/ld+0x1c035de) #2 0x01c0129e (/usr/bin/ld+0x1c0129e) #3 0x01c03d78 (/usr/bin/ld+0x1c03d78) #4 0x02c40009 (/usr/bin/ld+0x2c40009) c++: error: unable to execute command: Abort trap (core dumped) c++: error: linker command failed due to signal (use -v to see invocation) ninja: build stopped: subcommand failed. Reported by: pkg-fallout This reverts commit eb375ae.

$ ffmpeg -hide_banner -i foo.y4m -c:v libsvtav1 -y foo.ivf $ ffmpeg -hide_banner -i foo.ivf -f null /dev/null [libdav1d @ 0x250c2c00] libdav1d 1.0.0 [libdav1d @ 0x250c2c00] Frame size limit reduced from 2147483647 to 67108864. Bus error * thread #1, name = 'ffmpeg', stop reason = signal SIGBUS: hardware error frame #0: 0x22e8c816 libdav1d.so.6`dav1d_data_wrap(buf=0x25100390, ptr="\U00000012", sz=61259, free_callback=(libavcodec.so.58`libdav1d_data_free at libdav1d.c:189), user_data=0x250d66c0) at lib.c:734 (lldb) bt * thread #1, name = 'ffmpeg', stop reason = signal SIGBUS: hardware error * frame #0: 0x22e8c816 libdav1d.so.6`dav1d_data_wrap(buf=0x25100390, ptr="\U00000012", sz=61259, free_callback=(libavcodec.so.58`libdav1d_data_free at libdav1d.c:189), user_data=0x250d66c0) at lib.c:734 frame #1: 0x213a4c33 libavcodec.so.58`libdav1d_receive_frame(c=<unavailable>, frame=<unavailable>) at libdav1d.c:215:19 frame #2: 0x21121082 libavcodec.so.58`decode_receive_frame_internal(avctx=0x250bfc00, frame=<unavailable>) at decode.c:546:15 frame #3: 0x21120fd8 libavcodec.so.58`avcodec_send_packet(avctx=0x250bfc00, avpkt=0xffffd3d0) at decode.c:617:15 frame #4: 0x20a5273d libavformat.so.58`try_decode_frame(s=<unavailable>, st=0x250f9000, avpkt=<unavailable>, options=<unavailable>) at utils.c:3084:19 frame #5: 0x20a4fe73 libavformat.so.58`avformat_find_stream_info(ic=0x250d7000, options=0x250d61c0) at utils.c:3949:9 frame #6: 0x00418cf6 ffmpeg`open_input_file(o=0xffffd80c, filename=<unavailable>) at ffmpeg_opt.c:1196:15 frame #7: 0x004184c9 ffmpeg`open_files(l=<unavailable>, inout=<unavailable>, open_file=<unavailable>) at ffmpeg_opt.c:3338:15 frame #8: 0x00418278 ffmpeg`ffmpeg_parse_options(argc=<unavailable>, argv=<unavailable>) at ffmpeg_opt.c:3378:11 frame #9: 0x0042e6f0 ffmpeg`main(argc=7, argv=0xffffdc44) at ffmpeg.c:4988:11 frame #10: 0x00417d0d ffmpeg`_start1(cleanup=0x204537e0, argc=7, argv=0xffffdc44) at crt1_c.c:72:7 frame #11: 0x00417e70 ffmpeg`_start at crt1_s.S:46 $ make clean test -C graphics/libavif [...] 45% tests passed, 6 tests failed out of 11 Total Test time (real) = 17.82 sec The following tests FAILED: 1 - aviftest (Bus error) 5 - avifchangesettingtest (Bus error) 6 - avifgridapitest (Bus error) 7 - avifincrtest (Bus error) 8 - avifmetadatatest (Bus error) 11 - test_cmd (Failed) * thread #1, name = 'aviftest', stop reason = signal SIGBUS: hardware error frame #0: 0x207a81f6 libdav1d.so.6`dav1d_data_wrap(buf=0xffffc7d4, ptr="\U00000012", sz=37169, free_callback=(libavif.so.15`avifDav1dFreeCallback at codec_dav1d.c:34), user_data=0x00000000) at lib.c:734 731 void (*const free_callback)(const uint8_t *data, 732 void *user_data), 733 void *const user_data) -> 734 { 735 return dav1d_data_wrap_internal(buf, ptr, sz, free_callback, user_data); 736 } 737 (lldb) bt * thread #1, name = 'aviftest', stop reason = signal SIGBUS: hardware error * frame #0: 0x207a81f6 libdav1d.so.6`dav1d_data_wrap(buf=0xffffc7d4, ptr="\U00000012", sz=37169, free_callback=(libavif.so.15`avifDav1dFreeCallback at codec_dav1d.c:34), user_data=0x00000000) at lib.c:734 frame #1: 0x204746a1 libavif.so.15`dav1dCodecGetNextImage(codec=0x215e9090, decoder=0x2182c000, sample=0x215e9060, alpha=0, isLimitedRangeAlpha=0xffffc93c, image=0x218400a0) at codec_dav1d.c:87:9 frame #2: 0x2045c812 libavif.so.15`avifDecoderDecodeTiles(decoder=0x2182c000, nextImageIndex=0, firstTileIndex=0, tileCount=1, decodedTileCount=0x2183302c) at read.c:3853:14 frame #3: 0x2045bf59 libavif.so.15`avifDecoderNextImage(decoder=0x2182c000) at read.c:3937:9 frame #4: 0x004029a9 aviftest`runIOTests(dataDir="../libavif-0.11.0/tests/data/") at aviftest.c:255:54 frame #5: 0x00402310 aviftest`main(argc=2, argv=0xffffdc0c) at aviftest.c:327:19 frame #6: 0x00401f9d aviftest`_start1(cleanup=0x204157e0, argc=2, argv=0xffffdc0c) at crt1_c.c:72:7 frame #7: 0x00402100 aviftest`_start at crt1_s.S:46

$ ffmpeg -hide_banner -i foo.y4m -c:v libsvtav1 -y foo.ivf $ ffmpeg -hide_banner -i foo.ivf -f null /dev/null [libdav1d @ 0x250c2c00] libdav1d 1.0.0 [libdav1d @ 0x250c2c00] Frame size limit reduced from 2147483647 to 67108864. Bus error * thread #1, name = 'ffmpeg', stop reason = signal SIGBUS: hardware error frame #0: 0x22e8c816 libdav1d.so.6`dav1d_data_wrap(buf=0x25100390, ptr="\U00000012", sz=61259, free_callback=(libavcodec.so.58`libdav1d_data_free at libdav1d.c:189), user_data=0x250d66c0) at lib.c:734 (lldb) bt * thread #1, name = 'ffmpeg', stop reason = signal SIGBUS: hardware error * frame #0: 0x22e8c816 libdav1d.so.6`dav1d_data_wrap(buf=0x25100390, ptr="\U00000012", sz=61259, free_callback=(libavcodec.so.58`libdav1d_data_free at libdav1d.c:189), user_data=0x250d66c0) at lib.c:734 frame #1: 0x213a4c33 libavcodec.so.58`libdav1d_receive_frame(c=<unavailable>, frame=<unavailable>) at libdav1d.c:215:19 frame #2: 0x21121082 libavcodec.so.58`decode_receive_frame_internal(avctx=0x250bfc00, frame=<unavailable>) at decode.c:546:15 frame #3: 0x21120fd8 libavcodec.so.58`avcodec_send_packet(avctx=0x250bfc00, avpkt=0xffffd3d0) at decode.c:617:15 frame #4: 0x20a5273d libavformat.so.58`try_decode_frame(s=<unavailable>, st=0x250f9000, avpkt=<unavailable>, options=<unavailable>) at utils.c:3084:19 frame #5: 0x20a4fe73 libavformat.so.58`avformat_find_stream_info(ic=0x250d7000, options=0x250d61c0) at utils.c:3949:9 frame #6: 0x00418cf6 ffmpeg`open_input_file(o=0xffffd80c, filename=<unavailable>) at ffmpeg_opt.c:1196:15 frame #7: 0x004184c9 ffmpeg`open_files(l=<unavailable>, inout=<unavailable>, open_file=<unavailable>) at ffmpeg_opt.c:3338:15 frame #8: 0x00418278 ffmpeg`ffmpeg_parse_options(argc=<unavailable>, argv=<unavailable>) at ffmpeg_opt.c:3378:11 frame #9: 0x0042e6f0 ffmpeg`main(argc=7, argv=0xffffdc44) at ffmpeg.c:4988:11 frame #10: 0x00417d0d ffmpeg`_start1(cleanup=0x204537e0, argc=7, argv=0xffffdc44) at crt1_c.c:72:7 frame #11: 0x00417e70 ffmpeg`_start at crt1_s.S:46 $ make clean test -C graphics/libavif [...] 45% tests passed, 6 tests failed out of 11 Total Test time (real) = 17.82 sec The following tests FAILED: 1 - aviftest (Bus error) 5 - avifchangesettingtest (Bus error) 6 - avifgridapitest (Bus error) 7 - avifincrtest (Bus error) 8 - avifmetadatatest (Bus error) 11 - test_cmd (Failed) * thread #1, name = 'aviftest', stop reason = signal SIGBUS: hardware error frame #0: 0x207a81f6 libdav1d.so.6`dav1d_data_wrap(buf=0xffffc7d4, ptr="\U00000012", sz=37169, free_callback=(libavif.so.15`avifDav1dFreeCallback at codec_dav1d.c:34), user_data=0x00000000) at lib.c:734 731 void (*const free_callback)(const uint8_t *data, 732 void *user_data), 733 void *const user_data) -> 734 { 735 return dav1d_data_wrap_internal(buf, ptr, sz, free_callback, user_data); 736 } 737 (lldb) bt * thread #1, name = 'aviftest', stop reason = signal SIGBUS: hardware error * frame #0: 0x207a81f6 libdav1d.so.6`dav1d_data_wrap(buf=0xffffc7d4, ptr="\U00000012", sz=37169, free_callback=(libavif.so.15`avifDav1dFreeCallback at codec_dav1d.c:34), user_data=0x00000000) at lib.c:734 frame #1: 0x204746a1 libavif.so.15`dav1dCodecGetNextImage(codec=0x215e9090, decoder=0x2182c000, sample=0x215e9060, alpha=0, isLimitedRangeAlpha=0xffffc93c, image=0x218400a0) at codec_dav1d.c:87:9 frame #2: 0x2045c812 libavif.so.15`avifDecoderDecodeTiles(decoder=0x2182c000, nextImageIndex=0, firstTileIndex=0, tileCount=1, decodedTileCount=0x2183302c) at read.c:3853:14 frame #3: 0x2045bf59 libavif.so.15`avifDecoderNextImage(decoder=0x2182c000) at read.c:3937:9 frame #4: 0x004029a9 aviftest`runIOTests(dataDir="../libavif-0.11.0/tests/data/") at aviftest.c:255:54 frame #5: 0x00402310 aviftest`main(argc=2, argv=0xffffdc0c) at aviftest.c:327:19 frame #6: 0x00401f9d aviftest`_start1(cleanup=0x204157e0, argc=2, argv=0xffffdc0c) at crt1_c.c:72:7 frame #7: 0x00402100 aviftest`_start at crt1_s.S:46 (cherry picked from commit f61964e)

- installing some gemspecs ordinarily installed under ${STAGEDIR}${PREFIX}/lib/ruby/gems/${RUBY_VER}/specifications/default/*.gemspec - installing Ruby and all platform binary scripts under a RUBY_LIBEXEC prefix, with symlinks into host bindir Multiple issues 1) This installation without a version suffix on 'ruby' and other tools may cause issues under gem build reusing features of the original build definition ~~~~ ====> Compressing man pages (compress-man) ===> Building package for ruby30-gems-3.0.8 pkg-static: Unable to access file /usr/home/u1000/wk/dist_wk/ports_main/devel/ruby-gems/work/stage/usr/local/bin/gem30:Nosuch file or directory *** Error code 1 Stop. make[1]: stopped in /usr/home/u1000/wk/dist_wk/ports_main/devel/ruby-gems ~~~~ 2) TBD @ recursive lock error for the 'irb' script as installed under this build configuration cf. Gem.activate_bin_path in /usr/local/lib/ruby/site_ruby/3.0/rubygems.rb under Gem::LOADED_SPECS_MUTEX ... and subsq. loading of gem dependencies, under a single-threaded application ~~~~ [u1000@riparian ~/wk/dist_wk/ports_main/devel/ruby-gems ]$ env RUBYOPT='--debug -W2 -r debug' /usr/local/libexec/ruby/3.0/bin/irb [...] Debug.rb Emacs support available. /usr/local/libexec/ruby/3.0/bin/irb:9:require 'rubygems' (rdb:1) cont [...] Exception `ThreadError' at /usr/local/lib/ruby/site_ruby/3.0/rubygems/core_ext/kernel_gem.rb:67 - deadlock; recursive locking Exception `ThreadError' at /usr/local/lib/ruby/site_ruby/3.0/rubygems/core_ext/kernel_require.rb:45 - deadlock; recursive locking /usr/local/lib/ruby/site_ruby/3.0/rubygems/core_ext/kernel_require.rb:45: `deadlock; recursive locking' (ThreadError) from /usr/local/lib/ruby/site_ruby/3.0/rubygems.rb:306:in `block in activate_bin_path' from /usr/local/lib/ruby/site_ruby/3.0/rubygems.rb:304:in `synchronize' from /usr/local/lib/ruby/site_ruby/3.0/rubygems.rb:304:in `activate_bin_path' from /usr/local/libexec/ruby/3.0/bin/irb:23:in `<main>' /usr/local/lib/ruby/site_ruby/3.0/rubygems/core_ext/kernel_require.rb:45: raise (rdb:1) w --> freebsd#1 /usr/local/lib/ruby/site_ruby/3.0/rubygems/core_ext/kernel_require.rb:45:in `require' freebsd#2 /usr/local/lib/ruby/site_ruby/3.0/rubygems/request_set.rb:2:in `require' freebsd#3 /usr/local/lib/ruby/site_ruby/3.0/rubygems.rb:306:in `activate_bin_path' freebsd#4 /usr/local/libexec/ruby/3.0/bin/irb:23 ~~~ (cherry picked from commit 297b7b7)

https://forums.freebsd.org/threads/vulkan-caps-viewer-segmentation-fault.87083/ $ pkg delete qt5-wayland $ env -u WAYLAND_DISPLAY vulkanCapsViewer Reading extensions Device "Intel(R) HD Graphics 530 (SKL GT2)" Reading Vulkan 1.1 core properties Reading Vulkan 1.2 core properties Reading Vulkan 1.3 core properties Reading layers Reading queue families Reading physical feattures Reading Vulkan 1.1 core features Reading Vulkan 1.2 core features Reading Vulkan 1.3 core features Reading limits Reading memory properties Reading surface info Segmentation fault ```c++ (lldb) bt * thread freebsd#1, name = 'vulkanCapsViewer', stop reason = signal SIGSEGV: invalid address (fault address: 0x18) * frame #0: 0x0000000824ac758e libwayland-client.so.0`wl_proxy_create_wrapper(proxy=0x0000000000000000) at wayland-client.c:2406:37 frame freebsd#1: 0x00000008749dc1ef libvulkan_intel.so`wsi_wl_display_init(wsi_wl=0x000000085c889660, display=0x000000082088e668, wl_display=0x0000000000000000, get_format_list=true, sw=false) at wsi_common_wayland.c:558:34 frame freebsd#2: 0x00000008749dca1b libvulkan_intel.so`wsi_wl_surface_get_formats(icd_surface=0x000000085ca621a0, wsi_device=0x000000085c8beb58, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at wsi_common_wayland.c:779:8 frame freebsd#3: 0x00000008749d16b1 libvulkan_intel.so`wsi_GetPhysicalDeviceSurfaceFormatsKHR(physicalDevice=0x000000085c8be000, _surface=0x000000085ca621a0, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at wsi_common.c:709:11 frame freebsd#4: 0x00000008749ed972 libvulkan_intel.so`vk_tramp_GetPhysicalDeviceSurfaceFormatsKHR(physicalDevice=0x000000085c8be000, surface=0x000000085ca621a0, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at vk_dispatch_trampolines.c:162:12 frame freebsd#5: 0x00000000003bf422 vulkanCapsViewer`VulkanSurfaceInfo::get(this=0x000000085c978348, device=0x000000085ca7a280, surface=0x000000085c8892a0) at vulkansurfaceinfo.hpp:61:13 frame freebsd#6: 0x000000000039d67b vulkanCapsViewer`VulkanDeviceInfo::readSurfaceInfo(this=0x000000085c977c00, surface=0x000000085c8892a0, surfaceExtension="VK_KHR_wayland_surface") at vulkanDeviceInfo.cpp:760:17 frame freebsd#7: 0x00000000002fc8da vulkanCapsViewer`VulkanCapsViewer::getGPUinfo(this=0x000000082088f448, GPU=0x000000085c977c00, id=0, device=0x000000085ca7a280) at vulkancapsviewer.cpp:809:10 frame freebsd#8: 0x00000000002f792b vulkanCapsViewer`VulkanCapsViewer::getGPUs(this=0x000000082088f448) at vulkancapsviewer.cpp:902:9 frame freebsd#9: 0x00000000002f6317 vulkanCapsViewer`VulkanCapsViewer::VulkanCapsViewer(this=0x000000082088f448, parent=0x0000000000000000) at vulkancapsviewer.cpp:262:5 frame freebsd#10: 0x00000000002a438d vulkanCapsViewer`main(argc=1, argv=0x000000082088fc68) at main.cpp:93:22 frame freebsd#11: 0x000000000029c2d0 vulkanCapsViewer`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 ```

https://forums.freebsd.org/threads/vulkan-caps-viewer-segmentation-fault.87083/ $ pkg delete qt5-wayland $ env -u WAYLAND_DISPLAY vulkanCapsViewer Reading extensions Device "Intel(R) HD Graphics 530 (SKL GT2)" Reading Vulkan 1.1 core properties Reading Vulkan 1.2 core properties Reading Vulkan 1.3 core properties Reading layers Reading queue families Reading physical feattures Reading Vulkan 1.1 core features Reading Vulkan 1.2 core features Reading Vulkan 1.3 core features Reading limits Reading memory properties Reading surface info Segmentation fault ```c++ (lldb) bt * thread #1, name = 'vulkanCapsViewer', stop reason = signal SIGSEGV: invalid address (fault address: 0x18) * frame #0: 0x0000000824ac758e libwayland-client.so.0`wl_proxy_create_wrapper(proxy=0x0000000000000000) at wayland-client.c:2406:37 frame #1: 0x00000008749dc1ef libvulkan_intel.so`wsi_wl_display_init(wsi_wl=0x000000085c889660, display=0x000000082088e668, wl_display=0x0000000000000000, get_format_list=true, sw=false) at wsi_common_wayland.c:558:34 frame #2: 0x00000008749dca1b libvulkan_intel.so`wsi_wl_surface_get_formats(icd_surface=0x000000085ca621a0, wsi_device=0x000000085c8beb58, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at wsi_common_wayland.c:779:8 frame #3: 0x00000008749d16b1 libvulkan_intel.so`wsi_GetPhysicalDeviceSurfaceFormatsKHR(physicalDevice=0x000000085c8be000, _surface=0x000000085ca621a0, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at wsi_common.c:709:11 frame #4: 0x00000008749ed972 libvulkan_intel.so`vk_tramp_GetPhysicalDeviceSurfaceFormatsKHR(physicalDevice=0x000000085c8be000, surface=0x000000085ca621a0, pSurfaceFormatCount=0x000000082088e7c0, pSurfaceFormats=0x0000000000000000) at vk_dispatch_trampolines.c:162:12 frame #5: 0x00000000003bf422 vulkanCapsViewer`VulkanSurfaceInfo::get(this=0x000000085c978348, device=0x000000085ca7a280, surface=0x000000085c8892a0) at vulkansurfaceinfo.hpp:61:13 frame #6: 0x000000000039d67b vulkanCapsViewer`VulkanDeviceInfo::readSurfaceInfo(this=0x000000085c977c00, surface=0x000000085c8892a0, surfaceExtension="VK_KHR_wayland_surface") at vulkanDeviceInfo.cpp:760:17 frame #7: 0x00000000002fc8da vulkanCapsViewer`VulkanCapsViewer::getGPUinfo(this=0x000000082088f448, GPU=0x000000085c977c00, id=0, device=0x000000085ca7a280) at vulkancapsviewer.cpp:809:10 frame #8: 0x00000000002f792b vulkanCapsViewer`VulkanCapsViewer::getGPUs(this=0x000000082088f448) at vulkancapsviewer.cpp:902:9 frame #9: 0x00000000002f6317 vulkanCapsViewer`VulkanCapsViewer::VulkanCapsViewer(this=0x000000082088f448, parent=0x0000000000000000) at vulkancapsviewer.cpp:262:5 frame #10: 0x00000000002a438d vulkanCapsViewer`main(argc=1, argv=0x000000082088fc68) at main.cpp:93:22 frame #11: 0x000000000029c2d0 vulkanCapsViewer`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 ``` (cherry picked from commit 387f99b)

$ echo 'exec swaymsg -t get_outputs' >/tmp/sway.conf $ WLR_BACKENDS=headless sway -c /tmp/sway.conf 00:00:00.067 [wlr] [types/wlr_drm_lease_v1.c:716] No DRM backend supplied, failed to create wlr_drm_lease_v1_manager 00:00:00.000 [common/ipc-client.c:87] Unable to receive IPC response Segmentation fault (lldb) bt * thread #1, name = 'sway', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x000000082b381e84 libc.so.7`strlen + 84 frame #1: 0x0000000822cc530d libjson-c.so.5`json_object_new_string(s=0x0000000000000000) at json_object.c:1276:36 frame #2: 0x0000000000234de9 sway`ipc_json_describe_output(output=0x0000000871982200, object=0x00000008755e63b0) at ipc-json.c:255:4 frame #3: 0x000000000023441f sway`ipc_json_describe_node(node=0x0000000871982200) at ipc-json.c:707:3 frame #4: 0x0000000000239d07 sway`ipc_client_handle_command(client=0x000000084e3a1380, payload_length=0, payload_type=IPC_GET_OUTPUTS) at ipc-server.c:672:31 frame #5: 0x00000000002397fa sway`ipc_client_handle_readable(client_fd=27, mask=1, data=0x000000084e3a1380) at ipc-server.c:267:3 frame #6: 0x00000008271b88c7 libwayland-server.so.0`wl_event_source_fd_dispatch(source=0x000000084e3a16c0, ep=0x0000000820f4e360) at event-loop.c:112:9 frame #7: 0x00000008271b9fd4 libwayland-server.so.0`wl_event_loop_dispatch(loop=0x000000084e344320, timeout=-1) at event-loop.c:1027:4 frame #8: 0x00000008271b5c6f libwayland-server.so.0`wl_display_run(display=0x000000084e35e000) at wayland-server.c:1431:3 frame #9: 0x000000000023e205 sway`server_run(server=0x00000000002a3070) at server.c:310:2 frame #10: 0x000000000023cd84 sway`main(argc=3, argv=0x0000000820f4e608) at main.c:431:2 frame #11: 0x000000000022ca10 sway`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 (lldb) f 2 frame #2: 0x0000000000234de9 sway`ipc_json_describe_output(output=0x0000000871982200, object=0x00000008755e63b0) at ipc-json.c:255:4 252 json_object_new_string( 253 ipc_json_orientation_description(L_NONE))); 254 json_object_object_add(object, "make", -> 255 json_object_new_string(wlr_output->make)); 256 json_object_object_add(object, "model", 257 json_object_new_string(wlr_output->model)); 258 json_object_object_add(object, "serial", (lldb) p *wlr_output (wlr_output) $0 = { [...] make = 0x0000000000000000 model = 0x0000000000000000 serial = 0x0000000000000000 [...] PR: 267853 Reported by: lbartoletti Regressed by: https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/be86145322e6

$ mpv --vo=gpu-next foo.mp4 [...] Segmentation fault (lldb) bt * thread #10, name = 'mpv/vo', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x000000083b4c8e84 libc.so.7`strlen + 84 frame #1: 0x000000083b4996bd libc.so.7`vsscanf + 173 frame #2: 0x000000083b48c72d libc.so.7`sscanf + 141 frame #3: 0x00000000004c0dd4 mpv`gl_parse_3dlut_size(arg=0x0000000000000000, p1=0x000000088fcf7d3c, p2=0x000000088fcf7d38, p3=0x000000088fcf7d34) at lcms.h:45:9 frame #4: 0x00000000004c085b mpv`update_icc_opts(p=0x00000008792f9b10, opts=0x0000000891370050) at vo_gpu_next.c:1619:5 frame #5: 0x00000000004c00ef mpv`update_render_options(vo=0x0000000875b38910) at vo_gpu_next.c:1863:5 frame #6: 0x00000000004bde05 mpv`preinit(vo=0x0000000875b38910) at vo_gpu_next.c:1426:5 frame #7: 0x000000000048cc99 mpv`vo_thread(ptr=0x0000000875b38910) at vo.c:1088:13 frame #8: 0x000000083bc4783a libthr.so.3`___lldb_unnamed_symbol556 + 314

During an exp-run for llvm 15 (see bug 265425), it turned out that databases/db5 failed to build with clang 15. This is caused by db5's configure script attempting to detect TLS but encountering internal compiler errors while compiling its test cases, and then concluding TLS does not work at all: ... checking whether C++ supports the wstring class... checking for thread local storage (TLS) class... none ... in config.log it shows what is happening: configure:19128: checking for thread local storage (TLS) class configure:19164: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5 conftest.cpp:30:72: error: use of undeclared identifier 'NULL' template<typename T> __thread T* TLSClass<T>::tlsvar = NULL; ^ Assertion failed: (!isValueDependent() && "Expression evaluator can't be called on a dependent expression."), function isConstantInitializer, file /usr/src/contrib/llvm-project/clang/lib/AST/Expr.cpp, line 3184. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp 1. conftest.cpp:30:76: current parser token ';' #0 0x00000000053fec51 PrintStackTrace #/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:13 #1 0x00000000053fcf35 RunSignalHandlers #/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:104:18 #2 0x00000000053a591e HandleCrash #/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5 #3 0x00000000053a5ae3 CrashRecoverySignalHandler #/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51 #4 0x0000000006a1b05e handle_signal #/usr/src/lib/libthr/thread/thr_sig.c:0:3 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) Interestingly enough this compilation error with a fatal crash exists for a very long time, even back to clang 10 and earlier! But for various reasons the configure script has always ignored these errors and found some workaround way to enable TLS anyway. For now the problem can be fixed by including <stddef.h> at the top of conftest.cpp, which will allow the TLS test to succeed normally, without crashing, and the correct result will then be: configure:19128: checking for thread local storage (TLS) class configure:19165: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5 conftest.cpp:33:35: warning: unused variable 'x' [-Wunused-variable] static __thread int x = 0; ^ 1 warning generated. configure:19165: $? = 0 configure:19220: result: modifier PR: 267156 Approved by: maintainer timeout (>1 month) MFH: 2022Q4

FAILED: rpcs3/Emu/CMakeFiles/rpcs3_emu.dir/Cell/lv2/sys_net/lv2_socket_p2p.cpp.o [...] 1. <eof> parser at end of file #0 0x000000082c9b0ac9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm15/lib/libLLVM-15.so+0x33b0ac9) #1 0x000000082c9aeca5 llvm::sys::RunSignalHandlers() (/usr/local/llvm15/lib/libLLVM-15.so+0x33aeca5) #2 0x000000082c8d00c5 (/usr/local/llvm15/lib/libLLVM-15.so+0x32d00c5) #3 0x0000000822fadc60 (/lib/libthr.so.3+0x14c60) clang-15: error: clang frontend command failed with exit code 139 (use -v to see invocation) clang version 15.0.6 Target: x86_64-portbld-freebsd12.3 Thread model: posix InstalledDir: /usr/local/llvm15/bin Reported by: pkg-fallout This reverts commit 8bc04d7.

$ turbostat turbostat version 17.06.23 - Len Brown <lenb@kernel.org> Segmentation fault * thread #1, name = 'turbostat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0000000000216992 turbostat`topology_probe at turbostat.c:4685:7 4682 * Validate that all cpus in cpu_subset are also in cpu_present_set 4683 */ 4684 for (i = 0; i < CPU_SUBSET_MAXCPUS; ++i) { -> 4685 if (CPU_ISSET_S(i, cpu_subset_size, cpu_subset)) 4686 if (!CPU_ISSET_S(i, cpu_present_setsize, cpu_present_set)) 4687 err(1, "cpu%d not present", i); 4688 } (lldb) bt * thread #1, name = 'turbostat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x0000000000216992 turbostat`topology_probe at turbostat.c:4685:7 frame #1: 0x00000000002111c9 turbostat`setup_all_buffers at turbostat.c:4853:2 frame #2: 0x0000000000217909 turbostat`turbostat_init at turbostat.c:4888:2 frame #3: 0x0000000000218f3f turbostat`main(argc=1, argv=0x0000000820444710) at turbostat.c:5447:2 frame #4: 0x0000000000207160 turbostat`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:73:7 (lldb) p cpu_subset (cpu_set_t *) $0 = NULL PR: 262866

$ turbostat turbostat version 17.06.23 - Len Brown <lenb@kernel.org> Segmentation fault * thread #1, name = 'turbostat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0000000000216992 turbostat`topology_probe at turbostat.c:4685:7 4682 * Validate that all cpus in cpu_subset are also in cpu_present_set 4683 */ 4684 for (i = 0; i < CPU_SUBSET_MAXCPUS; ++i) { -> 4685 if (CPU_ISSET_S(i, cpu_subset_size, cpu_subset)) 4686 if (!CPU_ISSET_S(i, cpu_present_setsize, cpu_present_set)) 4687 err(1, "cpu%d not present", i); 4688 } (lldb) bt * thread #1, name = 'turbostat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x0000000000216992 turbostat`topology_probe at turbostat.c:4685:7 frame #1: 0x00000000002111c9 turbostat`setup_all_buffers at turbostat.c:4853:2 frame #2: 0x0000000000217909 turbostat`turbostat_init at turbostat.c:4888:2 frame #3: 0x0000000000218f3f turbostat`main(argc=1, argv=0x0000000820444710) at turbostat.c:5447:2 frame #4: 0x0000000000207160 turbostat`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:73:7 (lldb) p cpu_subset (cpu_set_t *) $0 = NULL PR: 262866 (cherry picked from commit b27279c)

$ baka-mplayer Segmentation fault * thread #1, name = 'baka-mplayer', stop reason = signal SIGBUS: hardware error frame #0: 0x0000000820df9a52 libX11.so.6`_XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0, psig=0x000000082092bd70, pidx=0x000000082092bd6c, pn=0x000000082092bd68) at IntAtom.c:86:30 83 if (atoms) { 84 firstidx = idx = HASH(sig); 85 while ((e = atoms->table[idx])) { -> 86 if (e != RESERVED && e->sig == sig) { 87 for (i = n, s1 = (char *)name, s2 = EntryName(e); --i >= 0; ) { 88 if (*s1++ != *s2++) 89 goto nomatch; (lldb) bt * thread #1, name = 'baka-mplayer', stop reason = signal SIGBUS: hardware error * frame #0: 0x0000000820df9a52 libX11.so.6`_XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0, psig=0x000000082092bd70, pidx=0x000000082092bd6c, pn=0x000000082092bd68) at IntAtom.c:86:30 frame #1: 0x0000000820df97d9 libX11.so.6`XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0) at IntAtom.c:176:17 frame #2: 0x0000000000263695 baka-mplayer`Util::DimLightsSupported() at linux.cpp:28:14 frame #3: 0x000000000026c71a baka-mplayer`BakaEngine::BakaEngine(this=0x00000008a964bd00, parent=0x000000082092fe10) at bakaengine.cpp:31:8 frame #4: 0x00000000002b1739 baka-mplayer`MainWindow::MainWindow(this=0x000000082092fe10, parent=0x0000000000000000) at mainwindow.cpp:31:16 frame #5: 0x00000000002648ec baka-mplayer`main(argc=1, argv=0x000000082092ff48) at main.cpp:21:16 frame #6: 0x00000000002633a0 baka-mplayer`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7 (cherry picked from commit 7a77117)

$ baka-mplayer Segmentation fault * thread #1, name = 'baka-mplayer', stop reason = signal SIGBUS: hardware error frame #0: 0x0000000820df9a52 libX11.so.6`_XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0, psig=0x000000082092bd70, pidx=0x000000082092bd6c, pn=0x000000082092bd68) at IntAtom.c:86:30 83 if (atoms) { 84 firstidx = idx = HASH(sig); 85 while ((e = atoms->table[idx])) { -> 86 if (e != RESERVED && e->sig == sig) { 87 for (i = n, s1 = (char *)name, s2 = EntryName(e); --i >= 0; ) { 88 if (*s1++ != *s2++) 89 goto nomatch; (lldb) bt * thread #1, name = 'baka-mplayer', stop reason = signal SIGBUS: hardware error * frame #0: 0x0000000820df9a52 libX11.so.6`_XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0, psig=0x000000082092bd70, pidx=0x000000082092bd6c, pn=0x000000082092bd68) at IntAtom.c:86:30 frame #1: 0x0000000820df97d9 libX11.so.6`XInternAtom(dpy=0x000000088683af00, name="_NET_WM_CM_S0", onlyIfExists=0) at IntAtom.c:176:17 frame #2: 0x0000000000263695 baka-mplayer`Util::DimLightsSupported() at linux.cpp:28:14 frame #3: 0x000000000026c71a baka-mplayer`BakaEngine::BakaEngine(this=0x00000008a964bd00, parent=0x000000082092fe10) at bakaengine.cpp:31:8 frame #4: 0x00000000002b1739 baka-mplayer`MainWindow::MainWindow(this=0x000000082092fe10, parent=0x0000000000000000) at mainwindow.cpp:31:16 frame #5: 0x00000000002648ec baka-mplayer`main(argc=1, argv=0x000000082092ff48) at main.cpp:21:16 frame #6: 0x00000000002633a0 baka-mplayer`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

Fixed in LLVM 16: fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/c++ -DQT_CORE_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_NO_KEYWORDS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_TESTCASE_BUILDDIR=\"/wrkdirs/usr/ports/devel/qcoro/work-qt5/.build\" -DQT_TESTLIB_LIB -DQT_USE_STRINGBUILDER -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/.build/tests/test-qcorosignal_autogen/include -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/tests/testlibs -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0 -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/qcoro -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/qcoro/core -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/.build/qcoro/core -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/.build/qcoro -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/qcoro/test -I/wrkdirs/usr/ports/devel/qcoro/work-qt5/.build/qcoro/test -isystem /usr/local/include/qt5 -isystem /usr/local/include/qt5/QtCore -isystem /usr/local/lib/qt5/mkspecs/freebsd-clang -isystem /usr/local/include/qt5/QtTest -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fcoroutines-ts -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=gnu++20 -fPIC -pthread -MD -MT tests/CMakeFiles/test-qcorosignal.dir/qcorosignal.cpp.o -MF tests/CMakeFiles/test-qcorosignal.dir/qcorosignal.cpp.o.d -o tests/CMakeFiles/test-qcorosignal.dir/qcorosignal.cpp.o -c /wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/tests/qcorosignal.cpp 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/wrkdirs/usr/ports/devel/qcoro/work-qt5/qcoro-0.9.0/tests/qcorosignal.cpp'. 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@_ZZ19qCoroSignalListenerI15MultiSignalTestM10SignalTestFvvEEN5QCoro14AsyncGeneratorINS4_6detail16QCoroSignalQueueIT_T0_E11result_type10value_typeEEEPS8_OS9_NSt3__16chrono8durationIxNSF_5ratioILl1ELl1000EEEEEENKUlNSF_10unique_ptrINS7_IS0_S3_EENSF_14default_deleteISM_EEEEE_clESP_.resume' #0 0x0000000014b1252c (/usr/bin/c+++0x14b1252c) #1 0x0000000014b0fd00 (/usr/bin/c+++0x14b0fd00) #2 0x0000000014aab0cc (/usr/bin/c+++0x14aab0cc) #3 0x0000000014aab020 (/usr/bin/c+++0x14aab020) #4 0x0000000014afc590 (/usr/bin/c+++0x14afc590) #5 0x00000000117cd530 (/usr/bin/c+++0x117cd530) #6 0x0000000014ab4fe0 (/usr/bin/c+++0x14ab4fe0) #7 0x0000000014ab4e6c (/usr/bin/c+++0x14ab4e6c) #8 0x00000000154bd3f0 (/usr/bin/c+++0x154bd3f0) #9 0x0000000014d5f9d0 (/usr/bin/c+++0x14d5f9d0) c++: error: clang frontend command failed with exit code 70 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: powerpc64le-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/qcorosignal-479743.cpp c++: note: diagnostic msg: /tmp/qcorosignal-479743.sh c++: note: diagnostic msg: ********************

Fixed in LLVM 16: /usr/bin/c++ -DCRCPP_EXPORT_API -Dconcurrencpp_EXPORTS -isystem /wrkdirs/usr/ports/devel/concurrencpp/work/concurrencpp-v.0.1.6/include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=c++20 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -pthread -MD -MT CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o -MF CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o.d -o CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o -c /wrkdirs/usr/ports/devel/concurrencpp/work/concurrencpp-v.0.1.6/source/timers/timer_queue.cpp fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/c++ -DCRCPP_EXPORT_API -Dconcurrencpp_EXPORTS -isystem /wrkdirs/usr/ports/devel/concurrencpp/work/concurrencpp-v.0.1.6/include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=c++20 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -pthread -MD -MT CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o -MF CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o.d -o CMakeFiles/concurrencpp.dir/source/timers/timer_queue.cpp.o -c /wrkdirs/usr/ports/devel/concurrencpp/work/concurrencpp-v.0.1.6/source/timers/timer_queue.cpp 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/wrkdirs/usr/ports/devel/concurrencpp/work/concurrencpp-v.0.1.6/source/timers/timer_queue.cpp'. 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@_ZN12concurrencpp11timer_queue22make_delay_object_implENSt3__16chrono8durationIxNS1_5ratioILl1ELl1000EEEEENS1_10shared_ptrIS0_EENS7_INS_8executorEEE.resume' #0 0x0000000014b1252c (/usr/bin/c+++0x14b1252c) #1 0x0000000014b0fd00 (/usr/bin/c+++0x14b0fd00) #2 0x0000000014aab0cc (/usr/bin/c+++0x14aab0cc) #3 0x0000000014aab020 (/usr/bin/c+++0x14aab020) #4 0x0000000014afc590 (/usr/bin/c+++0x14afc590) #5 0x00000000117cd530 (/usr/bin/c+++0x117cd530) #6 0x0000000014ab4fe0 (/usr/bin/c+++0x14ab4fe0) #7 0x0000000014ab4e6c (/usr/bin/c+++0x14ab4e6c) #8 0x00000000154bd3f0 (/usr/bin/c+++0x154bd3f0) #9 0x0000000014d5f9d0 (/usr/bin/c+++0x14d5f9d0) c++: error: clang frontend command failed with exit code 70 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: powerpc64le-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin

Use newer LLVM: fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/c++ -DHAVE_COLORSCHEME -DHAVE_KDBUSADDONS -DHAVE_KIO -DHAVE_RUNNER -DHAVE_WINDOWSYSTEM -DHAVE_X11 -DKCOREADDONS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -DQUOTIENT_07 -DQUOTIENT_STATIC -DQuotient_VERSION_MAJOR=0 -DQuotient_VERSION_MINOR=7 -DQuotient_VERSION_PATCH=1 -DQuotient_VERSION_STRING=\"0.7.1\" -D_LARGEFILE64_SOURCE -I/wrkdirs/usr/ports/net-im/neochat/work/.build/src -I/wrkdirs/usr/ports/net-im/neochat/work/neochat-23.04.1/src -I/wrkdirs/usr/ports/net-im/neochat/work/.build/src/neochat_autogen/include -I/wrkdirs/usr/ports/net-im/neochat/work/.build -isystem /usr/local/include/KF5/KConfigWidgets -isystem /usr/local/include/KF5 -isystem /usr/local/include/KF5/KWidgetsAddons -isystem /usr/local/include/qt5 -isystem /usr/local/include/qt5/QtWidgets -isystem /usr/local/include/qt5/QtGui -isystem /usr/local/include -isystem /usr/local/include/qt5/QtCore -isystem /usr/local/lib/qt5/mkspecs/freebsd-clang -isystem /usr/local/include/KF5/KConfig -isystem /usr/local/include/KF5/KConfigGui -isystem /usr/local/include/qt5/QtXml -isystem /usr/local/include/KF5/KConfigCore -isystem /usr/local/include/KF5/KCoreAddons -isystem /usr/local/include/KF5/KCodecs -isystem /usr/local/include/KF5/KAuthWidgets -isystem /usr/local/include/KF5/KAuthCore -isystem /usr/local/include/KF5/KAuth -isystem /usr/local/include/KF5/KWindowSystem -isystem /usr/local/include/qt5/QtQuick -isystem /usr/local/include/qt5/QtQmlModels -isystem /usr/local/include/qt5/QtQml -isystem /usr/local/include/qt5/QtNetwork -isystem /usr/local/include/qt5/QtMultimedia -isystem /usr/local/include/qt5/QtQuickControls2 -isystem /usr/local/include/KF5/KI18n -isystem /usr/local/include/KF5/Kirigami2 -isystem /usr/local/include/KF5/KNotifications -isystem /usr/local/include/qt5/QtDBus -isystem /usr/local/include/KF5/SonnetCore -isystem /usr/local/include/KF5/Sonnet -isystem /usr/local/include/KF5/KItemModels -isystem /usr/local/include/Quotient -isystem /usr/local/include/qcoro5 -isystem /usr/local/include/qcoro5/qcoro -isystem /usr/local/include/qcoro5/QCoro -isystem /usr/local/include/KF5/KIOWidgets -isystem /usr/local/include/KF5/KIOGui -isystem /usr/local/include/KF5/KIOCore -isystem /usr/local/include/KF5/KIO -isystem /usr/local/include/KF5/KService -isystem /usr/local/include/qt5/QtConcurrent -isystem /usr/local/include/KF5/KJobWidgets -isystem /usr/local/include/KF5/Solid -isystem /usr/local/include/KF5/KCompletion -isystem /usr/local/include/KF5/KDBusAddons -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fno-operator-names -fno-exceptions -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -fdiagnostics-color=always -fcoroutines-ts -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=gnu++20 -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -MD -MT src/CMakeFiles/neochat.dir/neochatroom.cpp.o -MF src/CMakeFiles/neochat.dir/neochatroom.cpp.o.d -o src/CMakeFiles/neochat.dir/neochatroom.cpp.o -c /wrkdirs/usr/ports/net-im/neochat/work/neochat-23.04.1/src/neochatroom.cpp 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/wrkdirs/usr/ports/net-im/neochat/work/neochat-23.04.1/src/neochatroom.cpp'. 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@_Z5qCoroI12QMediaPlayerMS0_FvNS0_11MediaStatusEEEN5QCoro4TaskINS4_6detail11QCoroSignalIT_T0_E11result_typeEEEPS8_OS9_NSt3__16chrono8durationIxNSF_5ratioILl1ELl1000EEEEE.resume' #0 0x0000000014b1252c (/usr/bin/c+++0x14b1252c) #1 0x0000000014b0fd00 (/usr/bin/c+++0x14b0fd00) #2 0x0000000014aab0cc (/usr/bin/c+++0x14aab0cc) #3 0x0000000014aab020 (/usr/bin/c+++0x14aab020) #4 0x0000000014afc590 (/usr/bin/c+++0x14afc590) #5 0x00000000117cd530 (/usr/bin/c+++0x117cd530) #6 0x0000000014ab4fe0 (/usr/bin/c+++0x14ab4fe0) #7 0x0000000014ab4e6c (/usr/bin/c+++0x14ab4e6c) #8 0x00000000154bd3f0 (/usr/bin/c+++0x154bd3f0) #9 0x0000000014d5f9d0 (/usr/bin/c+++0x14d5f9d0) c++: error: clang frontend command failed with exit code 70 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: powerpc64le-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg:

During an exp-run for llvm 15 (see bug 265425), it turned out that databases/db5 failed to build with clang 15. This is caused by db5's configure script attempting to detect TLS but encountering internal compiler errors while compiling its test cases, and then concluding TLS does not work at all: ... checking whether C++ supports the wstring class... checking for thread local storage (TLS) class... none ... in config.log it shows what is happening: configure:19128: checking for thread local storage (TLS) class configure:19164: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5 conftest.cpp:30:72: error: use of undeclared identifier 'NULL' template<typename T> __thread T* TLSClass<T>::tlsvar = NULL; ^ Assertion failed: (!isValueDependent() && "Expression evaluator can't be called on a dependent expression."), function isConstantInitializer, file /usr/src/contrib/llvm-project/clang/lib/AST/Expr.cpp, line 3184. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp 1. conftest.cpp:30:76: current parser token ';' #0 0x00000000053fec51 PrintStackTrace #/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:13 freebsd#1 0x00000000053fcf35 RunSignalHandlers #/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:104:18 freebsd#2 0x00000000053a591e HandleCrash #/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5 freebsd#3 0x00000000053a5ae3 CrashRecoverySignalHandler #/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51 freebsd#4 0x0000000006a1b05e handle_signal #/usr/src/lib/libthr/thread/thr_sig.c:0:3 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) Interestingly enough this compilation error with a fatal crash exists for a very long time, even back to clang 10 and earlier! But for various reasons the configure script has always ignored these errors and found some workaround way to enable TLS anyway. For now the problem can be fixed by including <stddef.h> at the top of conftest.cpp, which will allow the TLS test to succeed normally, without crashing, and the correct result will then be: configure:19128: checking for thread local storage (TLS) class configure:19165: c++ -c -O2 -pipe -Wall -Wextra -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE conftest.cpp >&5 conftest.cpp:33:35: warning: unused variable 'x' [-Wunused-variable] static __thread int x = 0; ^ 1 warning generated. configure:19165: $? = 0 configure:19220: result: modifier PR: 267156 Approved by: maintainer timeout (>1 month) MFH: 2022Q4

$ mono foo Segmentation fault * thread #1, name = 'mono-sgen', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x00000000005632f9 mono`mono_arch_create_sdb_trampoline(single_step=0, info=0x0000000820fe7d90, aot=0) at tramp-amd64.c:854:2 851 // IP saved at CFA - 8 852 mono_add_unwind_op_offset (unwind_ops, code, buf, AMD64_RIP, -cfa_offset); 853 -> 854 amd64_push_reg (code, AMD64_RBP); 855 cfa_offset += sizeof(mgreg_t); 856 mono_add_unwind_op_def_cfa_offset (unwind_ops, code, buf, cfa_offset); 857 mono_add_unwind_op_offset (unwind_ops, code, buf, AMD64_RBP, - cfa_offset); (lldb) bt * thread #1, name = 'mono-sgen', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x00000000005632f9 mono`mono_arch_create_sdb_trampoline(single_step=0, info=0x0000000820fe7d90, aot=0) at tramp-amd64.c:854:2 frame #1: 0x000000000047cf36 mono`mini_get_breakpoint_trampoline at mini-trampolines.c:1812:12 frame #2: 0x00000000004dc5a1 mono`mono_arch_init at mini-amd64.c:1405:19 frame #3: 0x000000000035fde4 mono`mini_init(filename="foo", runtime_version=0x0000000000000000) at mini-runtime.c:4364:2 frame #4: 0x0000000000426853 mono`mono_main(argc=2, argv=0x0000000820fe8268) at driver.c:2470:11 frame #5: 0x0000000000359363 mono`mono_main_with_options(argc=2, argv=0x0000000820fe8268) at main.c:50:9 frame #6: 0x00000000003589b1 mono`main(argc=2, argv=0x0000000820fe8268) at main.c:406:9 frame #7: 0x0000000000358770 mono`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7

$ vkcube-wayland Selected GPU 0: Intel(R) HD Graphics 530 (SKL GT2), type: IntegratedGpu Segmentation fault (lldb) bt * thread #1, name = 'vkcube-wayland', stop reason = signal SIGSEGV: invalid address (fault address: 0x40) * frame #0: 0x000000082114a4dc libwayland-client.so`wl_proxy_get_version(proxy=0x0000000000000000) at wayland-client.c:2248:16 frame #1: 0x000000082b8543e1 libvulkan_intel.so`wp_tearing_control_manager_v1_get_tearing_control(wp_tearing_control_manager_v1=0x0000000000000000, surface=0x0000245a71e110a0) at tearing-control-v1-client-protocol.h:191:90 frame #2: 0x000000082b852016 libvulkan_intel.so`wsi_wl_surface_create_swapchain(icd_surface=0x0000245a71e32e00, device=0x0000245a71f47400, wsi_device=0x0000245a71eb1ae0, pCreateInfo=0x0000000820617900, pAllocator=0x0000245a71f47440, swapchain_out=0x00000008206178d8) at wsi_common_wayland.c:2277:10 frame #3: 0x000000082b842be4 libvulkan_intel.so`wsi_CreateSwapchainKHR(_device=0x0000245a71f47400, pCreateInfo=0x0000000820617900, pAllocator=0x0000000000000000, pSwapchain=0x0000000820618700) at wsi_common.c:930:22 frame #4: 0x0000000822051bef libvulkan.so.1`terminator_CreateSwapchainKHR + 223 frame #5: 0x000000000021136b vkcube-wayland`demo_prepare_buffers(demo=0x0000000820617c30) at cube.c:1408:11 frame #6: 0x000000000020c679 vkcube-wayland`demo_prepare(demo=0x0000000820617c30) at cube.c:2302:5 frame #7: 0x000000000020af7a vkcube-wayland`main(argc=1, argv=0x0000000820618a38) at cube.c:4592:5 frame #8: 0x000000082356e5fa libc.so.7`__libc_start1(argc=1, argv=0x0000000820618a38, env=0x0000000820618a48, cleanup=<unavailable>, mainX=(vkcube-wayland`main at cube.c:4574)) at libc_start1.c:157:7 frame #9: 0x00000000002085d0 vkcube-wayland`_start at crt1_s.S:83 (lldb) f 2 frame #2: 0x000000082b852016 libvulkan_intel.so`wsi_wl_surface_create_swapchain(icd_surface=0x0000245a71e32e00, device=0x0000245a71f47400, wsi_device=0x0000245a71eb1ae0, pCreateInfo=0x0000000820617900, pAllocator=0x0000245a71f47440, swapchain_out=0x00000008206178d8) at wsi_common_wayland.c:2277:10 2274 2275 if (chain->base.present_mode == VK_PRESENT_MODE_IMMEDIATE_KHR) { 2276 chain->tearing_control = -> 2277 wp_tearing_control_manager_v1_get_tearing_control(wsi_wl_surface->display->tearing_control_manager, 2278 wsi_wl_surface->surface); 2279 if (!chain->tearing_control) { 2280 result = VK_ERROR_OUT_OF_HOST_MEMORY; (lldb) p wsi_wl_surface->display->tearing_control_manager (wp_tearing_control_manager_v1 *) $0 = NULL

$ arcan console pid 12345 (arcan), jid 0, uid 1111: exited on signal 6 (no core dump - bad address) $ tail -1 /var/log/messages Sep 29 22:48:36 localhost arcan[12345]: stack overflow detected; terminated (lldb) bt * thread #2, name = 'arcan', stop reason = signal SIGABRT * frame #0: 0x00000008277faf5a libc.so.7`__sys_kill at kill.S:4 frame #1: 0x00000008277fe361 libc.so.7`__fail(msg="stack overflow detected; terminated") at stack_protector.c:120:8 frame #2: 0x00000008277fe2d0 libc.so.7`__stack_chk_fail at stack_protector.c:127:2 frame #3: 0x00000000002eb876 arcan`button_count(fd=5, bitn=1, got_mouse=0x000000082040a5cf, got_joy=0x000000082040a5ce) at event.c:0 (lldb) f 3 frame #3: 0x00000000002eb876 arcan`button_count(fd=5, bitn=1, got_mouse=0x000000082040a5cf, got_joy=0x000000082040a5ce) at event.c:0 844 #define bit_isset(ary, bit) (( ary[bit_longn(bit)] >> bit_ofs(bit)) & 1) 845 #define bit_count(x) ( ((x) - 1 ) / (sizeof(long) * 8 ) + 1 ) 846 -> 847 static size_t button_count(int fd, size_t bitn, bool* got_mouse, bool* got_joy) 848 { 849 size_t count = 0; 850 PR: 274163 Reported by: Albin "a12l" Otterhäll (cherry picked from commit 2258b3e)

$ arcan console pid 12345 (arcan), jid 0, uid 1111: exited on signal 6 (no core dump - bad address) $ tail -1 /var/log/messages Sep 29 22:48:36 localhost arcan[12345]: stack overflow detected; terminated (lldb) bt * thread #2, name = 'arcan', stop reason = signal SIGABRT * frame #0: 0x00000008277faf5a libc.so.7`__sys_kill at kill.S:4 frame #1: 0x00000008277fe361 libc.so.7`__fail(msg="stack overflow detected; terminated") at stack_protector.c:120:8 frame #2: 0x00000008277fe2d0 libc.so.7`__stack_chk_fail at stack_protector.c:127:2 frame #3: 0x00000000002eb876 arcan`button_count(fd=5, bitn=1, got_mouse=0x000000082040a5cf, got_joy=0x000000082040a5ce) at event.c:0 (lldb) f 3 frame #3: 0x00000000002eb876 arcan`button_count(fd=5, bitn=1, got_mouse=0x000000082040a5cf, got_joy=0x000000082040a5ce) at event.c:0 844 #define bit_isset(ary, bit) (( ary[bit_longn(bit)] >> bit_ofs(bit)) & 1) 845 #define bit_count(x) ( ((x) - 1 ) / (sizeof(long) * 8 ) + 1 ) 846 -> 847 static size_t button_count(int fd, size_t bitn, bool* got_mouse, bool* got_joy) 848 { 849 size_t count = 0; 850 PR: 274163 Reported by: Albin "a12l" Otterhäll

* thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 87 static void dmabufFeedbackMainDevice(void* data, zwp_linux_dmabuf_feedback_v1* feedback, wl_array* device_arr) { 88 Debug::log(LOG, "[core] dmabufFeedbackMainDevice"); 89 -> 90 RASSERT(!g_pPortalManager->m_sWaylandConnection.gbm, "double dmabuf feedback"); 91 92 dev_t device; 93 assert(device_arr->size == sizeof(device)); (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) * frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 frame #1: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #2: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0, closure=0x0000000000000000) at ffi64.c:673:3 frame #3: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0) at ffi64.c:710:3 frame #4: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a89100, flags=1, target=0x0000182398a105c0, opcode=2, data=0x0000000000000000) at connection.c:1025:2 frame #5: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #6: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #7: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #8: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #9: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #10: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #11: 0x0000000000326718 xdg-desktop-portal-hyprland`CToplevelManager::activate(this=0x0000182398a19240) at ToplevelManager.cpp:109:5 frame #12: 0x0000000000267b72 xdg-desktop-portal-hyprland`CPortalManager::onGlobal(this=0x0000182398a1b000, data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:261:34 frame #13: 0x00000000002675e5 xdg-desktop-portal-hyprland`handleGlobal(data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:20:23 frame #14: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #15: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170, closure=0x0000000000000000) at ffi64.c:673:3 frame #16: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170) at ffi64.c:710:3 frame #17: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a1b8c0, flags=1, target=0x0000182398a10440, opcode=0, data=0x0000000000000000) at connection.c:1025:2 frame #18: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #19: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #20: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #21: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #22: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #23: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #24: 0x00000000002689a4 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x0000182398a1b000) at PortalManager.cpp:312:5 frame #25: 0x00000000002a3f76 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820fbc870, envp=0x0000000820fbc880) at main.cpp:38:23 frame #26: 0x000000082a0172aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820fbc870, env=0x0000000820fbc880, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #27: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 36 void mutex::unlock() noexcept { 37 int ec = __libcpp_mutex_unlock(&__m_); 38 (void)ec; -> 39 _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL( 40 ec == 0, "call to mutex::unlock failed. A possible reason is that the mutex wasn't locked"); 41 } 42 (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode * frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 frame #2: 0x0000000000268f06 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x000021aa1001b000) at PortalManager.cpp:335:5 frame #3: 0x00000000002a3f56 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820d386c8, envp=0x0000000820d386d8) at main.cpp:38:23 frame #4: 0x00000008274222aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820d386c8, env=0x0000000820d386d8, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #5: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 (lldb) f 1 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 421 422 while (1) { // dbus events 423 // wait for being awakened -> 424 m_sEventLoopInternals.loopRequestMutex.unlock(); // unlock, we are ready to take events 425 426 std::unique_lock lk(m_sEventLoopInternals.loopMutex); 427 if (m_sEventLoopInternals.shouldProcess == false) // avoid a lock if a thread managed to request something already since we .unlock()ed PR: 278496 Reported by: shurd

* thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 87 static void dmabufFeedbackMainDevice(void* data, zwp_linux_dmabuf_feedback_v1* feedback, wl_array* device_arr) { 88 Debug::log(LOG, "[core] dmabufFeedbackMainDevice"); 89 -> 90 RASSERT(!g_pPortalManager->m_sWaylandConnection.gbm, "double dmabuf feedback"); 91 92 dev_t device; 93 assert(device_arr->size == sizeof(device)); (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) * frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 frame #1: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #2: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0, closure=0x0000000000000000) at ffi64.c:673:3 frame #3: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0) at ffi64.c:710:3 frame #4: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a89100, flags=1, target=0x0000182398a105c0, opcode=2, data=0x0000000000000000) at connection.c:1025:2 frame #5: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #6: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #7: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #8: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #9: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #10: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #11: 0x0000000000326718 xdg-desktop-portal-hyprland`CToplevelManager::activate(this=0x0000182398a19240) at ToplevelManager.cpp:109:5 frame #12: 0x0000000000267b72 xdg-desktop-portal-hyprland`CPortalManager::onGlobal(this=0x0000182398a1b000, data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:261:34 frame #13: 0x00000000002675e5 xdg-desktop-portal-hyprland`handleGlobal(data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:20:23 frame #14: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #15: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170, closure=0x0000000000000000) at ffi64.c:673:3 frame #16: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170) at ffi64.c:710:3 frame #17: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a1b8c0, flags=1, target=0x0000182398a10440, opcode=0, data=0x0000000000000000) at connection.c:1025:2 frame #18: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #19: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #20: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #21: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #22: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #23: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #24: 0x00000000002689a4 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x0000182398a1b000) at PortalManager.cpp:312:5 frame #25: 0x00000000002a3f76 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820fbc870, envp=0x0000000820fbc880) at main.cpp:38:23 frame #26: 0x000000082a0172aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820fbc870, env=0x0000000820fbc880, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #27: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 36 void mutex::unlock() noexcept { 37 int ec = __libcpp_mutex_unlock(&__m_); 38 (void)ec; -> 39 _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL( 40 ec == 0, "call to mutex::unlock failed. A possible reason is that the mutex wasn't locked"); 41 } 42 (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode * frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 frame #2: 0x0000000000268f06 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x000021aa1001b000) at PortalManager.cpp:335:5 frame #3: 0x00000000002a3f56 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820d386c8, envp=0x0000000820d386d8) at main.cpp:38:23 frame #4: 0x00000008274222aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820d386c8, env=0x0000000820d386d8, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #5: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 (lldb) f 1 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 421 422 while (1) { // dbus events 423 // wait for being awakened -> 424 m_sEventLoopInternals.loopRequestMutex.unlock(); // unlock, we are ready to take events 425 426 std::unique_lock lk(m_sEventLoopInternals.loopMutex); 427 if (m_sEventLoopInternals.shouldProcess == false) // avoid a lock if a thread managed to request something already since we .unlock()ed PR: 278496 Reported by: shurd (cherry picked from commit 78fbf8e)

add leftover build file

1e6a91f

Resolves build warning that the file /etc/dbus-1/system.d/afp.conf is leftover after package is deinstalled.

uqs closed this Jun 4, 2013

tota pushed a commit to tota/freebsd-ports that referenced this pull request Apr 18, 2014

1. Fix build when using clang 3.4.

ca4740c

2. RTM_OLDADD and RTM_OLDDEL were removed from -stable. Thanks alfred@ for this patch. 3. Stagify. Submitted by: alfred (freebsd#2)

valpackett referenced this pull request in DankBSD/ports Sep 13, 2017

Merge pull request #2 from freebsd/plasma5

15872cf

Merge pull request #1 from swills/plasma5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net/netatalk3: fix leftover build file #2

net/netatalk3: fix leftover build file #2

evansus commented Jun 4, 2013

evansus commented Jun 4, 2013

tota commented Jun 4, 2013

evansus commented Jun 4, 2013

tota commented Jun 4, 2013

uqs commented Jun 4, 2013

net/netatalk3: fix leftover build file #2

net/netatalk3: fix leftover build file #2

Conversation

evansus commented Jun 4, 2013

evansus commented Jun 4, 2013

tota commented Jun 4, 2013

evansus commented Jun 4, 2013

tota commented Jun 4, 2013

uqs commented Jun 4, 2013