Broken unicode workaround

[lukas2511]

At FrOSCon we had some issues with tickets including unicode characters like german quotation and emojis.
The postencoding worker simply exited during the XMLin function and affected tickets were stuck in the postencoding state.

Afaik this was the first FrOSCon using a Frab version with real unicode support, so we never had this exact case before. It's not entirely clear if that is the issue or if something else is going on.

While trying to figure out what was happening I wasn't able to reproduce the issue when trying to extract the parsed XML in any way. So I basically knew parsing from written files worked fine... So as a quick and dirty workaround I simply wrote the incoming XML into a file and used it inside of the XMLin function, that worked perfectly. This is not a good solution, but it worked, and I'm posting the patch here in case anybody else runs into the same problem and needs a quick workaround.

diff --git a/lib/CRS/Executor.pm b/lib/CRS/Executor.pm
index 7a699a8..05c9438 100644
--- a/lib/CRS/Executor.pm
+++ b/lib/CRS/Executor.pm
@@ -127,8 +127,16 @@ sub load_job {
     my $jobfile = shift;
     die 'You need to supply a job!' unless $jobfile;

+    my @cset = ('0' ..'9', 'A' .. 'F');
+    my $tstr = join '' => map $cset[rand @cset], 1 .. 8;
+    my $tmpfile = "/tmp/fnord-" . $tstr . ".xml";
+
+    open(my $fh, '>:utf8', $tmpfile);
+    print $fh $jobfile;
+    close $fh;
+
     my $job = XMLin(
-        $jobfile,
+        $tmpfile,
         ForceArray => [
             'option',
             'task',
@@ -137,6 +145,9 @@ sub load_job {
         ],
         KeyAttr => ['id'],
     );
+
+    unlink($tmpfile);
+
     return $job;
 }

[a-tze]

@lukas2511 Do you know the Perl/libs versions used or the linux distro/release? Or do you have a ticket number, the jobfile-XML is retrieved from the tracker as-is and written to a file. this could be some problem in unicode normalization/c14n. german quotes were present before, I think we also tested a pile of poo in a title at some time.

[lukas2511]

@lukas2511 Do you know the Perl/libs versions used or the linux distro/release? Or do you have a ticket number, the jobfile-XML is retrieved from the tracker as-is and written to a file. this could be some problem in unicode normalization/c14n. german quotes were present before, I think we also tested a pile of poo in a title at some time.

The system was an up-to-date Debian bullseye, Perl v5.32.1. Problem happened with tons of tickets, e.g. 2916.

The same system was used last year without any issues and there also were some talks with german-style quotation in their description... I'm not sure if anything about the tracker or crs scripts changed in the meantime, the only real difference I know of were the encoding changes on the frab database.

[v0tti]

EDIT: Not true, it was something else that differs in the perl env between bookworm and trixie.

We just ran into the same problem at 39C3. libxml-sax-perl 1.02+dfsg-4 has this problem, while version 1.02+dfsg-3 works fine.

[zuntrax]

https://tracker.c3voc.de/39c3/ticket/165109

[a-tze]

This is weird, according to the Debian changelog there was no code change between the two versions mentioned by v0tti, at least none that was worth mentioning. Maybe something changed in the package build process? @v0tti Do these different versions come with different dependencies on other libraries? Or did you compare a trixie installation to a bookworm installation?

[v0tti]

Sorry, this was just the first thing that came to mind when comparing the environments between minion2, where the XML parses correctly, and the new storage (trixie), where the tickets are stuck and parsing is silently failing.

After downgrading the lib version on storage, the issue was still present.

[lukas2511]

This is a new issue after updating from debian 12 to debian 13 and not related to the original problem. The contents of /etc/perl/XML/SAX/ParserDetails.ini do not get updated and perl uses a "pure perl" implementation of an XML parser instead of LibXML. When re-installing the package the file sometimes gets updated and the problem seems to magically be fixed (didn't figure out the logic about when it's actually getting updated). I've added a workaround to our cm master branch which simply rewrites that config file on debian 13 hosts: voc/cm@4f3296f

[a-tze]

I took a deeper dive into this, all the UTF8 handling is actually ok, even without the fix in 7fe94ac .
The two problems seem to be related, as XML::Simple also has some references to LibXML (and even worse, this seems to be some kind of plugin framework in perl, where different libraries can be chosen for XML parsing), thus resulting in different behaviour on systems that seem equal regarding the crs-scripts and the libraries directly used by them.

A stable solution can be to switch to another XML perl library, that has no obscure runtime decisions and also treats the utf-8 flag of the perl strings correctly. v0tti suggested XML::LibXML::Simple which seems to address this exact issue.