| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
This is a fix for a bug introduced two months ago in v5.35.5.
|
| | |
|
| | |
|
| |
|
|
| |
No sense trying to derive them ourselves.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a thinko/missed simplification that should have been part of
commit 53a41f9c2c0671d8:
Inline the xhv_aux struct in the main hash body
For now, memory for this structure is always allocated, even though it
isn't always flagged as being present.
Prior to that commit the Renew() in S_hv_auxinit() had been needed because
the memory that HvARRAY() points to needed to be expanded from "just the
array of HE pointers" to "that, plus space for the xhv_aux struct.
With that commit, the xhv_aux struct was no longer stored in the same
memory block, so there was no need to reallocate storage. Hence the
Renew() should be completely removed. What that commit actually did was
neatly change the parameters to the Renew() call such that it reallocated
storage to the exact same size, which isn't wrong, but is makework. Oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the assignments to SvFLAGS(sv) after the check for SvOOK(), and use
arena_index for the array index to PL_body_roots. Without both fixes,
del_body() would always be called with &PL_body_roots[SVt_PVHV], which is
wrong if the body was allocated from &PL_body_roots[HVAUX_ARENA_ROOT_IX].
PVHV body handling was changed recently by commit 94ee6ed79dbca73d:
Split the XPVHV body into two variants "normal" and "with aux"
Default to the smaller body, and switch to the larger body if we need to
allocate a C<struct xpvhv_aux> (eg need an iterator).
This restores the previous small size optimisation for hashes used as
objects.
as part of changing where memory for C<struct xpvhv_aux> is allocated.
The new implementation uses two sizes of "bodies" for PVHVs - the default
body is unchanged, but when a hash needs a C<struct xpvhv_aux>, it now
swaps out the default body for a larger body with space for the struct.
(Previously it would reallocate the memory used for HvARRAY() to make space
for the struct there - an approach which requires more tracking of changed
pointers.)
That commit was subtly buggy in that on hash deallocation it didn't *return*
hash bodies to the correct arena. As-was, it would return both sizes of hash
body to the arena for the default (smaller) body. This was due to a
combination of two subtle bugs
1) the explicit reset of all SvFLAGS to SVf_BREAK would implicitly clear
SVf_OOK. That flag bit set is needed to signal the different body size
2) The code must call del_body() with &PL_body_roots[arena_index], not
&PL_body_roots[type]
type is SVt_PVHV for both body sizes. arena_index is SVt_PVHV for the
smaller (default) bodies, and HVAUX_ARENA_ROOT_IX for the larger bodies.
There were no memory errors or leaks (that would have been detectable by
tools such as ASAN or valgrind), but the bug meant that larger hash bodies
would never get re-used. So for code that was steady-state creating and
destroying hashes with iterators (or similar), instead of those bodies being
recycled via their correct arena, the interpreter would need to continuously
allocate new memory for that arena, whilst accumulating ever more unused
"smaller" bodies in the other arena.
I didn't spot this bug whilst reviewing commit 8461dd8ad90b2bce:
don't overwrite the faked up type details for hv-with-aux
CID 340472
which is in the same area of the code, but fixes a related problem.
Curiously when reporting CID 340738:
Assigning value "SVt_IV" to "arena_index" here, but that stored value is
overwritten before it can be used
Coverity also didn't spot that the code in question was unconditionally
unreachable, and warn about that, or modify its warning to note that.
(For the code prior to this commit SvOOK(sv) at that point could only ever
be false. This is obscured thanks to macros, but all these macros are
unconditionally defined to the same values, so static analysis should be
able to infer that they are actually constant, and reason accordingly.
To be fair, this is *hard*. But not impossible. Hence I infer that static
analysis tools still have room for improvement, and can make "mistakes".)
Ironically, defining PURIFY would hide this bug, because that disables the
use of arenas, instead allocating all bodies explicitly with malloc() and
releasing them with free(), and free() doesn't need to know the size of the
memory block, hence it wouldn't matter that the code had that size wrong.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that HvAUX(hv) is allocated as part of the HV's body, it's imperative
to retain the flag that indicates which size of body has been allocated.
Otherwise, if we clear the flag, sv_clear() believes that the body is the
smaller of the two possible sizes, and so returns it to the correct arena
for that body size. This doesn't result in out-of-bounds memory reads, or
even memory leaks (when full cleanup runs with PERL_DESTRUCT_LEVEL=2),
because all bodies are still correctly tracked. However, without this bug
fixed, code that takes the same hash and repeatedly
1) assigns entries
2) iterates the hash
3) undef %hash
will request one new (larger) hash body for each iteration of the loop,
but each time return it to the arena for the smaller hash bodies, with the
result that the interpreter will steadily request ever more memory for
arenas for larger hash bodies, until memory is exhausted.
|
| |
|
|
|
|
|
| |
struct xpvhv_aux holds 4 pointers which can point to memory which needs
explicit release - document how hv_undef_flags() is directly responsible
for freeing xhv_mro_meta, indirectly responsible for freeing xhv_eiter,
and by implication can't free xhv_backreference or xhv_name_u.
|
| |
|
|
| |
This code is identical to a few lines above it
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
7.64 Fri 17 Dec 15:35:46 GMT 2021
No changes since v7.63_11
7.63_11 Tue 14 Dec 16:00:11 GMT 2021
OS390 fixes:
- Extend prereqs sort to work on EBCDIC
7.63_10 Mon 13 Dec 16:26:49 GMT 2021
OS390 fixes:
- Fix dynamic loading
7.63_09 Wed 8 Dec 22:20:53 GMT 2021
Enhancements:
- Don't use canned libpth values
7.63_08 Sat 27 Nov 17:28:03 GMT 2021
Correction:
- Previous change to ${LDFLAGS) was reverted
7.63_07 Sat 27 Nov 11:34:12 GMT 2021
Enhancements:
- Add $(LDFLAGS) when linking binary modules
7.63_06 Wed 3 Nov 01:24:05 GMT 2021
Bug fixes:
- Add -rpath when compiling XS modules on macOS
7.63_05 Sat 14 Aug 09:04:08 BST 2021
Enhancements:
- Added CPPRUN variable
7.63_04 Wed 30 Jun 15:15:01 BST 2021
Doc fixes:
- Describe CCFLAGS’ default
7.63_03 Tue 22 Jun 14:39:32 BST 2021
OS390 Enhancements:
- Fix override xs_make_dynamic_lib() for os390
7.63_02 Thu 3 Jun 19:52:03 BST 2021
Doc fixes:
- Changed wording for POLLUTE
7.63_01 Tue 25 May 16:22:50 BST 2021
Bug fixes:
- Comparing inodes numerically is unsafe
|
| |
|
|
|
|
|
| |
The "#ifndef _SAFECRT_IMPL" part made sense only for no longer
supported versions of Visual C++, but
92ca2349051b948d915e3fc721e3cbb97e7271e2 has accidentally exposed it
to Mingw builds.
|
| | |
|
| |
|
|
|
|
| |
These two functions, unlike all the rest, require the thread context
parameter to be explicitly passed. This commit makes the documentation
be accurate.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
If a sub exists, it takes precedence over the filehandle
interpretation even without the parens:
$ perl -le 'sub foo { "bar" } print foo;'
bar
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When bareword filehandles are disabled, the parser was interpreting
any bareword as a filehandle, even when immediatey followed by parens:
$ perl -M-feature=bareword_filehandles -le 'print foo()'
Bareword filehandle "foo" not allowed under 'no feature "bareword_filehandles"' at -e line 1.
While with the feature enabled, it works and prints the value returned
by the function:
$ perl -le 'sub foo { @_ } print foo("bar")'
bar
As for filehandles versus functions, a space before the parens makes
the difference:
$ perl -le 'print STDOUT ("bar")'
bar
$ perl -le 'print STDOUT("bar")'
Undefined subroutine &main::STDOUT called at -e line 1.
This fixes the bug by using the already-existing "immediate_paren"
variable to make it consistent when the feature is disabled.
Fixes #19271
|
| |
|
|
|
|
|
|
| |
- Move the version to the package line and bump it.
- Bump use version now that we're using package NAME VER.
- Drop strict now that we get it from use version.
- Switch to non-inheritance based Exporter usage.
- Use defined-or operator.
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
It turns out the functionality here duplicates a pre-existing tool,
which this commit converts to use instead.
|
| | |
|
| | |
|
| |
|
|
|
| |
Instead, this uses the fundamental constants and derived values copied
from utf8.h, making things shorter
|
| |
|
|
| |
Prepare for a future commit that will add a surrounding block.
|
| | |
|
| |
|
|
| |
Some of them need to be changed after generation
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that this function is available in miniperl, mktables can use it to
avoid a bunch of visually distracting 'no overloading' calls.
|
| |
|
|
| |
These apparently were once needed, but no longer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This update enables us to build EBCDIC static/dynamic
and 31-bit/64-bit addressing mode Perl. The number of
tests that pass is consistent with the baseline before
these updates, namely:
For blead.31.dynamic.ebcdic
Configured using -Dusedl
Failed 98 tests out of 1939, 94.95% okay.
Elapsed: 1038 sec
u=18.13 s=6.04 cu=535.69 cs=178.56 scripts=1939 tests=1035071
For blead.64.dynamic.ebcdic
Configured using -Dusedl -Duse64bitall
Failed 102 tests out of 1941, 94.74% okay.
Elapsed: 1057 sec
u=19.49 s=6.49 cu=543.00 cs=181.00 scripts=1941 tests=1053149
These changes also provide the base support to be able to provide
ASCII static/dynamic and 31-bit/64-bit addressing mode Perl.
Description of changes:
Makefile.SH
Changes were made to the os390*) case specific part of the code.
Support was added for the 64-bit DLL path because the original
only had support for 31-bit.
hints/os390.sh
This is the largest set of changes:
- Compilation and Link options were added for ASCII and 64-bit
- A z/OS specific check was added to determine if the Perl
code being built is ASCII or EBCDIC. The check works by
looking at the first character of the shell script to see
if it is an ASCII or non-ASCII character. If ASCII, then
the build is deemed to be ASCII. If not ASCII, it is assumed
to be EBCDIC.
- Cleanup was performed to remove code for z/OS systems that are
no longer supported, simplifying the file (e.g.
"`uname -v`x`uname -r`" in 02x0[89].*|02x1[0-9].*|[0-9][3-9]x*)
which would only be true on unsupported, very old pre-z/OS systems
- The compiler has been changed from xlc to c99. Both are available
as priced features of the operating system, and the c99 compiler is
a better 'fit' for options processing, being more consistent with
c99 on other platforms.
- Suppressing warning messages for CCN3159 were added because the
1-bit bitfields flagged due to a smaller-than-int data type are
harmless.
- Several feature test macros were added to bring the compilation up
to a modern level to enable Perl to take advantage of capabilities
available on all supported z/OS 2.4 and up systems.
- Removed the -Wl,EDIT=NO because debug information is no longer stored
in an area that will be loaded into memory, but is now stored in a
NOLOAD section. So - while this does mean that the binary on disk is a
little 'fat', what is loaded into memory is not, and it means that
people can have better problem determination tools available even on
production Perl distributions.
|
| | |
|
| |
|
|
|
|
|
| |
Transforming -iv into "(UV)-(iv + 1) + 1" can avoid signed integer
overflow even if iv was IV_MIN in 2's compelement representation
(as long as iv < 0), so that it makes special treatment for IV_MIN
unnecessary and saves one conditional jump.
|
