• obviously with GDOME configuration the problem disappears.
• i haven't tested the problem with 3.5.0 version inside apache (i think that the problem happens also in that environment). Anyway the problem first appeared in our 3.3.15 production eprints just after libxml2 update. After apache reboot, it crashed with core dump. Obviously i immediately returned back to 2.11.9 libxml2 version, without doing any other tests.

Hi Paolo,

Version 2.14.5 is the most recent version of LibXML2 (only released 15th July 2025), the latest version of have tested on is for RHEL 10, which is running LibXML 2.12.5 (patch version 7).

I am not overly happy as making a change to such a core file, as I am unsure what the side-effects may be.  I have quickly checked over the code base and I can only see once instance where the XML::LibXML::parse_file function which you propose changing in your diff has a second parameter for the basepath.  

This instance is in a command script (tools/phrases_map) rather than any code loaded by Apache.  I don't believe this script is needed, as it looks to be a legacy script for updating certain phrases between versions of EPrints.  I don't every remember using this script, so I reckon it is more than 10 years old, so I would probably just remove it, if I made a change to the parse_file function.  However, I am uncertain if any Bazaar plugins, ingredients, etc. may call this will a basepath.  I feel a better fix may be to only provide this second argument to XML::LibXML's parse_fh if it has a non-empty value.  E.g.

eval { $doc = $basepath ? $PARSER->parse_fh( $fh, $basepath ) : $PARSER->parse_fh( $fh ) };

Then if something does require the basepath then this does not suddenly break.  However, as I suspect is the case this basepath argument is barely ever used, then it will probably never affect your repository in the way you have described.

I think the best thing you can do is submit this as an issue on https://github.com/eprints/eprints3.4 as that is a better forum to discuss this in more detail.

Thanks and regards

David Newman

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Dear all,

more or less 1/2 month ago FreeBSD updated libxml2 its package from version 2.11.9   to version 2.14.5 and it's subsequent XML::LibXML perl package. 

With this upgrade eprints became very unstable, on our production server (3.3.15) and on our test server (3.4.6 and  3.5.0 beta 1). The instability seems to happen when it tries to read language files. For example with 3.5.0 the command 
#epadmin test [site] 

crashes with 'Bus Error' or ' Segmentation fault'

reading .../lib/lang/en/phrases/ep_template.xml

This error seems to disappear when applying this small patch

--- LibXML.pm   2025-08-26 15:02:20.844122000 +0200

+++ LibXML_new.pm       2025-08-26 15:02:46.564720000 +0200

@@ -130,7 +130,7 @@

        open(my $fh, "<", $file) or die "Error opening $file: $!";

        my $doc;

-       eval { $doc = $PARSER->parse_fh( $fh, $basepath ) };

+       eval { $doc = $PARSER->parse_fh( $fh ) };

modifying all the language xml files adding complete path on DTD definition.

Recompiling libxml2 from scratch (not using the package or ports) present the same instability.

The strange thing is that a very small program that reads the language files, without all the eprints infrastructure, works like a charme.

Anybody has found a similar problem ? Any ideas ? I can't test this problem on a Linux server for now, i fear that it is a eprints+FreeBSD related bug.

Best regards,

Paolo Tealdi

Ing. Paolo Tealdi                                                                                                                             ISIAD - Politecnico Torino            

Telefono/Phone : +39-011-0906714 , FAX : +39-011-0906625

Indirizzo/Address : C.so Duca degli Abruzzi,  24 - 10129 Torino - ITALY                     Skype : tealdi.paolo

Please consider your environmental responsibility before printing this e-mail

*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/