I recently upgraded my system from jessie i386 to bullseye amd64.
Since I did this, a long-established web application has become flaky
(returning no output from requests).  Associated with its failures I
see log messages like this:

Jul  8 21:59:42 chiark kernel: [354982.615451] perl[7671]: segfault at 22 ip 000055b443da11b1 sp 00007ffe01ca1e50 error 6 in perl[55b443d9d000+185000]

The same hardware has been running an amd64 kernel (albeit i386
userland) forever with no unexplained problems, so I trust the
hardware.  Other Perl programs on the system are fine.

I looked through the memory map of a relevant perl process (see below)
and I think it very likely that the problem is a bug in libfcgi or in
FCGI.so.  The failures are intermittent and I don't have a reliable
repro.

Due to the convoluted arrangements by which this webapp is invoked in
my environment, it is not entirely straightforward to get coredumps or
stack traces, etc.  I can try to provide better information if it is
likely to be useful.

But first I thought I would ask: is this at all a plausible theory ?
Is it worth my time upending everything so that I can get a stack
trace or attach a debugger ?

My alternative is to reorganise my invocation method entirely.  My
webapp is in Mason 1 (libhtml-mason-perl), so I think my options may
be limited.

You're filing this bug against libfcgi-perl, and in the subject you
say "I think it's CGI::Fast".

I'd just like to mention that CGI::Fast is in the libcgi-fast-perl
package.

Cheers,
gregor

Hi.  What a quick reply!

gregor herrmann writes ("Re: Bug#1014617: libfcgi-perl: perl is segfaulting and I think it's CGI::Fast"):

I am obviously confused.

...

Ah I see.  I mean that I think it's FCGI.so which is in libfcgi-perl
which is loaded by CGI::Fast.  And CGI::Fast, aka libcgi-fast-perl, is
pure perl so I doubt it is reponsible.

Thanks,
Ian.