On Tue, 12 Apr 2016 10:41:24 +0200 (CEST) "Sternberger, Sven" <sven.sternber...@desy.de> wrote: > 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. - Alex --------- RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Washington DC - May 23 & 24, 2016