From time to time I purge unused accounts in the RT database with shredder.
Suddenly it starts to throw “bizarre” exceptions. Now I can’t purge any
accounts.
root@rt:~# /opt/rt4/sbin/rt-shredder --force --plugin “Users=no_tickets,1;status,any;replace_relations,Nobody;limit,3;member_of,unprivileged”
SQL dump file is ‘/root/20160411T134517-0001.sql’
[2329] [Mon Apr 11 13:45:50 2016] [critical]: Couldn’t wipeout object: Bizarre copy of CODE in list assignment at /usr/local/share/perl/5.18.2/Devel/StackTrace.pm line 61. (/opt/rt4/sbin/…/lib/RT.pm:388)
Trace begun at /opt/rt4/sbin/…/lib/RT.pm line 302
Log::Dispatch::ANON(‘Log::Dispatch=HASH(0x5c24310)’, ‘Couldn't wipeout object: Bizarre copy of CODE in list assignment at /usr/local/share/perl/5.18.2/Devel/StackTrace.pm line 61.^J’) called at /opt/rt4/sbin/…/lib/RT.pm line 388
RT::ANON(‘Couldn't wipeout object: Bizarre copy of CODE in list assignment at /usr/local/share/perl/5.18.2/Devel/StackTrace.pm line 61.^J’) called at /opt/rt4/sbin/rt-shredder line 175
Couldn’t wipeout object: Bizarre copy of CODE in list assignment at /usr/local/share/perl/5.18.2/Devel/StackTrace.pm line 61.
root@rt:~# /opt/rt4/sbin/rt-shredder --force --plugin “Users=no_tickets,1;status,any;replace_relations,Nobody;limit,3;member_of,unprivileged”
SQL dump file is ‘/root/20160411T134517-0001.sql’
[2329] [Mon Apr 11 13:45:50 2016] [critical]: Couldn’t wipeout object: Bizarre copy of CODE in list assignment at /usr/local/share/perl/5.18.2/Devel/StackTrace.pm line 61. (/opt/rt4/sbin/…/lib/RT.pm:388)
“Bizarre copy of …” is always a sign of an internal error in perl.
In this case, it’s caused by the fact that objects on the perl stack
aren’t refcounted, which means that in some cases they can already have
been garbage-collected by the time the object is examined.
Specifically, when RT produces an error, Devel::StackTrace tries to
suss out the values that were passed to each function in the
call stack – and in some cases, those values may no longer exist.
So this is a sign of some other error, which Devel::StackTrace is
trying to build the stack trace for, which itself triggers an internal
perl error. RT catches that error and gives the stack trace for that, which is why what you’re seeing is a stack trace of the log
infrastructure.
You can likely work around this by disabling LogStackTraces, which I
believe you’ve turned on. You’ll then see the underlying RT error that
it was trying to report the stack trace of.
Perl 5.18 is technically out of support, but “stack isn’t refcounted”
isn’t exactly fixed in any recent Perls, so upgrading might only fix
this if it happened to shift the global destruction order.