[rt-users] Bizarre errors with shredder
alex at chmrr.net
Wed Apr 13 04:34:14 EDT 2016
On Tue, 12 Apr 2016 10:41:24 +0200 (CEST)
"Sternberger, Sven" <sven.sternberger at desy.de> wrote:
> root at 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'
>  [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
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.
More information about the rt-users