UBSAN errors in pp_hot.c:880 (Perl_pp_multiconcat)
#20678
Comments
|
I'm happy to revisit this once GCC 13 is released if you'd prefer. if I build Perl from master at 244f1aa, I get the same thing during the build but also when running |
thesamesam
changed the title
pp_hot.c:880 (Perl_pp_multiconcat)pp_hot.c:880 (Perl_pp_multiconcat)
|
On Fri, Jan 06, 2023 at 06:06:21PM -0800, Sam James wrote:
Perl crashes when bulit with Undefined Behavior Sanitizer (UBSAN,
`-fsanitize=undefined`) when running `aclocal`:
....
pp_hot.c:880:17: runtime error: load of address 0x7ffdeba10fa8 with
insufficient space for an object of type 'ssize_t'
...
#0 0x7fef20e39346 in Perl_pp_multiconcat /var/tmp/portage/dev-lang/perl-5.36.0-r1/work/perl-5.36.0/pp_hot.c:880
Do you have the ability to produce a reduced test case? The undefined
behaviour is being detected in a string concatenation operation, and
Perl -V does many string concatenations - the number and nature of which is
dependent on the user's installation. aclocal presumably has many
versions and is dependent upon the user's local environment for its
exact behaviour.
(I don't have GCC 13 installed so can't reproduce the issue).
…--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.
|
|
Looks like this is enough: |
[snip]
You have approximately 70 command-line switches here, making debugging difficult. Have you tried to identify the minimum number of such switches needed to generate the failure you're reporting? |
|
In #20678 (comment), I built from git with just: And that triggered the failures. |
|
I managed to reproduce this with gcc 13. I added some debug output to show the pointers involved, the first line is before the Note that buf is an auto array with 64 entries (each with a pointer and length), the value of svpv_p where the error is produced is well within the range of of the svpv_buf[] array. If I debug and break immediately before the error line: diff adding the debug output |
|
cc @siddhesh |
tonycoz
added a commit
to tonycoz/perl5
that referenced
this issue
Jan 12, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in Perl#20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes Perl#20678.
|
The fix looks right; |
|
Also FWIW, I've filed a gcc bug for this. It looks like __bdos is overzealous about this and screws up the size computation even if there wasn't actually any undefined behaviour: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 |
tonycoz
added a commit
that referenced
this issue
Jan 16, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in #20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes #20678.
|
Thanks for putting the time into this folks! |
steve-m-hay
pushed a commit
that referenced
this issue
Apr 10, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in #20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes #20678. (cherry picked from commit 92ef216)
pjacklam
pushed a commit
to pjacklam/perl5
that referenced
this issue
May 20, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in Perl#20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes Perl#20678.
pjacklam
pushed a commit
to pjacklam/perl5
that referenced
this issue
May 20, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in Perl#20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes Perl#20678.
khwilliamson
pushed a commit
to khwilliamson/perl5
that referenced
this issue
Jul 10, 2023
When svpv_base == svpv_buf, svpv_p would be set to point before the buffer, which is undefined. This appears to be what gcc 13 is complaining about in Perl#20678, despite that report including what appears to be a completely valid address, on a line where the value of svpv_p is now within the range of svpv_buf. An intermediate approach to this used: temp = svpv_p; if (svpv_p++ == svpv_end) break but this is also incorrect, since svpv_p would end up as an invalid pointer, though gcc UBSAN didn't pick that up. Fixes Perl#20678.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Perl crashes when bulit with Undefined Behavior Sanitizer (UBSAN,
-fsanitize=undefined) when runningaclocal:This is with GCC 13.0.0_pre20230101. Note that GCC 13 isn't yet released, but the only other bug I've hit so far of this type was legitimate (gentoo/elfix#3) and this type of object size check is new in 13.
Steps to Reproduce
-fsanitize=undefinedusing GCC 13.export UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1"perl -Voraclocal.Expected behavior
perl -Voraclocalto succeed with no errors.Perl configuration
The text was updated successfully, but these errors were encountered: