Perl upgrade on Debian 9 causes JSON error

Upgrading the Perl packages on Debian testing causes external auth to fail:

16594] [Thu Oct 27 16:22:52 2016] [error]: encountered object ‘1’, but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at /usr/share/perl5/JSON.pm line 154.

Stack:
[/usr/share/perl5/JSON.pm:154]
[/usr/share/request-tracker4/lib/RT/Interface/Web.pm:197]
[/usr/share/request-tracker4/lib/RT/Interface/Web.pm:4065]
[/usr/share/request-tracker4/html/Elements/JavascriptConfig:79]
[/usr/share/request-tracker4/html/Elements/Header:64]
[/usr/share/request-tracker4/html/index.html:4]
[/usr/share/request-tracker4/lib/RT/Interface/Web.pm:681]
[/usr/share/request-tracker4/lib/RT/Interface/Web.pm:369]
[/usr/share/request-tracker4/html/autohandler:53] (/usr/share/request-tracker4/lib/RT/Interface/Web/Handler.pm:209)A quick google doesn’t show this particular error.

Any hints as to what might be wrong? I was using external auth and thought that might be causing the problem, but turning that off leaves the JSON error.

I’m using the Debian packages for everything, which had JSON at 3.02 and JSON::XS at 2.98 after the upgrade. Upgrading JSON::XS with CPAN worked and now CPAN says that JSON and JSON::XS packages are both up to date (3.02)

The rest of the system works as advertised, just not the web UI.

James Zuelow
Systems Operations Manager
City and Borough of Juneau - MIS
(907) 586-0236

OK, to answer my own question, I edited line 197 of /usr/share/request-tracker4/lib/RT/Interface/Web.pm

I just added the allow_blessed => 1 to get rid of the error message.

sub EncodeJSON {
my $s = JSON::to_json(shift, { allow_blessed => 1, allow_nonref => 1 });
$s =~ s{/}{\/}g;
return $s;
}

Now the question remains - am I silently breaking something else with that little hack?

I know just enough Perl to be dangerous, so freely admit I’m not aware of all of the possible ramifications of the edit.

James Zuelow
Systems Operations Manager
City and Borough of Juneau - MIS
(907) 586-0236

My apologies on resurrecting an old thread–it most closely identifies with the issue I experienced this weekend.

Did you get find anything else on this issue?

I encountered the same error and stack trace after upgrading my Debian box from Wheezy to Jessie (v9). I was faced with the “an internal error occurred, contact the administrator” page after authentication. After much digging I found your post and applied the same patch which enabled authentication to complete. However, I couldn’t use the advanced search at all as I’d receive a similar error relating to JSON and line 154.

I had used the RT make process to update the perl modules which completed successfully, barring this issue. So I had a half functional RT installation.

As a left field thought I suspected the Debian Perl libraries may . Consequently, I explored the version info for the Debian and the compiled modules for JSON and JSON::XS. The compiled versions were 2.9 and 3.03, whilst the Debian libraries are v2.61 and 2.34 respectively.

Removed the two modules I compiled, installed the Debian libraries instead and RT is now fully functional.

Thought I’d add my experience in case anyone else has a similar experience.

This is also https://bugs.debian.org/848041 (also the much older topic Update to RT 4.2.1 -> JSON error after login).

I believe it’s caused by JSON::XS being installed, and a more recent version of JSON::XS removing the to_json method. I’m not sure exactly what the history is here, but Bug #94784 for JSON: Please recommend Cpanel::JSON::XS instead of JSON::XS suggests that there are known issues with JSON::XS.

I’d like to document just a little bit more concerning this old problem, since it still seems to be an issue. This is my first RT install with the latest version being 4.4.2. The error I got was due to a JSON::PP::Boolean object being sent to JSON::to_json().

$VAR1 = [
{
‘Privileged’ => bless( do{(my $o = 1)}, ‘JSON::PP::Boolean’ ),
‘EmailAddress’ => ‘REDACTED’,
‘Name’ => ‘root’,
‘RealName’ => ‘Enoch Root’,
‘id’ => ‘14’
}
];

I found that I had both JSON::XS and JSON::PP installed. I removed the JSON::XS module with cpanm -U and the problem went away. HTH

1 Like

Hi,

Quick solution to the people using apt package manager on Debian/Ubuntu. Just remove JSON XS package:

$ sudo apt-get uninstall libjson-xs-perl

IMPORTANT: be carefull if you have other packages that depends on XS, and check the evolution of the bug report at debian

1 Like

Just ran into this on RHEL9 with a fresh install of 5.0.3 using an existing database from another 5.0.2 instance that evolved all the way from a 3.x version and have never seen this until the recent move to the RHEL9 server.

Not sure what installed JSON::XS as I don’t have any Perl on my web server besides RT. I checked my installed packages and I don’t have anything with “json” in the name at all, so I don’t have any kind of libjson-xs-perl or anything like it that I am aware of installed at the OS package level. I do have mod_perl installed for apache2 and use it to handle the RT web app, so I’m assuming that’s clashing with the perl package JSON::XS somehow. This has never happened before so must be related to a new version of JSON::XS (or mod_perl).

I used cpanm to remove JSON::XS and have stopped getting the error.

$ cpan App::cpanminus
$ /usr/local/bin/cpanm --uninstall JSON::XS

Will edit this post I run into any issues and someone will get some benefit from it.

1 Like