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: oleonard@myacpl.org Reporter: rafiqur83@gmail.com QA Contact: testopia@bugs.koha-community.org 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.