[Koha-bugs] [Bug 2625] moremember.pl consumes all available memory

bugzilla-daemon at pippin.metavore.com bugzilla-daemon at pippin.metavore.com
Thu Sep 18 19:09:17 CEST 2008


http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2625





------- Comment #1 from clay.fouts at liblime.com  2008-09-18 10:09 -------
<cfouts> except that it's trying to use that enormous number as the array index
number. Does perl do as-needed allocation of array elements or does it alloc
all memory up to the highest index?
<acmoore> we shouldn't be indexing an array like that anyway. It's probably
suppoosed to be using it as a hash key or something. Where is this code?
<cfouts> acmoore: moremember.pl line 65
<acmoore> I'm pretty sure it will malloc a ton of memory if you ask for
$whatever[ $bignumber ].
<cfouts> that's what I'm thinking, too, which happens to be the exact behavior
I'm seeing this process do.
<rch> it's looking for $foo[33235018078710] ??!!!
<cfouts> rch: yup... assigning a value to it, actually.
<acmoore> I'm pretty sure that line makes @failedreturns a list with one
element. So, like [ '33235018078710; ]. I don't think that's a problem.
<acmoore> well, [ '33235018078710' ]; but you get the idea.
<cfouts> but then look at the assignment in line 70
<cfouts> $return_failed[$failedret] = 1;
<cfouts> where $failedret is that huge value.
<acmoore> oh yeah, that's bad. We should be using a hash instead of an array.
<acmoore> espeically since barcodes can probably have characters in them, too.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the Koha-bugs mailing list