If you are using the barcode range option in the label creator, if your barcode range is too large, your Koha server may run out of memory before the process finishes. This causes out of memory errors. This could happen if a library had e.g. "100101223" as their last used barcode and they wanted to print the next 50 barcodes and they make a mistake while entering the "To:" field in the barcode range creator. From: 100101224 To: 1000101274 You could very easily accidentally cause the label-create.pl process to create insane amounts of barcodes. In this case 900 million barcodes would be created, if my math is right. :) The memory usage will slowly increase as barcodes are created and "eventually" there will be no more memory left, causing OOM killer to strike. We should at least warn in the barcode range creation tool that such problems can happen if you aren't careful while entering values. I don't know if there's a good way to stop users from entering too large ranges, maybe there is a valid use case for a large barcode range if you have enough memory. To reproduce (assuming you are on ktd): 1. Check your current memory usage, e.g. with "ps aux --sort -rss" (or "free -h" to see how much memory is still free) 2. Make sure you know how to kill a process in Debian, e.g. "killall -9 /kohadevbox/koha/labels/label-create-pdf.pl" - you will need it soon.. 3. Go to Cataloging -> Label Creator -> Print barcode range 4. Enter in a number in "From:" and a crazy high number in "To:"; see above for an example 5. Print range -> Export (doesn't matter which templates etc.) -> Click on "Download as PDF" 5. Check your memory usage again, it should start spiking over the next minutes. The guilty process should be /kohadevbox/koha/labels/label-create-pdf.pl (assuming you are on ktd). 6. Either kill the process or you will run out of memory
Nice spot, Philip. This is a tricky one. I hoped that maybe checking the size of the array created by ($from .. $to) would be enough, but it turns out that ($from .. $to) is a very heavy CPU and RAM intensive operation itself when using the values 100101224 and 1000101274. On the face of it, we could minus $to from $from to get a difference to try to validate, but... I think barcodes are not necessarily positive integers. The ".." Perl range operator also has a magical auto-increment algorithm when applied to strings, so it might be difficult to take into account that magic... That being said... if you put $from = 'ax' and increment is with $from++, you'll get 'ay' same as when using the ".." range operator. So using a for loop with ++ increment operator and a max count might work. That should have a number of advantages in terms of CPU and RAM usage actually since the calculation should be quite stable. We'd also want another variable to test the last generated value, because something like: "from *x to az" will only yield *x, so you wouldn't want to increment 10000 times and get *x for each iteration. Anyway... perhaps not a perfect solution but hopefully it would be practical?
I briefly wondered if Perl could automagically do a diff on BARCODE9999 minus BARCODE1000 but no... it did not like that haha. You can increment and decrement but there are no operations that can automagically determine the difference it seems.