Increase or Eliminate BUFFER_MAX_SIZE in include/opensrf/utils.h

[Jason Stephenson]

While investigating bug 1835620, I got a segmentation fault from doing "introspect open-ils.storage" with srfsh.

The behavior is slightly different depending on distro. On Ubuntu Bionic, one gets "Segmentation fault (core dumped)" and srfsh exits immediately. On Debian Buster, "Buffer reached MAX_SIZE of 10485760Segmentation fault" appears in srfsh, and srfsh then hangs. (I do not know for how long, though I assume indefinitely. I never left srfsh hanging for more than 2 minutes or so before killing it.)

In both cases, /openils/var/log/open-ils.storage_stderr.log contains a message similar to the following:

Caught error from 'run' method: Exception: OpenSRF::EX::Session 2019-07-07T08:03:59 OpenSRF::Application /usr/local/share/perl/5.26.1/OpenSRF/Application.pm:240 Session Error: <email address hidden>/_bionic_1562501006.497240_2824 IS NOT CONNECTED TO THE NETWORK!!!

Something like the following appears in /var/log/syslog:

Jul 7 08:03:59 bionic kernel: [ 62.539299] srfsh[2824]: segfault at 55abf85de3d1 ip 00007f46705785e6 sp 00007ffc37bd3300 error 6 in libopensrf.so.2.1.1[7f467055e000+30000]

I did some experimentation on Buster and upped BUFFER_MAX_SIZE to 100MB. I was then able to dump the results of introspect open-ils.storage to a file. It was approximately 47MB in size.

I recommend that we either do away with the BUFFER_MAX_SIZE constant and let the O/S handle memory exhaustion, or that we increase it to a minimum of 50MB, though I think 100MB would be better.

A third option could be to find a better way to manage the data in the smaller buffer, such as passing it off to the client, though this may not be as easy as the previous two options.