https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43435
Bug ID: 43435
Summary: opac-detail.pl crashes with "Can't call method
itemtype on an undefined value" — repeated occurrences
correlate with Starman worker panics (fold_constants
JMPENV_PUSH) and worker process death
Initiative type: ---
Sponsorship ---
status:
Product: Koha
Version: 25.11
Hardware: HP
OS: Linux
Status: NEW
Severity: major
Priority: P5 - low
Component: OPAC
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
Target Milestone: ---
Created attachment 204573
-->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204573&action=edit
opac-detail.pl crashes with "Can't call method itemtype on an undefined value"
— repeated occurrences correlate with Starman worker panics (fold_constants
JMPENV_PUSH) and worker process death
We are running Koha 25.11.04.000 in production and are experiencing a
recurring, ongoing issue where OPAC requests to opac-detail.pl trigger a Perl
runtime error, and — when this error coincides with a Plack/Starman graceful
shutdown signal (e.g. from log rotation, worker recycling via max_requests, or
a manual/automated restart) — the affected worker child processes crash with a
low-level Perl interpreter panic instead of shutting down cleanly. This causes
our Starman worker pool to gradually shrink over time (sometimes down to 0-1
active workers out of a configured 6), resulting in severe OPAC
slowness/unavailability until Plack is manually or automatically restarted.
Error 1 — recurring, very frequent (multiple times per hour under normal
traffic)
Can't call method "itemtype" on an undefined value at
/usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 749.
We have NOT been able to isolate this to one specific biblionumber or item
record:
item-level_itypes system preference = 1 (item-level, not biblio-level)
No items found with NULL/empty itype (checked via SQL)
Only 2 biblio records had NULL biblioitems.itemtype (21729, 31981) —
expected/normal since item-level_itypes=1
Correlating access logs against error log timestamps did not reliably identify
a single problem record; the error occurs across many different requests over
time, suggesting it may be triggered by a specific (but not-yet-identified)
data condition (e.g. an item with missing/orphaned data referenced transiently,
or a race condition in item retrieval) rather than one permanently broken
record.
We would appreciate guidance on what conditions cause an item object to be
undefined at opac-detail.pl line 749, so we can identify the underlying data
issue on our end, and suggest the code add a definedness check before calling
->itemtype to avoid the fatal error regardless of data condition.
Error 2 — Perl interpreter panic, occurs specifically when a shutdown/restart
signal arrives during request handling
panic: fold_constants JMPENV_PUSH returned 2.
panic: gen_constant_list JMPENV_PUSH returned 2.
Child process XXXXX exited with status 29
Sample from our plack-error.log (timestamps redacted for brevity, full log
available on request):
2026/09/01-09:48:27 Received QUIT. Running a graceful shutdown
Sending children hup signal
panic: fold_constants JMPENV_PUSH returned 2.
panic: fold_constants JMPENV_PUSH returned 2.
panic: fold_constants JMPENV_PUSH returned 2.
panic: fold_constants JMPENV_PUSH returned 2.
Child process 8344 exited with status 29
Child process 8343 exited with status 29
Child process 8347 exited with status 29
Child process 8345 exited with status 29
2026/09/01-09:48:27 Worker processes cleaned up
2026/09/01-09:48:27 Server closing!
This panic appears to occur when Starman sends a QUIT/graceful-shutdown signal
to workers while a worker is in the middle of handling a request that would
otherwise trigger the "itemtype on undefined value" error above (or similar
warning/exception). Instead of a clean shutdown, the child process panics and
exits with an abnormal status (4 or 29), rather than completing its current
request and exiting normally.
Observed effect
Because our environment restarts Plack periodically (via our own monitoring
script when worker count drops, and previously via routine log rotation /
max_requests recycling), the panic gets triggered repeatedly throughout the
day, each time killing multiple worker children simultaneously. Over hours,
this depletes the worker pool faster than it can be replenished, causing severe
performance degradation for library patrons.
Steps to Reproduce
Run Koha 25.11.04.000 under Plack/Starman with max_requests set (we use 60;
also reproduced with 200 and 1000)
Allow normal OPAC browsing traffic (including search engine/social media
crawlers hitting opac-detail.pl for various biblionumbers) to occur
At some point, the "Can't call method itemtype on an undefined value" error
will appear in plack-error.log for some biblionumber (we have not found a 100%
reliable manual reproduction step — it appears data/record-dependent and we
could not pin down the exact triggering record despite investigation)
If a Plack restart (graceful QUIT signal) occurs at approximately the same time
as one of these errors is being processed by a worker, that worker (and often
several others active at that moment) will panic with fold_constants
JMPENV_PUSH returned 2 instead of shutting down gracefully
Expected behavior
opac-detail.pl should not throw a fatal "Can't call method itemtype on an
undefined value" error for any valid request — it should handle
missing/undefined item data gracefully (e.g., skip display of item-level
details, or show a "not available" message) rather than crashing the whole
request.
A graceful shutdown signal (QUIT) arriving during request/error handling should
never cause a Perl-level panic that kills the worker process abnormally.
Actual behavior
opac-detail.pl fatally errors on line 749 for certain (unidentified)
records/requests.
When a shutdown signal coincides with this error being raised, the worker
process panics and dies abnormally (exit status 4 or 29) instead of shutting
down cleanly, contributing to a shrinking worker pool over time.
Environment
Koha version: 25.11.04.000
OS version (uname -a): Linux localhost 6.12.100+deb13-amd64 #1 SMP
PREEMPT_DYNAMIC Debian 6.12.100-1 (2026-07-30) x86_64
Perl interpreter: /usr/bin/perl
Perl version: 5.040001
MySQL version: 11.8.6-MariaDB-0+deb13u1 from Debian
Apache version: Apache/2.4.68 (Debian)
PSGI: Plack (deployment)
Zebra version: Zebra 2.2.8, Using ICU
Message broker: RabbitMQ
Plack configuration:
plack_workers: 6
plack_max_requests: 60 (also reproduced at 200 and 1000)
Additional notes
We suspect this may be related to running on a relatively new/bleeding-edge
stack (Perl 5.40.1 on Debian 13 "Trixie") — the fold_constants JMPENV_PUSH
panic is a historically rare Perl-core-level issue previously seen with older
Perl+Plack/Starman combinations; we are not certain if it is specific to Perl
5.40 or triggered by something in Koha's exception-handling path.
We are happy to provide additional diagnostic information, full log excerpts,
or test on our instance if that would help narrow down the root cause.
This is a production library catalog (OPAC) serving real patrons, so we would
appreciate any guidance on a temporary code-level workaround (e.g., a defensive
if (defined $item) check around line 749) while a permanent fix is developed.
Thank you for your time reviewing this report.
--
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
