You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
Original diff by deraadt@
I extracted try.c from Configure and ran it on OpenBSD (without contributor's patch), FreeBSD, NetBSD and Linux. I got the segfault in the first two cases. Contributor's patch eliminated the segfaults in those cases. So, +1.
I believe just inconvenience, it fails the try either way so the results are the same, just a message about it on the console and a core file that is deleted automatically.
Tux
added a commit
that referenced
this pull request
Sep 22, 2020
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
Original diff by deraadt@
Updated the metaunit and regenerated Configure.
Note that PR's directly to Configure can generally not be "pulled", as Configure is generated
Thanks and sorry for the delay.
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
Original diff by deraadt@
(cherry picked from commit bec07c3)
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
Original diff by deraadt@
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On several systems the attempt to determine if we "need va_copy() or
similar" results in a SIGBUS instead of a SIGSEGV because the fault
happens pointing at an io device address.
While reviewing accounting logs during the OpenBSD system build, bluhm@
noticed a core dump and deraadt@ tracked it down.
While researching it was discovered that this is a fairly common case in
other systems as well.
Original diff by deraadt@
This was committed to OpenBSD already.