Trap SIGBUS when Configure checks for va_copy #18148
Closed
Conversation
This file contains 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. Original diff by deraadt@
|
I extracted |
|
What are the consequences exactly? Is this just a minor inconvenience, or should it be backported to maintenance releases of perl. |
|
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. |
steve-m-hay
pushed a commit
that referenced
this pull request
Dec 26, 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@ (cherry picked from commit bec07c3)
khwilliamson
pushed a commit
to khwilliamson/perl5
that referenced
this pull request
Jul 28, 2023
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@
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.