Front page | perl.perl5.porters |
Postings from August 2021
"L. Walsh" <perl-diddler@tlinx.org> wrote:
:On 2021/08/09 16:25, Dan Book wrote:
:>
:> Correct, the only way to affect out of memory errors is by recompiling
:> Perl with specific options (to reserve a buffer for out-of-memory use)
:> and then using https://perldoc.perl.org/variables/$%5EM.
:---
:%5EM?...new one on me.
That's the $^M variable, lightly documented in perlvar. There's a bit
more info on perlmonks at eg
https://perlmonks.org/index.pl?node_id=11130839
which also has a couple of additional links that look handy.
In this context, using $^M could get you a stacktrace at the point of
failure, which could well point you directly at the problem.
:> Another option is to use something
:> like https://metacpan.org/pod/Devel::Trace as a hammer to log
:> everything that happens up until you run out of memory.
:
:Wouldn't that be likely to affect the outcome? Though rt now, I'm seeing
:a wide variance in fail times (with system memory barely scratched).
If it is suddenly running out of memory rather than gradually growing
in size, it could well be a wild allocation of some sort. Commonest
cause of that in pure perl is using the numeric value of a reference
in a context that causes an allocation, such as an array index.
perl will give a warning if you directly use a reference as an array index:
% perl -wle 'my @a; my $index = {}; $a[$index] = 1'
Use of reference "HASH(0x5574970ad1e0)" as array index at -e line 1.
Out of memory!
It is not able to do so if you use it indirectly:
% perl -wle 'my @a; my $key = {}; my $index = $key + 0; $a[$index] = 1'
Out of memory!
And the same problem can arise in other ways:
% perl -wle 'my $index = {}; my $s = "x" x $index'
Out of memory!
[p5p: any reason we couldn't warn on this, same as for array indices?]
There has been talk of a 'strict'-like mode that would trap all
stringification and numification of references, but as far as I know
no such module exists at the moment.
_If_ something like that is the cause (and if $^M seems like too much
effort), logging seems like the best way to narrow down which code
to audit for the error, and there's a good chance that the additional
logging will not affect the outcome.
Hugo
Thread Previous
|
Thread Next