simple2zoom has segmentation faults

As the problem appears to be with simple2zoom itself, and nothing particularly related to Evergreen, this should probably be reported as a bug with the upstream project at https://rt.cpan.org/Public/Dist/Display.html?Name=Net-Z3950-Simple2ZOOM

My thought was that maybe this bug should be filed on Ubuntu 12.04 and let the Ubuntu developers work it out with upstream.

Simple2zoom is perl and the errors seem to be coming from a lower level than simple2zoom, but I could be wrong.

We're seeing this also.

Done

Then second comment came in between. I sent the bug report to the cpan address. It is recorded as:

  https://rt.cpan.org/Ticket/Display.html?id=84841

Changing status to Triaged pending further discussion... due to differing opinions about whether this bug needs to be tracked for Evergreen or just watched on RT as a simple2zoom problem.

Seriously looks like a bug in some package used by simple2zoom. Question is, which one?

https://rt.cpan.org/Public/Bug/Display.html?id=84841

(testing to see if it'll add a bug watch for the full URL)

This should rightfully be a bug against Ubuntu 12.04. The problem appears to be caused by libyaz from Ubuntu packages.

Using the following appears to fix this:

http://ftp.indexdata.dk/pub/yaz/ubuntu/README

We updated apt-get on our development server and updated yaz and its libraries. This seems to have fixed the problem. We will give it a try on production and see what happens.

Since current releases of the packages we depend on seem to fix the issue, marking this as invaild for evergreen. I'll leave point it at Ubuntu to others if they feel it's still warranted, but I don't think so since an apt-get update fixed things for the OP.

Not quite fixed, because the most recent libyaz4 version on Ubuntu 12.04, for example, is 4.2.18-1build1, and the problem is solved in a later version which is not in official Ubuntu repositories yet. So, there is a workaround, but not a fix yet, at least for Ubuntu, unless I'm missing something.

It is an Ubuntu bug and should be opened there.

Workarounds become fixes in the absence of real versions of the latter.

Hello Jason,

No argument that it is an Ubuntu bug. I even stated that in the report.
Its just nice to have it documented on the Evergreen site so that people
do not have to look all over the place to find a solution.

al

ps. That's not my comment you are noticing. As long as its fixed or
there is a solution, I'm happy.

pps. When do you want to have a more in depth conversation on NCIP.
Simon and I have been studying up on Perl modules, mod_perl, etc. While
I've been programming for a number of years and have worked with a lot
of protocols in the library world, writing a Perl module is a new type
of programming for me.

Galen's last comments seemed to be about money. Our boss just wants an
NCIP server.

We have our development machines set up with a Evergreen 2.4.1 instance.

Also I'll be leaving on vacation starting August 9th. I'll be back on
August 19th.

On 08/01/2013 02:00 PM, Jason Stephenson wrote:
> It is an Ubuntu bug and should be opened there.
>
> Workarounds become fixes in the absence of real versions of the latter.
>

--
Alan Rykhus
PALS, A Program of the Minnesota State Colleges and Universities
(507)389-1975
<email address hidden>
"Be pleasant until ten o'clock in the morning and the rest of the day
will take care of itself." ~ Elbert Hubbard

https://bugs.launchpad.net/ubuntu/+source/yaz/+bug/1215512

So, um, given that Ubuntu hasn't lifted a finger to resolve this and everyone installing Evergreen on Ubuntu 12.04 will still run into this problem, maybe the prereq installer / README should be updated to point at the Index Data packages.

Also, in IRC someone argued that this was likely a problem with Debian Wheezy as well; however, wheezy currently offers libyaz 4.2.30 (where the problem should be long fixed), while Ubuntu 12.04 is stuck on 4.2.18.

Ubuntu--

Ubuntu 14.04 also, like Wheezy, packages libyaz version 4.2.30 <http://packages.ubuntu.com/trusty/yaz>. If that version solved the segfault problem, could the newer version from the Ubuntu 14.04 repository be installed on Ubuntu 12.04? E.g., replacing libyaz-dev with libyaz4-dev/trusty and yaz with yaz/trusty in Makefile.ubuntu-precise. Of course, if 4.2.30 has the same segfault problem, then installing a newer version from Index Data would probably need to be done on Wheezy and Ubuntu 14.04 versions as well, not just Ubuntu 12.04?

Could anybody who is using 4.2.30 confirm whether or not they are observing the segfaults?

If installing directly from Index Data, I am assuming choice of one specific version rather than latest version at the time of install. Some of them may be unstable or experimental.

You shold use the yaz version from the Index Data repository mentioned above. Thast seems to work. I am not certain that pulling in the package from 14.04 will do the trick, but it might.

However, I am trying to set z39.50 up on a Precise VM and instead of segfaults, I'm getting SIGTERM:

Found database: MVLC
09:41:30-21/10 [server] Adding dynamic listener on tcp:10.0.7.7:2210 id=1 PID=25
668
11:46:31-21/10 simple2zoom(1) [session] Session - OK 1 tcp:10.0.5.77 PID=25688
11:46:31-21/10 simple2zoom(1) [request] Auth none
11:46:31-21/10 simple2zoom(1) [request] Init OK - ID:81 Name:YAZ Version:4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031
search: translated '@attrset Bib-1 "history of essex county"' to '"history of essex county"'
11:46:54-21/10 simple2zoom(1) [request] Search MVLC ERROR 100 1 1+0 RPN @attrset Bib-1 "history of essex county"
11:49:11-21/10 [server] Received SIGTERM. PID=25668

Not sure it is the same thing, but I'm looking into it.

Never mind the SIGTERM in my previous comment. That's when I told it to stop running.

I'm still getting search errors, but don't think it is at all related to this.

Installing directly from IndexData by way of, for example

deb http://ftp.indexdata.dk/ubuntu precise main
deb-src http://ftp.indexdata.dk/ubuntu precise main

would bring in at the time of installation the newest version, as new versions are released relatively frequently: http://ftp.indexdata.com/pub/yaz/ubuntu/precise/?C=M;O=D.

That is better than installing an official Ubuntu 12.04 version that is known to be broken, but could also result in installing a different broken version, for example, on http://www.indexdata.com/yaz/doc/NEWS we see a broken release and then a fix a day later:

----------
--- 4.2.65 2013/08/22

ZOOM: another fix for record caching (introduced in YAZ 4.2.64).

--- 4.2.64 2013/08/21 (Broken WRT ZOOM C, do not use)

ISO2709/MARC parse most octet aligned records; not just those that
are known to be ISO2709/MARC. This makes ZOOM and yaz-client
MARC parse more records instead of just dumping as is. YAZ-670

ZOOM: proper caching for variations of record schema. YAZ-671

Solr: Check for enging / and perhaps commands (select/term) YAZ-651
----------

My suggestion is find a known, working version, and submit the package on the Ubuntu bug. Join the Maters of the Universe group, since this package lives in universe, and then you can get the fixes in more easily.

Hah! "Maters of the Universe" should be Masters of the Universe.

Got hit by this on a brand new provisioned Ubuntu 14.04 box. Using the yaz 4.2.30 and associated libnet-z3950-simple2zoom-perl and libnet-z3950-zoom-perl packages included in Ubuntu's universe resulted in simple2zoom starting up, but then segfaulting (somewhere in libgnutls.so.26) upon receiving the first "find" request.

So I removed the Ubuntu packages, installed yaz 5.16.0 from indexdata's packages, and installed Net::Z3950::Simple2ZOOM via CPAN (which install Net::Z3950::ZOOM as another CPAN dependency), and now it works. Yayz.

Interestingly, I don't recall experiencing this on Ubuntu 14.04, but it has been two years, so memory maybe fuzzy.

One further annoying update: the Z39.50 server is working great with the indexdata packages, but now z39.50 import of records with accents winds up with either corrupted accented characters (they look fine in the MARC editor, but once you hit "import" they get corrupted) or a refusal to import them at all.

I tried rolling back to the indexdata packages from a few years back (first 5.10.2-1.indexdata, then 5.5.1-1.indexdata - November 2014) but the z39.50 corrupted accented character problem persisted. This latter problem might be able to be solved in our ZClient module with a judicious encode() or decode() call--I'll look into that--but in the short term perhaps the best option is to isolate the Z39.50 server environment on a separate VM or in a docker container so it can use yaz5, while the Z39.50 import functionality can use yaz4 on the main Evergreen server.

It turns out the reason yaz4 was segfaulting in libgnutls.so.26 is because we were pointing at an HTTPS URL for SRU; if you point at a plain old HTTP URL for SRU, then yaz4 works just fine. A bit problematic if your site is HTTPS everywhere, but this is hopefully helpful for anyone looking to reproduce the symptoms.